Last Comment Bug 647036 - Allow attachment pane of a message to open non-collapsed by default
: Allow attachment pane of a message to open non-collapsed by default
Status: RESOLVED FIXED
[gs]
:
Product: Thunderbird
Classification: Client Software
Component: Mail Window Front End (show other bugs)
: Trunk
: All All
: -- minor with 8 votes (vote)
: Thunderbird 17.0
Assigned To: Jim Porter (:squib)
:
Mentors:
http://getsatisfaction.com/mozilla_me...
: 730073 (view as bug list)
Depends on: 282068
Blocks: attachUXtracker 782021
  Show dependency treegraph
 
Reported: 2011-03-31 16:25 PDT by rsx11m
Modified: 2012-08-15 22:55 PDT (History)
22 users (show)
squibblyflabbetydoo: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Add pref to initially expand attachment pane (6.48 KB, patch)
2011-04-14 02:01 PDT, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
Add pref to initially expand attachment pane (redux) (3.61 KB, patch)
2011-04-14 09:38 PDT, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
Jim's Addon - customizable solution to make all users happy (7.82 KB, application/x-xpinstall)
2012-08-07 07:06 PDT, Thomas D. (currently busy elsewhere; needinfo?me)
no flags Details
Updated patch (7.71 KB, patch)
2012-08-11 01:27 PDT, Jim Porter (:squib)
bwinton: review+
bwinton: ui‑review+
Details | Diff | Splinter Review

Description rsx11m 2011-03-31 16:25:48 PDT
The redesign of the attachment pane in bug 282068 now shows it collapsed with
a nice indication about the number of attachments and their size. This is an improvement for users frequently receiving many attachments, or with mostly inlined-displayed content (images or text) for which the attachment list and icons would be redundant.

However, another class of users will typically receive a small amount of attachments, and they may not be displayable inline (e.g., PDF or Word files). Consequently, these users now need a click more, (1) open the attachment pane, (2) double-click on the attachment to open it. Even more, if just a single attachment is received, its name is presented next to the button, but that label isn't clickable and thus can't be used to open the attachment.

A couple of possible solutions to this issue:

(a) Add an explicit preference setting whether top open collapsed=true/false;
(b) remember the last setting (opened or closed) and use it for the next opened
    message (may be more intuitive than a hidden pref);
(c) have some "more"-style mechanism, thus showing a single row of attachments
    and allow it to expand with the button if more attachments are present
    (this would be my personal favorite, easily allowing the first attachments
    to be accessed while not filling up considerable space if more than one
    row is needed).
Comment 1 Jim Porter (:squib) 2011-03-31 17:14:49 PDT
(In reply to comment #0)
> Even more, if just a single attachment is received, its name is presented
> next to the button, but that label isn't clickable and thus can't be used to
> open the attachment.

You can just click the dropdown on the save button and click "open" in this case.
Comment 2 Jim Porter (:squib) 2011-03-31 17:42:48 PDT
(c) probably isn't going to happen, since I don't think there's a good way to simultaneously show the new UI and the first row of attachments while also saving vertical space. The new UI is important, since 1) it shows the total size/count of the attachments (useful for getting a quick estimate of the amount of attached "stuff"), 2) provides a toolbar button to make "save all" more obvious (bug 466060), and 3) has a slightly more noticeable UI than the old way (bug 635884, probably), all without taking up more space. In fact, it takes up *less* vertical space on most platforms (and you can save a few extra pixels by getting rid of the toolbar if you're on a small monitor).

(b) seems like it would be disruptive, since it would require people who usually want the attachment area to be collapsed to always remember to collapse it when they're done. Since the mail content pane is typically fairly small unless you have messages opened in a new tab/window, I think we should avoid defaulting to things that eat up more space than absolutely necessary.

(a) is possible, though in my experience, the overwhelming majority of cases involve a single attachment, which is no better or worse than before (two clicks); you could even make this a single click if you added an "open" button to the toolbar. About the only time I see multiple attachments is on Gmane when mailing list footers get spat out as separate MIME parts (we really need to handle that case better in general).

I had originally planned to do (a) but I skipped it since I didn't want to add more things to test (the expansion/collapsing code had some weird edge cases, though I think I ended up eliminating them in the end).
Comment 3 rsx11m 2011-03-31 18:00:09 PDT
(In reply to comment #1)
> You can just click the dropdown on the save button and click "open" in this
> case.

Thanks, I've missed that one - too much used to double-clicking attachments.
So this would need to get used to, but the single-attachment case is to that extent covered.

(In reply to comment #2)
> ... though in my experience, the overwhelming majority of cases
> involve a single attachment, which is no better or worse than before

It's usually dangerous to assume a specific usage pattern, so if someone's workflow includes getting messages with 2-3 attachments at a time, it would be a regression in efficiency for him or her how they are to be opened (and I'm sure that we will see such requests in the forums once 3.3 is out).

We have a couple of settings for the message headers already to customize them, there shouldn't be any harm implementing some switch to determine the default behavior of the attachment pane when opening a message.

I agree that (b) may cause similar issues with someone's expectations being differently, and that (c) would imply some additional work for it to function.
Comment 4 Mark Banner (:standard8) (afk until 26th July) 2011-04-01 01:00:30 PDT
(In reply to comment #3)
> We have a couple of settings for the message headers already to customize them,
> there shouldn't be any harm implementing some switch to determine the default
> behavior of the attachment pane when opening a message.

We shouldn't take adding extra preferences lightly, they make the code more complex - we should be encouraging extensions more. I'd also rather get some wider feedback before we rush into further changes.


Having said that, I think the point about displaying the attachment name (in the case of one attachment) without it being clickable IMO would be annoying to me. I think we either need to consistently not display the attachment name, or in the case of one attachment it needs to be clickable.
Comment 5 rsx11m 2011-04-01 07:43:39 PDT
(In reply to comment #4)
> We shouldn't take adding extra preferences lightly, they make the code more
> complex - we should be encouraging extensions more.

One could equally argue that bug 282068 might have been implemented as an extension ;-) [Jim, don't get me wrong - I think it's great to see the number and total size of the attachments, and also to collapse a large list, and to have this as a default feature in Thunderbird, I'm just envisioning issues for users having a different environment and usage pattern than was targeted.]

While the comparison with the "to/cc" message headers might not be entirely applicable (that was a feature regressed in 2.0 and further in 3.0 until 3.1 eventually fixed it, whereas collapsible attachment panes haven't been there), the user's view may be similar: Thunderbird 3.0 restricted the address list to one visible address then a "more", and now we have one visible attachment or just the "more" to get to them. We've seen that users substantially disagreed with the notion getting just a single address in the header is "usually" enough so I wouldn't be surprised to see a similar reaction on the attachment pane if this isn't addressed.

> I'd also rather get some wider feedback before we rush into further changes.

I'm fine with that, but sooner or later feature and string freezes kick in...
Comment 6 rsx11m 2011-04-01 07:47:46 PDT
> (still comment #4) I think the point about displaying the attachment name (in
> the case of one attachment) without it being clickable IMO would be annoying to
> me. I think we either need to consistently not display the attachment name, or
> in the case of one attachment it needs to be clickable.

Making the label clickable would be intuitive and easier discoverable/usable than the menu option. Once the user figured out that right-click doesn't do anything here, he or she will hopefully find the menu to the right for the other attachment-handling actions.

As a logical extension to this proposal, why not have something like this,
"n attachments: file1.txt, file2.txt, file3.txt ... [Save All v]" which uses the available space with clickable attachment names until the line is full?
This would elegantly address the issue without the need of a preference setting or additional space. If indeed you get a dozen attachments or want to see the full details with icons, one can still use the "expand" button to open it.
Comment 7 Jim Porter (:squib) 2011-04-01 10:50:11 PDT
I think showing all the attachment names inline would be too cluttered. It works for the headers since the header is, by default, quite a bit bigger.

It's actually pretty straightforward to make the pane start out expanded (three lines of code total, including setting the default pref value), and it should be really easy to test since I already have a similar test for starting out collapsed.

One benefit of the pref is that it becomes really easy to go back to the old way if you hate/fear change (just set the pref and add some userChrome to hide the toolbar).

I can make the single attachment name clickable though. Probably the best solution would be to make it change color on mouseover (either like a link or like the addresses in the header) and then on click, pop up the menu that you'd get from right-clicking a message in the list proper.
Comment 8 Jim Porter (:squib) 2011-04-01 10:50:48 PDT
clarkbw, do you have opinions on comment 7 (esp. the last paragraph)?
Comment 9 Joe Sabash [:JoeS1] 2011-04-01 18:13:42 PDT
(In reply to comment #7)

> I can make the single attachment name clickable though. Probably the best
> solution would be to make it change color on mouseover (either like a link or
> like the addresses in the header) and then on click, pop up the menu that you'd
> get from right-clicking a message in the list proper.

The problem with this is that most users are accustomed to double-clicking.
So now when "muscle memory" has me double-clicking..I now see a menu ?

It's not a matter of hating/fearing change, it's a matter of habit and expectations.

Extra steps (clicks) are never appreciated. (My "Carpel Tunnel" resistance already tested enough with 50,000 or more "Don't use alternate text" clicks.)
Comment 10 Bryan Clark (DevTools PM) [@clarkbw] 2011-04-03 11:01:14 PDT
(In reply to comment #7)
> I can make the single attachment name clickable though. Probably the best
> solution would be to make it change color on mouseover (either like a link or
> like the addresses in the header) and then on click, pop up the menu that you'd
> get from right-clicking a message in the list proper.

Sounds reasonable though clicking the behavior is different than when looking at attachments in the expanded box.  I'm wondering if we should keep the behavior the same...  Accept double click to open the attachment and show the right click menu if right clicked.  Though more consistent I don't think it would be as clear as just a link style hover where a single opens and a right click shows the popup menu.

I would go with a link style hover and pointer mouse, single click opens the attachment and right click opens the popup.  I think that would translate best in this situation in terms of consistent behavior and the different display.
Comment 11 mad.engineer 2011-04-03 19:14:02 PDT
(In reply to comment #4)

> We shouldn't take adding extra preferences lightly, they make the code more
> complex - we should be encouraging extensions more. I'd also rather get some
> wider feedback before we rush into further changes.

Would like to add my 2 cents here. I'm not a developer nor a tester, but just a passionate end user since the Netscape days.

I understand that adding extra preferences add complexity to the code, but any time there's a change made in the UI that affect the end user behavior, it's a no win situation in my opinion. I'm sure that half of the users will like the change, and half won't. You cannot satisfy everyone. But the only way to keep everyone happy is to give the end users an option in the UI.  Those in favor, can simply enable it via the preference, and those against, disable it the same way. Change is always hard to adapt to. I can give you several examples here like the "more" option added in 3.x over the previous versions etc. This was not a good UI decision.

As for the extension/add-on route, it's a good method, but unfortunately, it leave the end users like us on the mercy of the extension author. If they abandon the extension, you're left scrambling to figure out what to do next. I can give you examples where the extension(s) I use to overcome some of the 3.1.x UI shortcomings in my opinion, have been abandoned by the author and now I'm proactively searching for alternates for the next 3.3 version. I've yet to see any formal method of soliciting feedback from the user community for the new features. Yes, bug reports are suppose to be the case, but then enhancement related bug reports in my option are pretty much black holes based on my own experience. There should be a formal way to request feedback, see what majority of the end users feel about it and then implement it. 

For this specific feature, I understand that the making the attachment box collapsible adds extra real estate space, but then every other major client that I've used in the past show all attachments by default. There must be reason that others feel like this is the right way of doing it :-)
Comment 12 rsx11m 2011-04-04 08:21:06 PDT
(In reply to comment #7)
> It's actually pretty straightforward to make the pane start out expanded (three
> lines of code total, including setting the default pref value),

I would consider three lines an acceptable increase of code complexity relative to the benefit it provides to the user. I'd expect the test to be more complex than that, despite parts of it already existing... ;-)
Comment 13 Jim Porter (:squib) 2011-04-14 02:01:16 PDT
Created attachment 525964 [details] [diff] [review]
Add pref to initially expand attachment pane

While I'm not 100% sure we want to do this, here's a patch for it anyway. It's pretty simple. Note: this patch only addresses the pref. I didn't do anything with making the single attachment item clickable. (See the following comment for stuff on that.)
Comment 14 Jim Porter (:squib) 2011-04-14 02:08:38 PDT
So I've been thinking about making the single attachment name clickable. Since it would also open a content menu on right-click, this is nearly everything you can do with the expanded attachment area (except drag-and-drop). I could even make the attachment name draggable, so it would do everything.

However, I'm hesitant to eliminate the expanded area in the single attachment case because:

1) Drag-and-drop seems much more "obvious" from the expanded area, since it looks like a file manager.

2) When we finally get keyboard accessibility in the attachment pane fixed, I think it will be easier to use a keyboard inside the expanded area than in the collapsed attachment bar.

3) The attachment icon is potentially useful, but I didn't want to put that in the collapsed bar since it seems a little too in-your-face to me.

4) It would be more complicated to totally disable expanding the bar in the single attachment case (even more so if the pref in comment 13 is added), and I don't think there's really any harm in allowing it to be expanded.
Comment 15 Jim Porter (:squib) 2011-04-14 09:38:59 PDT
Created attachment 526025 [details] [diff] [review]
Add pref to initially expand attachment pane (redux)

Oops. The previous patch had another patch that snuck aboard.
Comment 16 Jim Porter (:squib) 2011-04-16 00:22:15 PDT
Comment on attachment 526025 [details] [diff] [review]
Add pref to initially expand attachment pane (redux)

:clarkbw, does it sound reasonable to add a hidden pref to make the attachment pane start out expanded? While we've discussed ways to make the collapsed state more useful in this bug, I'm not sure that will satisfy everyone.
Comment 17 Bryan Clark (DevTools PM) [@clarkbw] 2011-04-22 11:07:17 PDT
Comment on attachment 526025 [details] [diff] [review]
Add pref to initially expand attachment pane (redux)

I'm going to let Blake make the call on this one.  

I'm sure everyone knows I loathe hidden prefs because of the added complexity in every area of our work.  The UI may look and behave differently for a certain set of people and it only solves the issue for those who are lucky enough to search for the possibility.  As pointed out in comment 11 with an add-on you're at the mercy of the add-on author however hidden prefs are the step children of our code which regularly get lost in the shuffle and broken.

The world of add-ons just keeps getting better inside Thunderbird.  You can create a restart-less add-on that makes this happen and people can search for it within the new add-on manager, one-click-install.  I'd recommend add-ons for these issues every time.  If there's something we can do in the code base to make the add-on development easier then I think that's worth investigating.
Comment 18 Jim Porter (:squib) 2011-04-25 15:49:35 PDT
Comment on attachment 526025 [details] [diff] [review]
Add pref to initially expand attachment pane (redux)

I discussed this with Blake on IRC, and the plan is to write a simple extension that lets people tweak the attachment pane. The options I plan to include are:

* Initially expand the attachment pane
* Hide the attachment header bar
* (If it's not too complicated) put the attachment pane up by the message header
Comment 19 Joe Sabash [:JoeS1] 2011-04-25 16:59:26 PDT
What about the case of making a single attachment clickable.
Would you include that in the extension, or resolve that here or in another bug.
Or..yet another extension. (sorry for that "the devil made me do it" ala Flip Wilson)
Extensions are great, but testers and realtime users inputs to a change in UX are important as well.
Comment 20 rsx11m 2011-04-25 17:22:53 PDT
First of all, thanks to Jim for all his efforts, it's appreciated. I obviously disagree with the notion that a 3-linish addition to the code to allow a better customization adds complexity that a comparable add-on wouldn't. In contrast, having to considerably add extensions for functionality which are basically a set of fairly trivial code additions for a hidden pref (or even just style changes) adds potential instability due to the dependency on the respective third party to keep it up to date and by possible conflicts with other add-ons.

Anyway, question per comment #19 to Blake whether this is a blanket WONTFIX or if there is any component in this bug you'd like to see implemented.
Comment 21 Jim Porter (:squib) 2011-04-25 17:43:23 PDT
I'll be making the attachment name clickable in this bug.
Comment 22 Blake Winton (:bwinton) (:☕️) 2011-04-25 17:49:13 PDT
(In reply to comment #20)
> First of all, thanks to Jim for all his efforts, it's appreciated. I obviously
> disagree with the notion that a 3-linish addition to the code to allow a better
> customization adds complexity that a comparable add-on wouldn't.

The complexity isn't the three lines themselves, it's the added tests, and the twice-as-many-cases for extension authors or core developers who want to do something with the attachment area to handle, and the extra confusion on support staff who won't know why some user's UI is different than theirs.

> In contrast,
> having to considerably add extensions for functionality which are basically a
> set of fairly trivial code additions for a hidden pref (or even just style
> changes) adds potential instability due to the dependency on the respective
> third party to keep it up to date and by possible conflicts with other
> add-ons.

The potential instability is still there if the code is in core, and hopefully there will only be one add-on which will contain all the various tweaks you want to see.  Heck, Jim even volunteered to write the add-on, so I believe it'll be kept up to date at least as well as the code is.  ;)

> Anyway, question per comment #19 to Blake whether this is a blanket WONTFIX or
> if there is any component in this bug you'd like to see implemented.

It's not a blanket WONTFIX, at least not until we get some data on how our users actually use this new feature, and what the pain points are for everyone.  (You'ld have to agree that if it's only you who's really bothered by this, then certainly an extension is the right way to go.  On the other hand, if everyone complains about the new UI being slower and more cumbersome, and the add-on has as many users as Thunderbird itself does, then we will certainly look into changing it to fix that.  :)

Actually, even in that case, adding a hidden pref is a WONTFIX.  But I would still like to resolve the case you mentioned in the first comment of users who only get a small number of non-inline-able attachments.  (Although, with Jim's change from comment #21, that only leaves people who regularly get 2-3 attachments which they only want to open some of, which is starting to sound like a pretty small set of people to cater to…)

Thanks,
Blake.
Comment 23 Jim Porter (:squib) 2011-04-25 18:55:34 PDT
Ok, I lied. :) I think I'm actually going to make the single attachment name clickable in bug 646032, just because I'm touching the same CSS in both of these changes, and it'll be easier to do it in one bug instead of two.
Comment 24 David :Bienvenu 2011-04-26 07:35:31 PDT
One data point - the new behavior is always wrong for me, and I suspect will be wrong for most users. From past experience, this is going to drive users crazy. I don't think an extension is particularly appropriate here, personally, unless it has a lot more useful features besides just showing me my attachments by default so I can open them with a double click.

I think remembering the last expand/collapse state of the attachments area will suffice for most users. If you wanted to auto collapse when there were a lot of attachments, that would probably help with your objections to b).

I understand that hidden prefs are bad, so why not make it visible? It could even be accessible via a context menu in the attachments widget, instead of buried in the prefs ui.
Comment 25 David Ascher (:davida) 2011-04-26 07:37:53 PDT
Wouldn't remembering the collapsed state end up being that visible pref?
Comment 26 David :Bienvenu 2011-04-26 07:43:04 PDT
(In reply to comment #25)
> Wouldn't remembering the collapsed state end up being that visible pref?

It could be, or it could be a tri-state - always expand, always collapse, remember.

Sorry for ranting on, and sorry if this will be addressed in a patch not yet landed, but the simple case of a single attachment is worse now - a single attachment could be displayed expanded and only take up as much space as a collapsed single attachment.

All that being said, I'm very glad that the attachment area is getting some much needed attention.
Comment 27 David :Bienvenu 2011-04-26 07:59:38 PDT
So what would make me very happy is to just show the attachments if they only take up one line, aka hiding the twisty in the simply case. Though I don't think it's quite that simple because you probably still want to show the Save button.
Comment 28 rsx11m 2011-04-26 08:12:33 PDT
This would correspond to variant (c) in my initial bug description, which I'd too would consider the optimum behavior with acceptable size trade-off. Rather than collapsing the attachment pane one could just prohibit vertical overflow (similar to the "singleline" attribute in the to/cc message headers) and then present the twisty button only if an overflow occurs. This would obsolete the issue of showing a single attachment name in the bar, but it still would be nice to retain the total size count and the action button in that bar.
Comment 29 Jim Porter (:squib) 2011-04-30 23:30:42 PDT
(In reply to comment #27)
> So what would make me very happy is to just show the attachments if they only
> take up one line, aka hiding the twisty in the simply case. Though I don't
> think it's quite that simple because you probably still want to show the Save
> button.

Unfortunately, this would pose a real problem for people who need to operate on a subset of the attachments they have (e.g. save all but the second attachment). That's why I didn't just follow the style of the To/Cc/Bcc fields in the header.

Anyway, I created an addon for people who want to change how the attachment pane is displayed: https://addons.mozilla.org/en-US/thunderbird/addon/attachment-options/

For me, that makes this bug fixed, but I'll leave it open, as some people may disagree.
Comment 30 rsx11m 2011-05-01 06:50:18 PDT
Thanks Jim. I yet think that the proposed variant in comment #28 would be suitable to implement comment #27; users could still open he full attachment pane for the "all but the 2nd" scenario, but it would spare them having to do that for gaining access to a small number of attachments below one line. Showing the attachment bar in that case is another question, I'd tend to yes.

BTW: It appears that overlay.xul includes a CSS sheet from another extension:
> <?xml-stylesheet href="chrome://mailsummaries/content/overlay.css" type="text/css"?>
Comment 31 Jim Porter (:squib) 2011-05-01 12:25:17 PDT
(In reply to comment #30)
> Thanks Jim. I yet think that the proposed variant in comment #28 would be
> suitable to implement comment #27; users could still open he full attachment
> pane for the "all but the 2nd" scenario, but it would spare them having to do
> that for gaining access to a small number of attachments below one line.
> Showing the attachment bar in that case is another question, I'd tend to yes.

That violates ux-minimalism though: "Interfaces should avoid redundancy." If we started cramming all the attachments we could fit on one line, we might as well go all the way and make it work like Outlook does (i.e. like Thunderbird's To/Cc/Bcc fields), which as far as I can remember, doesn't allow multiselection. The current way Thunderbird does things is actually pretty similar to how Evolution works (Evolution's attachment handling is one of the few things I like about it), except that they also have attachment save/open buttons shown inside the message.

Filling up the row with attachments would also make it more difficult to get at the full list, since you can click on unused parts of the bar to expand it.

Usually ux-minimalism's nemesis is ux-discovery, but I don't think discovery is hurt in this case; it's pretty obvious that there are more attachments, and the twisty indicates that more information is there, but hidden. I also don't think ux-efficiency is hurt much, since if you receive >1 attachment, you probably want to do things with >1 of them (possibly all of them, but not necessarily), so you'd either hit "save all" or have to open the full list anyway (or suffer through operating on each attachment individually).

> BTW: It appears that overlay.xul includes a CSS sheet from another extension:
> > <?xml-stylesheet href="chrome://mailsummaries/content/overlay.css" type="text/css"?>

Whoops!
Comment 32 rsx11m 2011-05-01 14:47:08 PDT
(In reply to comment #31)
> That violates ux-minimalism though: "Interfaces should avoid redundancy." If we
> started cramming all the attachments we could fit on one line, we might as 

We may be talking about different things. Have a look at Bozz's workaround in http://forums.mozillazine.org/viewtopic.php?f=29&t=2153111#p10641887 to see what I mean (it won't take care of any overflow/underflow conditions, but you get the idea). I don't see a redundancy here, it might make your efforts to get the single attachment clickable in bug 646032 (part 2) moot though given that the single (and few) attachment would always be fully accessible in this way.
Comment 33 Jim Porter (:squib) 2011-05-01 16:23:29 PDT
That method sounds like the worst of both worlds. It just wastes space for the single attachment case, and in the case of several attachments, presents an extremely confusing UX. The fact that the scroll bar won't be present in the single-row case is a *serious* violation of ux-discovery and ux-consistency, and without reading that description, I would have absolutely no idea that there were more attachments than what fit in the first row.

While I generally think that making this work like the To/Cc/Bcc headers is bad, at least that UX would be comprehensible to someone who wasn't intimately familiar with how the UX was supposed to work.

I'm well aware that there are certain people who want something different than the default UX (as is very often the case, they just want the old way), but that's why there's an addon available for them.
Comment 34 Jim Porter (:squib) 2011-05-01 16:42:55 PDT
Also, I know you can set the minimum size of the attachment list to 32px and have scrollbars appear (on most systems), but really, that's almost 2 rows of attachments*, which wastes even more space, and largely defeats the point of needing an expandable pane anyway (I seriously doubt that people are getting a large number of emails with >8 attachments). In that case, I'd just use the addon and set the pane to start out expanded.

* There's a margin of a couple pixels around the list, so 32px isn't *quite* two rows, but it's pretty darn close.
Comment 35 rsx11m 2011-05-01 18:32:19 PDT
Well, so far that solution works best for me (and apparently others as well). Nobody said that you need those extra 32px, this was only for testing if and
when a scroll bar is desired (and I don't think it's needed, thus leave it at
the minimum). I'm happy with devoting 24px for that row of attachments if it spares me from having to click on the twisty button most of the time.

Anyway, it's probably up to Blake to decide on the future of this bug. I can live with the workaround, the question is what's serving best the inexperienced user who may not be happy about installing add-ons (and even less of putting cryptic code into some cryptic file at some even more cryptic location).
Comment 36 Jim Porter (:squib) 2011-05-01 18:54:07 PDT
(In reply to comment #35)
> Well, so far that solution works best for me (and apparently others as well).
> Nobody said that you need those extra 32px, this was only for testing if and
> when a scroll bar is desired (and I don't think it's needed, thus leave it at
> the minimum). I'm happy with devoting 24px for that row of attachments if it
> spares me from having to click on the twisty button most of the time.

That solution works for you entirely because you know exactly what's happening (since you added userChrome to do it). It would not be obvious at all to people who hadn't done that. There have already been bug reports filed (mostly for Firefox, as I recall) about scrollbars being missing and causing confusion. I don't think it's a good idea at all to go down that route, certainly not without having the user make an explicit choice to do that.

Compared to the default or the addon, the userChrome just optimizes the experience for people who are likely to receive 2-3 rows of attachments (i.e. around 5 or more) and always want to operate on a subset of those attachments. For people who usually receive fewer attachments, the addon is sufficient. For people who usually receive 1 attachment or typically save/detach/delete all their attachments, the default is fine. For people who don't care a whole lot either way, the default is also (obviously) fine.

If it turns out that lots of people install the addon, I'm sure the powers that be will consider putting those features into Thunderbird proper. But I think it's premature to do that now, when we don't actually have any idea how many people care about this. We can't draw any conclusions on that yet, however, since a handful of people on mozillazine aren't a representative sample set.

> Anyway, it's probably up to Blake to decide on the future of this bug. I can
> live with the workaround, the question is what's serving best the inexperienced
> user who may not be happy about installing add-ons (and even less of putting
> cryptic code into some cryptic file at some even more cryptic location).

I never understood people's aversion to addons (or, perhaps, people's assumption that others are averse to addons). One of the most important principles behind Mozilla applications are that they should be extensible via addons. We should be encouraging people to use addons *more*, not less.
Comment 37 rsx11m 2011-05-01 19:09:03 PDT
We see outdated or conflicting add-ons all the time in the forums, so in contrast to the assumption voiced in comment #22, it's not a secure path to more stability (at least anything in the core code is - ideally - consistent with anything else in the core code, whereas combining two extensions with similar scope easily screws up things; the expectation that there is one universal add-on covering the attachment pane is rather wishful thinking).

The user expects an application to be as complete as possible to do the job (sorry for not being able to present any hard numbers), and will usually react fine when recommended one or maybe even two add-ons in the forums to fix a problem. I'm confident that an inflation of add-ons needed won't be well received if that turns out to be the norm rather than the exception. Such negative reaction was already encountered with the compact header and folder columns features that were converted to 3rd-party extensions in the past.
Comment 38 Jim Porter (:squib) 2011-05-01 19:33:33 PDT
(In reply to comment #37)
> We see outdated or conflicting add-ons all the time in the forums, so in
> contrast to the assumption voiced in comment #22, it's not a secure path to
> more stability (at least anything in the core code is - ideally - consistent
> with anything else in the core code, whereas combining two extensions with
> similar scope easily screws up things; the expectation that there is one
> universal add-on covering the attachment pane is rather wishful thinking).

Outdated addons aren't really relevant anymore, since the switch to faster releases in Mozilla applications means that addons will automatically have their maxVersion updated if they don't break anything. I assume Thunderbird is doing this too; if not, they certainly should. Also, this addon is maintained by a Thunderbird developer (me), so it will be maintained for the foreseeable future.

Incompatible addons happen, but that's easy to work around with a small amount of effort (e.g. protz and I coordinated Thunderbird Conversations and Mail Summaries to be compatible). Since I'm the one maintaining this addon, I can say with a fair amount of confidence that I'll attempt to maintain compatibility where possible. That argument can also easily be overextended to expect *everything* to be a part of Thunderbird.

> The user expects an application to be as complete as possible to do the job
> (sorry for not being able to present any hard numbers), and will usually react
> fine when recommended one or maybe even two add-ons in the forums to fix a
> problem.

Since we have no idea what a statistically significant set of users expect, it's premature to try to cater to them. They may not exist in any great number. We'll be able to figure out more about this when we see how many people install the addon. Keep in mind I'm not saying "this should be WONTFIX", but "we should wait and see how many people actually care".

> Such negative reaction was already encountered with the compact header and
> folder columns features that were converted to 3rd-party extensions in the
> past.

This may not be the ideal analogy to make, since of course, the Thunderbird drivers chose to pull those out into extensions, despite the (relatively minor, compared to other feature cuts I've seen) wailing and gnashing of teeth. :)
Comment 39 Lufferov 2011-07-06 04:52:21 PDT
It seems to me this is only been looked at from a single users perspective who rarely gets sent attachments, and that that those they do will will mostly be pictures that appear within the message itself.

Unfortunately it's not that simple, in my work for instance I get sent multiple attachments with nearly email I receive. Press releases and images etc... I don't want to "Save All", I want to open the press release to get the copy, and save selected images for use in my article. I can regularly get 10+ attachments!

Using extensions for something as simple as this adds complexity to my installation and is something else for me to maintain. I am not happy to see a feature I am accustomed to change like this.

The argument to move things to plug-ins is fundamentally flawed. You could use the argument for every single feature in the application, how far do you take it? Just have POP by default and move SMTP into an extension? Don't include an Address book and provide that as an extension? Attachments are a fundamental feature of email and should be fully catered for in the core code!
Comment 40 Jim Porter (:squib) 2011-07-06 07:48:48 PDT
As already mentioned in the bug, the extension is an experiment to determine how many people care about having the attachment pane expanded by default. If the number of users of that extension isn't particularly high, then that's a pretty clear sign that not enough users care about the extra click needed to expand the pane for the feature to move into Thunderbird.

To be perfectly clear: absolutely no functionality has been lost. The only change is that we optimize for reading the message rather than saving subsets of attachments. The reason there isn't already a pref to control this from inside Thunderbird is simply because we have no evidence that a significant fraction of users care.
Comment 41 rsx11m 2011-07-06 07:54:56 PDT
(In reply to comment #40)
> If the number of users of that extension isn't particularly high,

That count isn't accurate as it misses those users which simply employ the circulating userChrome.css workarounds for individualized customization.
Comment 42 rsx11m 2011-07-06 08:08:26 PDT
So, right now the site shows 623 downloads, that's a week after the 5.0 release
and despite the "experimental" banner which likely scares off "normal" users.
Which number has to be reached in your opinion to justify implementing such an
option in the regular release? Also, many users won't make it to the forums to
know about the add-on, thus they just live with what they have.
Comment 43 Jim Porter (:squib) 2011-07-06 08:31:14 PDT
(In reply to comment #41)
> (In reply to comment #40)
> > If the number of users of that extension isn't particularly high,
> 
> That count isn't accurate as it misses those users which simply employ the
> circulating userChrome.css workarounds for individualized customization.

Even if we assumed that an order of magnitude more people used userChrome modifications, there still wouldn't be a significant number of users who care (ADUs for the add-on peak at around 100). At least by using the add-on's stats, we can get some kind of sense for how common the issue is. Individual comments in this bug aren't statistically significant. As an aside, this bug currently has exactly one vote, which isn't particularly motivating either (I regularly run a query on Bugzilla to find the bugs voted on most frequently and have fixed a few issues entirely because of that).

(In reply to comment #42)
> So, right now the site shows 623 downloads, that's a week after the 5.0
> release
> and despite the "experimental" banner which likely scares off "normal" users.
> Which number has to be reached in your opinion to justify implementing such
> an
> option in the regular release?

Well, first I have to fix a minor error and get it fully reviewed. Once that happens, I'll personally consider it worthwhile to push for a pref to be added to Thunderbird if the ADU count exceeds, say, 10,000. (If I were feeling snarky, I'd say "more users than Extra Folder Columns or Compact Header": about 250K.)

Note that this isn't any kind of a guarantee, but it'll be enough for me to make another push to add a pref for this. Bear in mind I originally planned to control this via pref, and indeed wrote a patch for it (see above), but it didn't get very far since we had no evidence that it was worth the maintenance cost.
Comment 44 Joe Sabash [:JoeS1] 2011-07-06 15:31:26 PDT
If you are using that extension download count as a metric, I downloaded via Right click ..save link as and that count never changed.
Also, the extension does not seem to work when using a standalone window to view messages.
Comment 45 Matthew Atkinson 2011-07-12 12:05:35 PDT
I've downloaded the add-on, and with the toolbar removed, and attachments expanded by default, I'm now back to a usable mail client.

I'm sure I'm not unusual in getting many messages with multiple attachments, and the toolbar provided no value for me whatsoever. I could already see how many attachments as their names are all shown, and the size of the message is already displayed in the size column in the message list. I almost never want to save an attachment (why would I want another copy, I already have one in my e-mail?), just to open it, read it, and perhaps print it.

I strongly agree with those who feel that this functionality (which is essentially being able to keep what was there in previous releases) should be present in the standard product, and not require an add-on. Surely it's always regressive to lose one way of doing things (which some will like) just because you think some will like another way of doing them. 

I've now got two Add-Ons (this one and Extra Folder Columns) just to get me back to where I was in TB2! How can that possibly be progress? I've already had to put up with silly headers which won't show me all the recipients of an e-mail at once, and still can't see the full names of my attachments, both as 'improvements', this is just making things worse.
Comment 46 thebluejay 2011-07-24 11:32:21 PDT
Just a plain old user who would love to be able to see the attachments by default. It is indeed quite a nuisance for me to have to open a new menu to get to the attachments.

I have tried the Attachment Options 0.3 and that doesn't seem to work for me. If I right-click on the attachment area, the only customize options available are Separator and Space which can be added to the toolbar and show text or icons. Nothing about having the area collapsed or open.

I then tried the modification of my userchrome file. I don't know if I got that quite right but here is what I did:

My userchroeme file is located here:
C:\Documents and Settings\thebluejay\AppData\Roaming\Thunderbird\Profiles\947zl6pc.default\chrome\userChrome.css

and this is the content of the file itself:

/*
 * Edit this file and copy it as userChrome.css into your
 * profile-directory/chrome/
 */

/*
 * This file can be used to customize the look of Mozilla's user interface
 * You should consider using !important on rules which you want to
 * override default settings.
 */

/*
 * Do not remove the @namespace line -- it's required for correct functioning
 */
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */


/*
 * Some possible accessibility enhancements:
 */
/*
 * Make all the default font sizes 20 pt:
 *
 * * {
 *   font-size: 20pt !important
 * }
 */
/*
 * Make menu items in particular 15 pt instead of the default size:
 *
 * menupopup > * {
 *   font-size: 15pt !important
 * }
 */
/*
 * Give the Location (URL) Bar a fixed-width font
 *
 * #urlbar {
 *    font-family: monospace !important;
 * }
 */

/*
 * For more examples see http://www.mozilla.org/unix/customizing.html
 */
 

/*
 * Edit this file and copy it as userChrome.css into your
 * profile-directory/chrome/
 */

/*
 * This file can be used to customize the look of Mozilla's user interface
 * You should consider using !important on rules which you want to
 * override default settings.
 */

/*
 * Do not remove the @namespace line -- it's required for correct functioning
 */
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */


/*
 * Some possible accessibility enhancements:
 */
/*
 * Make all the default font sizes 20 pt:
 *
 * * {
 *   font-size: 20pt !important
 * }
 */
/*
 * Make menu items in particular 18 pt instead of the default size:
 *
 * menupopup > * {
 *   font-size: 18pt !important
 * }
 */
/*
 * Give the Location (URL) Bar a fixed-width font
 *
 * #urlbar {
 *    font-family: monospace !important;
 * }
 */

/*
 * Eliminate the throbber and its annoying movement:
 *
 * #throbber-box {
 *   display: none !important;
 * }
 */

/*
 * For more examples see http://www.mozilla.org/unix/customizing.html
 */
 
/* Change color of ACTIVE tab */
/*tab
/*{
/*    -moz-appearance: none !important;
/*}
/*tab[selected="true"]
/*{
/*    background-color: rgb(120, 255, 120) !important;
/*    color: black !important;
/*}
/*/* Change color of normal tabs */
/*tab:not([selected="true"])
/*{
/*    background-color: rgb(202, 228, 255) !important;
/*    color: rgb(21, 1, 133) !important;
/*}


#attachmentView > [collapsed="true"] {
  visibility: visible !important;
}

#attachmentToggle {
  display: none !important;
}

This did not work either. Did I put the file in the right place? Are the entries configured properly? I have no objection to working with extensions or modifications to userchrome, but darn it would be really nice if they worked! :)

One more point I might add about the isssue. Making a single attachment visible and clickable was a good idea. But often a single attachment turns out to be accompanied by other "stuff" like ads from Incredimail or notice from AVG about virus checking. These also show as attachments and then the "real" attachment is no longer single and can't be opened directly from the attachment area without first opening it.

For me, the best solution would be to have the option to have the attachment area always expanded or always collapsed. I guess this would work for those who get many attachments as well as for those of us who get only a couple or soo at a time.

In the meantime, I hope someone can help me with the extension and/or workaround that aren't working for me.

Nice to see the attention being given to the issue. Much appreciated.

Thanks.
Comment 47 Jim Porter (:squib) 2011-07-24 11:35:14 PDT
Try installing version 1.0b2 of the add-on (you'll need to click "View all versions" near the bottom to get at it, since it hasn't been reviewed yet).
Comment 48 thebluejay 2011-07-24 12:54:34 PDT
Beautiful, Jim!  That did the trick just fine.  Many thanks.
Comment 49 Thomas D. (currently busy elsewhere; needinfo?me) 2011-08-20 02:41:45 PDT
Related/Similar:

Bug 271052 - Add Prefs UI to control default visibility of Attachments pane on New Message
Comment 50 rsx11m 2011-08-20 07:01:57 PDT
Not really; that one is for the attachment pane being invisible during message composition unless an attachment is actually to be added, we are talking about the redesign for the message viewer here - two completely different things.
Comment 51 rsx11m 2011-08-20 09:35:17 PDT
(on a side note, Thomas is certainly correct that the two bugs are related in a sense that they address issues with hidden attachment panes to be kept open by a preference setting; bug 271052 is more of a discoverability issue whereas the bug here addresses a usability issue to get to more individual attachments received.)
Comment 52 Thomas D. (currently busy elsewhere; needinfo?me) 2011-11-01 15:06:03 PDT
fyi, four months after comment 42 the download count for Jim's addon(1) which fixes this annoying problem is up to 3,662 today (from 623 on 2011-07-06), and I downloaded using the button and my download wasn't counted. I don't believe in addon download counts, and I don't believe in addons to fix basic usability problems, but it's more than obvious this needs to be fixed in the core.

The addon UI is nice and intuitive and something along those lines should be in the core (not sure about hiding the bar, very sure that this option should be tri-state: always collapsed, always uncollapsed, remember previous).

Another sidenote on the nonsense of counting addon downloads: If I was the IT administrator of a big company using TB on some thousand computers, I'd probably just download that addon *once* and then deploy it through the network. After that, thousands of users in my company are using the addon, and the download count is probably just up by one.

(1) https://addons.mozilla.org/en-US/thunderbird/addon/attachment-options/
Comment 53 Lufferov 2011-11-01 18:08:47 PDT
I've learnt that you are wasting your time with these things, I've been involved in a number of blatantly bad usability "bug" reports. None of them are ever addressed. 

Developers don't care too much about issues like this, they want to spend their time coding new stuff, not fixing annoying issues like this one. It's unfortunately a fundamental problem with this type of software development.

As you will see above, this report is rated as "minor" and in my experience you can forgot this issue ever being resolved despite how relatively easy it would be to do so. A fairly common response is to tell you to contribute some code yourself. What these people forget is we aren't all programmers! Just users who actually care about design and usability.
Comment 54 David :Bienvenu 2011-11-01 18:17:45 PDT
It's not that the developer doesn't care about usability; it's that he disagrees with you about the usability issue. And I believe our UI reviewer is happy with the current decision. It would be great if everyone agreed about UI but that's not the world we live in. Disagreeing does not equal not caring.
Comment 55 Lufferov 2011-11-01 18:26:43 PDT
As I say, this kind of attitude is endemic in this type of software development. If this was a commercial product and they lost several thousand paying customers then you can be damn sure it would get a higher importance than it has for something that can be fixed so easily.

I am dismayed at the state of software development in general these days. Usability simply isn't given a high enough importance, it's often an after thought. Whereas really it should be at the very foundations of the design. I've given up now after trying time and time again. It really makes me wonder what credentials these reviewers actually have when they can make such poor judgements.
Comment 56 Jim Porter (:squib) 2011-11-01 19:18:15 PDT
(In reply to Lufferov from comment #55)
> I am dismayed at the state of software development in general these days.
> Usability simply isn't given a high enough importance, it's often an after
> thought.

Given that I (the original developer of the new attachment UI) also went out of my way to write the add-on to resolve this issue while we figure out if a statistically significant number of users are bothered by this, I think your characterization is inaccurate.

While I understand that the current UI is problematic for some people, that doesn't mean that you need to post advocacy comments on the bug to remind people of its existence. I'm well aware of this bug and have been tracking the usage share of the add-on on a daily basis. When we start getting Test Pilot studies up and running, I'll propose a study on the attachment UI to find the most common issues so that we can focus on those. If this is one of those issues, I'll push to get it fixed. However, I'm not going to change my stance just because individual people complain about it in the bug.

This will be my last comment on the matter until I have some news about the bug itself.
Comment 57 rsx11m 2011-11-02 06:20:06 PDT
(In reply to Jim Porter (:squib) from comment #56)
> Given that I (the original developer of the new attachment UI) also went out
> of my way to write the add-on to resolve this issue while we figure out if a

Not to mention those countless userChrome.css contributions from volunteers to work around this and other usability issues...  ;-)

> statistically significant number of users are bothered by this,

You still believe in add-on counts being a sufficient statistical indicator to determine whether or not it's a problem? It's as much "anecdotal" as numbers gathered from forum-post counts, as it only means that a specific number of users were directed in forum threads or knowledge base articles to the add-ons site and used the "official" way to download it so that it gets counted. While it may be one indicator among others, it won't tell you how many people got the add-on in some other way or used a userChrome.css workaround. Same with the magic Test Pilot, only people actually running it and participating get counted.

The underlying assumption that a single index alone provides sufficient diversity and statistical power to be considered significant enough for such UX decisions is just naive (and weren't applied to implement the features in question to start with).

But yes, we are going in circles, and it's mostly up to Blake where this bug goes.
Comment 58 Blake Winton (:bwinton) (:☕️) 2011-11-02 06:29:56 PDT
(Just to put a timeline on this, I'm snowed under with other things for the next week and a half, after which I'll start trying to deal with the things that are piling up while I'm ignoring them, so don't expect me to say anything on this for at least two weeks, and possibly longer.)
Comment 59 Jim Porter (:squib) 2011-11-02 22:13:01 PDT
Oh, just as a note: I unassigned myself not because I don't want to work on this bug, but because that's the only way I can avoid getting bugmail about it. If we decide to fix this, I'll come back and do it, but I'd rather avoid more email about this bug until then (I'm aware of the irony of this comment bugspamming everyone else CCed ;) ).
Comment 60 Jim Porter (:squib) 2012-02-23 14:05:39 PST
*** Bug 730073 has been marked as a duplicate of this bug. ***
Comment 61 Thomas D. (currently busy elsewhere; needinfo?me) 2012-05-03 14:46:43 PDT
Did you forget to vote for this bug?
18 users CC'ed, but only 7 votes?

The addon to address this problem is up to *4,351 users* (I think that's actual users, as opposed to download counts).

33 people on the getsatisfaction reports that have been tagged so far have the same problem.
Comment 62 Ben Bucksch (:BenB) 2012-08-07 04:16:37 PDT
This bug is highly annoying for me. Esp. with my fax->email gateway, which makes 2 attachments (one jpg overview, one PDF for full doc), and I have to make many clicks just to take a look at the faxed document.

There's a trivial fix, from from UI guidelines and code perspective: The twisty should remember the last state it had. If I left it open with the last message, the next message should start with it being open, not closed. People who want to hide many attachments can still do so, but all others save 1 click.
Comment 63 Blake Winton (:bwinton) (:☕️) 2012-08-07 06:17:59 PDT
That seems okay to me.  Do you have any time to whip up a patch that does that, Ben?
Comment 64 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-07 07:06:28 PDT
Created attachment 649635 [details]
Jim's Addon - customizable solution to make all users happy

Jim's addon [1] (21,000+ downloads and 4800+ users) provides a simple and fully customizable solution to make *all* users happy. Can't we just port that into core?

"Remember previous state" (boolean pref) is certainly better then the status quo. However, we cannot safely assume that a *per-message* choice (expanding or collapsing attachments for a single msg) is prejudicial for user's *general* preference of *initial default* status. Even if they end up manually expanding attachment pane more often than not, users might still want to *default* to the clean *initial UI* of collapsed attachment pane (or expanded). "Remember previous state" might be a good guess, but we will still get it wrong 50% of the time for *all* users.

Jim's solution is safe and sound for all types of users:

Provide a default choice of:
*Initial Status* when selecting a msg (*number pref* with values 1, 2, or 3):
1) Expanded (attachment pane always initially expanded)
2) Collapsed (attachment pane always initially collapsed)
3) Remember Previous (collapsed or expanded -> *boolean pref*)

[1] https://addons.mozilla.org/en-US/thunderbird/addon/attachment-options/
Comment 65 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-07 07:20:28 PDT
(In reply to Thomas D. from comment #64)
> Created attachment 649635 [details]
> Jim's Addon - customizable solution to make all users happy
> Provide a default choice of:
> *Initial Status* when selecting a msg (*number pref* with values 1, 2, or 3):
> 1) Expanded (attachment pane always initially expanded)
> 2) Collapsed (attachment pane always initially collapsed)
> 3) Remember Previous (collapsed or expanded -> *boolean pref*)

If someone implements Jim's addon into core, we could make "Remember Previous" the default if that's wanted - users can then change that to whatever they *really* want as an inital status for every message.
Comment 66 Matthew Atkinson 2012-08-07 07:38:56 PDT
First, I'd just like to say that Jim's addon is truly wonderful, and should be implemented into core. Before this bug went active again, I'd forgotten what a pain standard TB is without this add-on.

As well as remembering the state of the attachment pane, the add-on also allows hiding of the 'attachment bar', which is also extremely useful. If you've got the attachment pane visible. the attachment bar adds absolutely nothing useful or interesting (unless you can't count) and just wastes space. This should also be included.
Comment 67 Ben Bucksch (:BenB) 2012-08-07 08:10:42 PDT
Comment on attachment 649635 [details]
Jim's Addon - customizable solution to make all users happy

Thomas D, extensions are in general not suitable for adoption into core without major rework. If you want this to be integrated, you first to need a developer to adapt this.
Comment 68 Jim Porter (:squib) 2012-08-07 09:01:03 PDT
(In reply to Ben Bucksch (:BenB) from comment #67)
> Thomas D, extensions are in general not suitable for adoption into core
> without major rework. If you want this to be integrated, you first to need a
> developer to adapt this.

Given that I already have a patch attached to this bug that does most of this (with tests), it's really not that hard. However, I'm not going to spend time on this unless we have an agreement as to what exactly the patch should do (just remember the state? have an option for starting expanded/collapsed? have an option for expanded/collapsed/remember?).
Comment 69 Matthew Atkinson 2012-08-07 09:04:40 PDT
I vote for doing exactly what your add-on does. No more, no less.
Comment 70 Jim Porter (:squib) 2012-08-07 09:07:05 PDT
(In reply to Matthew Atkinson from comment #69)
> I vote for doing exactly what your add-on does. No more, no less.

Specifically, I'd like Blake's input, as he's the UI guy. (Also, I don't plan on adding other options like the ability to hide the attachment bar header.)
Comment 71 Blake Winton (:bwinton) (:☕️) 2012-08-07 09:40:11 PDT
Does anyone commenting here want the option to remember the previous state, or do people just want it to start expanded or start collapsed?
Comment 72 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-07 09:54:47 PDT
Comment on attachment 649635 [details]
Jim's Addon - customizable solution to make all users happy

(In reply to Jim Porter (:squib) from comment #70)
> (In reply to Matthew Atkinson from comment #69)
> > I vote for doing exactly what your add-on does. No more, no less.
> 
> Specifically, I'd like Blake's input, as he's the UI guy. (Also, I don't
> plan on adding other options like the ability to hide the attachment bar
> header.)

Thanks Jim for repeatedly confirming your willingless to implement this (as already announced in comment 59).

So I suppose the easiest way to ask for Blake's UI input is to ask for ui-review of the addon (21000+ downloads, 4800+ users), where the proposed UI of tri-state default pref can be seen in action (always collapsed | always expanded | remember previous). See my comment 64 why *only* having "remember previous" as a one-for-all default is not sufficient to make all users happy (but it might make might a good default per Ben's comment 62; either that or "always collapsed").

Per my comment 52, I'm OK to skip the addon option of hiding attachment bar (I don't mind having that option, either, and it might be useful for many users; but perhaps it's currently a bit difficult to get the bar back).
Jim's addon still provides superior UX even without that option.

There's no-one who knows attachment pane better than Jim, so here's a once-in-a-lifetime chance for seamless quality code to get this "right" and customizable without any drawbacks that I am aware of.
Comment 73 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-07 10:28:02 PDT
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #71)
> Does anyone commenting here want the option to remember the previous state,
> or do people just want it to start expanded or start collapsed?

I agree with Ben's comment 62 that "remember previous" is a very useful behaviour, and perhaps even a good default (if complemented by "always collapsed" and "always expanded" as alternative options). It's the UX concept of semi-permanently toggling the visibility of the entire pane, similar to F8 to toggle the preview pane, or F9 to toggle contact side bar in composition (and, in support of tri-state, we've already seen requests that the contact sidebar should also have an option of "always initially expanded" even if the user happens to close it for the current composition): You switch it on, it stays for so long, you switch it off, it's out of the way. That's pretty good, and pretty simple, only that some of us need more control to accomodate for their legitimately different use patterns.

I beg to consider that attachment pane is not some negligible remote corner of a mailer; it is one of the most heavily used parts of message reader UI.
Technically, we need at least one pref if we want to give users a choice anyway (initialStatePref); having a second pref to fine-tune the behaviour (previousStatePref) really isn't too much given the importance of that UI part. Interaction of those two prefs is straightforward, the code has been tried in the addon, and Jim knows what he is doing. UI-wise, imo no problem either to have 3 self-explaining submenu options instead of 2. Now more than ever we should strive to make all users happy.
Comment 74 Matthew Atkinson 2012-08-07 10:33:49 PDT
(In reply to Thomas D. from comment #72)

> Per my comment 52, I'm OK to skip the addon option of hiding attachment bar
> (I don't mind having that option, either, and it might be useful for many
> users; but perhaps it's currently a bit difficult to get the bar back).
> Jim's addon still provides superior UX even without that option.
> 

Leaving out the option to remove the rather pointless attachment bar seems rather to miss the point of Thomas D.'s last paragraph. 

It's not difficult to get the bar back, you just right click and select Show Attachment Bar. If you've worked out how to remove it, you'll work out how to get it back.

If you have the attachments pane always showing, the bar is completely pointless. It only has any value if the attachments pane is hidden, and really is only of any use for people who get tens of attachments at once but rarely want to open any of them (are there many people in that category?). For anyone else who usually gets between 1 and 4 attachments at once, replacing the bar with the pane makes the whole thing easier to use.
Comment 75 Jim Porter (:squib) 2012-08-07 11:06:29 PDT
(In reply to Thomas D. from comment #73)
> (In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #71)
> > Does anyone commenting here want the option to remember the previous state,
> > or do people just want it to start expanded or start collapsed?
> 
> [snip]

None of this really explains why someone would prefer the "remember state" pref over the other two. I think predictability is more useful in this case, since people who don't like the current default are complaining because they expect the attachment pane to start out expanded. Remembering the previous state only helps them if the user remembers to keep the attachment pane in the state they want. I suspect that what people want, based on this bug and comments I've seen about the add-on, that what they want is to set the initial state, and then sometimes *temporarily* expand (or collapse) the pane, either to get at the attachments, or to free up more space for the message body.

As for the behavior of the contacts pane in the composer (which is to remember the state), that's not a very good UX either. We should probably consider changing that too (I'd suggest dropping the "remember state" code entirely), but that's another bug.

From a code perspective, adding a "remember state" pref is more complicated than just adding the ability to start out expanded, and unless people actually want to *use* that option, we shouldn't add it. Eliminating that option also simplifies the UI down from a submenu with 3 options to a single checkbox.

(In reply to Matthew Atkinson from comment #74)
> If you have the attachments pane always showing, the bar is completely
> pointless.

Not so. Part of the reason we added the attachment bar is because user studies have shown that users had a hard time finding the attachments for a message; that's why we're careful to include both a paperclip icon and the word "attachment" on the attachment bar. The attachments pane also includes the "Save"/"Save All" button, which is quicker and more obvious than using context menus or keyboard shortcuts. It also provides an easy way to collapse the pane if you want more space for the message. The only case where there's real redundancy is if you receive exactly one attachment.

Besides that, hiding the attachment bar is easy to do with userChrome, whereas expanding the attachment pane is less easy.

In any case, I'm not handling this the same way as the Attachment Options add-on, since the UI in that isn't very good. Hiding the attachment bar isn't a part of this bug though; please file a followup to discuss it so we don't get sidetracked.
Comment 76 Ben Bucksch (:BenB) 2012-08-07 11:20:11 PDT
> Does anyone commenting here want the option to remember the previous state,
> or do people just want it to start expanded or start collapsed?

I want it always start expanded.

However, UI guidelines suggest "direct manipulation", i.e. not having a separate prefs UI, but that you can directly interact with the UI and it does what you want. If we have to support 2 states, I think the most natural way is to simply remember state, and no preference UI.

Coincidentally, the implementation should be trivial: Just add XUL attribute
persist="collapsed"
(or whatever the attribute name is).
Comment 77 Jim Porter (:squib) 2012-08-07 11:35:31 PDT
(In reply to Ben Bucksch (:BenB) from comment #76)
> > Does anyone commenting here want the option to remember the previous state,
> > or do people just want it to start expanded or start collapsed?
> 
> I want it always start expanded.
> 
> However, UI guidelines suggest "direct manipulation", i.e. not having a
> separate prefs UI, but that you can directly interact with the UI and it
> does what you want.

The UI I'm planning on for this is an option when you right-click the attachment bar. I think that keeps us pretty close to "direct manipulation" and lets us avoid the issue where someone really only meant to temporarily show/hide the attachment pane and expects the next message to be back to normal. Another UI option would be a pin icon, but I don't expect people would want to change the initial state often enough for that to be useful.

> Coincidentally, the implementation should be trivial: Just add XUL attribute
> persist="collapsed"
> (or whatever the attribute name is).

There's no attribute name for it, since it relies on Javascript to determine the optimal size for the pane. It's conceivable that we could make this work via attributes, but it would be more work than just storing the state in a pref.
Comment 78 Jim Porter (:squib) 2012-08-11 01:27:00 PDT
Created attachment 651108 [details] [diff] [review]
Updated patch

Ok, here's the patch. I'm not sure about the string. Does anyone have any better ideas? Also, when toggling the menuitem, do you think we should also set the attachment pane's state to correspond? That is, if you turn off "Start Hidden", should it expand the attachment pane?
Comment 79 Blake Winton (:bwinton) (:☕️) 2012-08-12 17:52:29 PDT
Comment on attachment 649635 [details]
Jim's Addon - customizable solution to make all users happy

Since Jim has an actual patch, I won't be reviewing this attachment.
Comment 80 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-12 23:29:46 PDT

(In reply to Jim Porter (:squib) from comment #78)
> Created attachment 651108 [details] [diff] [review]
> Updated patch
> 
> Ok, here's the patch. I'm not sure about the string. Does anyone have any
> better ideas? Also, when toggling the menuitem, do you think we should also
> set the attachment pane's state to correspond? That is, if you turn off
> "Start Hidden", should it expand the attachment pane?

(In reply to Jim Porter (:squib) from comment #75)
> (In reply to Thomas D. from comment #73)
> > (In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #71)
> > > Does anyone commenting here want the option to remember the previous state,
> > > or do people just want it to start expanded or start collapsed?
> > 
> > [snip]
> 
> As for the behavior of the contacts pane in the composer (which is to
> remember the state), that's not a very good UX either. We should probably
> consider changing that too (I'd suggest dropping the "remember state" code
> entirely), but that's another bug.

+1

> From a code perspective, adding a "remember state" pref is more complicated
> than just adding the ability to start out expanded, and unless people
> actually want to *use* that option, we shouldn't add it. Eliminating that
> option also simplifies the UI down from a submenu with 3 options to a single
> checkbox.

I agree it's hard to resist that charming simplicity :)
Jim, could you attach a screenshot with that context menu in action?
Comment 81 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-12 23:48:38 PDT
...forgot to reply this one:

(In reply to Jim Porter (:squib) from comment #78)
> Created attachment 651108 [details] [diff] [review]
> Ok, here's the patch. I'm not sure about the string. Does anyone have any
> better ideas?

Not really. With the string being "Start hidden", is it clear enough from context that this is about attachments and not something else?

If not, perhaps:
2) "Initially hide attachments" (still reasonable, I think)
or
3) "Start with attachments hidden"

Too long? Well then, back to square 1) "Start hidden"... ;)
("Hide attachments" would be too ambiguous; might be confused with the temporary toggle, especially if we add immediate UX-feedback and also toggle the state)

> Also, when toggling the menuitem, do you think we should also
> set the attachment pane's state to correspond? That is, if you turn off
> "Start Hidden", should it expand the attachment pane?

Sounds good to me (though I'd have to test that in action to really tell):
- immediate UX-feedback as a way of confirming the user's change of initial status
- if we don't provide that feedback, user might have to unnecessarily switch to another message to see if the new setting works as intended (especially if we have a shorter and somewhat context-less wording like "Start hidden")
- the "new" state is what the user just chose as a preference anyway, so we can safely assume he prefers that for the current message, too...
Comment 82 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-12 23:58:48 PDT
(In reply to Thomas D. from comment #81)
> With the string being "Start hidden", is it clear enough from
> context that this is about attachments and not something else?

Given that "Start hidden" is a context menu *on attachment bar* (and on attachment pane whitespace), could this be misunderstood as "Start with *attachment bar* hidden" (a plausible potential desire for those who start with the pane always expanded)?

-> Slight tendency in favour of
2) "Initially hide attachments"
Comment 83 Jim Porter (:squib) 2012-08-13 00:19:12 PDT
Some thoughts on the string. We have tooltips that say "Show/Hide the attachment pane", so we should reuse that terminology if possible. Some ideas along those lines:

"Initially Hide Attachment Pane"
"Start Attachment Pane Hidden"

We could also change the verbs to Expand/Collapse, which might make the phrasing clearer.
Comment 84 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-13 00:53:46 PDT
(In reply to Jim Porter (:squib) from comment #83)
> Some thoughts on the string. We have tooltips that say "Show/Hide the
> attachment pane", so we should reuse that terminology if possible.

+1, consistent termminology very welcome.

> Some ideas along those lines:
> "Initially Hide Attachment Pane"

Nice. How does that look in a context menu (screenshot)?

> "Start Attachment Pane Hidden"

Not sure if that's grammatical, or at least it tweaks the meaning somewhat into "Start the Attachment Pane as hidden"
Whereas what we want to say is
"Start [the message] with attachment pane being hidden"
So the grammatically more correct version would be
"Start *with* Attachment Pane Hidden"
...which starts getting too long. I like the simple word "start", but I think "Initially" is the better choice here (more concise, more correct)

> We could also change the verbs to Expand/Collapse, which might make the
> phrasing clearer.

I recall we decided to prefer the simple language version (hide/show) for the tooltips, so if we want to be consistent here, we'd have to stick with that. My guess is that hide/show will also result in more natural translations.
otoh, expand/collapse are equally correct & precise terms.
Comment 85 rsx11m 2012-08-15 06:37:09 PDT
Jim, Blake - thanks for getting back to this bug. I like the idea of putting this into the context menu, thus making it better visible than a checkbox in an options dialog. As another option, how about switching from negative to positive logic?

Thus, reversing the check's logic by making it "Show always" or "Keep open" which may be more intuitive than the "hide" phrasing? On the other hand, it may raise the expectation that the check is cleared when explicitly closing the attachment pane, which may not be intended (e.g., when closing the pane for a message with a lot of attachments to see the message text, I'd like to still be shown again when opening the next message).
Comment 86 Ben Bucksch (:BenB) 2012-08-15 06:39:20 PDT
> "Show always" or "Keep open" which may be more intuitive than the "hide" phrasing?

+1
Comment 87 Blake Winton (:bwinton) (:☕️) 2012-08-15 09:11:34 PDT
Comment on attachment 651108 [details] [diff] [review]
Updated patch

>+++ b/mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd
>@@ -64,16 +64,18 @@
> <!-- Attachment context menu items -->
>+<!ENTITY startCollapsedCmd.label    "Start Hidden">
>+<!ENTITY startCollapsedCmd.accesskey    "H">

I think I'ld go with "Show attachment pane", or better, "Initially show attachment pane" to mimic the tooltip.
http://dl.dropbox.com/u/2301433/Screenshots/ShowAttachmentPane.png
And given that we have "Open message in New Window", and "Open message in Conversation" in another context menu, I'm not worried about either of those strings being too long.

The code also seems fine, so with that change, ui-r=me, and r=me.

Thanks,
Blake.
Comment 88 Thomas D. (currently busy elsewhere; needinfo?me) 2012-08-15 15:05:52 PDT
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #87)
> Comment on attachment 651108 [details] [diff] [review]
> I think I'ld go with "Show attachment pane", or better, "Initially show
> attachment pane" to mimic the tooltip.
> http://dl.dropbox.com/u/2301433/Screenshots/ShowAttachmentPane.png

Including "Initially" (or something equivalent) is crucial to avoid UX-misunderstandings that this option represents the current (temporary) status of the pane. "Initially show attachment pane" sounds good to me.
Comment 89 Jim Porter (:squib) 2012-08-15 22:55:48 PDT
Checked in: http://hg.mozilla.org/comm-central/rev/fe4a51cb38b4

Note You need to log in before you can comment on or make changes to this bug.