1427092 - [META] Improve composition's attachment pane UX with discoverable, efficient, always-available and stable in-place attachment actions

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #707432 +++

Composition's attachment header bar is currently informative, but not helpful as it's not interactive. This RFE is here to change that and make it helpful and smart with in-place functionality. This comes with significant improvements of ux-efficiency, ux-discovery, and ux-consistency, in an ux-minimalist implementation which blends in seamlessly with the existing UI at a near-zero cost.

For a start, I've often wished to just click on the header for adding more attachments or accessing the attachment list context menu.
While we are here, let's also massage the bucket whitespace click behaviour to be more useful, correct, and transparent, including tooltips.
This realizes some of my orthogonal proposal of bug 707432 and is somewhat similar to Bug 680695 where I made message reader's attachment header more interactive.

Enhancements (as implemented in the upcoming patch, pls try it!):

1) Convert "3 Attachments" label into a split menu button
   * Main button part: Attach File(s) (highly discoverable and conveniently in-place!)
   * Dropdown button part: Attachment list context menu (which ensures easy access and discovery even when there is no attachment pane whitespace).
   * Tooltip: "Attach File(s)"
2) Add paperclip icon to attachment header (consistent with message reader and the existing attach button)
3) Dynamically replace useless "0 attachments - 0 bytes" header with plain vanilla "Attach" button. (And I'm thinking to put an [x] button at that blank space where we would normally show the total size, allowing user to close the pane when there are no attachments).

4) Add "Remove All Attachments" menu item to attachment list context menu (also exposed on the split button dropdown menu; new command: cmd_removeAllAttachments).

5) Preserve keyboard shortcut Alt+M to focus attachments pane and expose it in Edit Menu (where most other attachment related commands are); new command: Focus Attachment Pane (cmd_focusAttachmentPane).
6) Alt+M aka cmd_focusAttachmentPane now helpfully shows the attachment pane even when it's hidden, providing a convenient starting point for adding attachments
7) Allow click on header blank space, total size label to focus attachment pane (as it was possible before by clicking on the "3 Attachments" label), and add a tooltip to expose this functionality: "Attachments pane"

8) For attachment pane whitespace, restore "single-click-to-attach-file(s)" functionality and expose it with a tooltip: "Attach File(s)"
9) While there are *selected* attachments, the first left-click on attachment pane whitespace must clear selection; dynamically adjust tooltip accordingly: "Clear Selection"

Comment 1

[Thomas D. (:thomas8)]

Attachment: Patch V.1: Meet the interactive attachments pane header (and overall polish)

Richard, this implements all the goodness exactly as described in comment 0.

Could you please assist with a bit of CSS:
- push the button upwards a bit (so that the edge of the header is on same level with the long "From" line, as in current release version)
- push the button to the left a bit (so that the paperclip icon is centered above the attachment icons).

Comment 2

[Thomas D. (:thomas8)]

Note to self:

cmd_selectAll should be disabled when there are no attachments:

var attachmentBucketController = {
  commands: {
    cmd_selectAll: {
      isEnabled: function() {
        return (attachmentsCount() > 0);
      },

Comment 3

[Thomas D. (:thomas8)]

Attachment: Patch V.1.1 (needs attachment 8938896): Meet the interactive attachments pane header, and overall polish (- bug 1427037, + cmd_selectAll isEnabled fix)

Comment 4

[Thomas D. (:thomas8)]

Comment on attachment 8938919 [details] [diff] [review]
Patch V.1.1 (needs attachment 8938896 [details] [diff] [review]): Meet the interactive attachments pane header, and overall polish
(- bug 1427037, + cmd_selectAll isEnabled fix)

Updated patch, to be applied on top of bug 1426344, attachment 8938896 [details] [diff] [review].

Removed one hunk which fixed bug 1427037, now included in bug 1426344 so that we get shortcut issues out of the way.

Updated command enabling of cmd_selectAll to be disabled when there are no attachments (fixes pre-existing bug). This command is useful for mouse-only workflows, e.g. with many attachments for dragging all of them somewhere. That's currently about the only thing to do with *all* attachments, as we now have cmd_removeAllAttachments for doing that, and currently unfortunately we don't allow any other actions on all/multiple attachments.

Comment 5

[Thomas D. (:thomas8)]

Comment on attachment 8938919 [details] [diff] [review]
Patch V.1.1 (needs attachment 8938896 [details] [diff] [review]): Meet the interactive attachments pane header, and overall polish
(- bug 1427037, + cmd_selectAll isEnabled fix)

sorry for the noise

Comment 6

[Richard Marti (:Paenglab)]

Patch V.1 is obsolete, correct?

Comment 7

[Thomas D. (:thomas8)]

Comment on attachment 8938883 [details] [diff] [review]
Patch V.1: Meet the interactive attachments pane header (and overall polish)

(In reply to Richard Marti (:Paenglab) from comment #6)
> Patch V.1 is obsolete, correct?

Yeah, but changes are trivial, so if you want to apply only one patch without applying the other patch first, it should still work.

Comment 8

[Thomas D. (:thomas8)]

Attachment: Patch V.1.2 (needs attachment 8938896): Meet the interactive attachments pane header, incl. polished bucket behaviour (nitfix: Alt+M/Ctrl+M)

This adds the Alt+X/Ctrl+M (Win/MAC) keyboard shortcut which was missing in the previous patch.

Comment 9

[Thomas D. (:thomas8)]

Comment on attachment 8938933 [details] [diff] [review]
Patch V.1.2 (needs attachment 8938896 [details] [diff] [review]): Meet the interactive attachments pane header, incl. polished bucket behaviour (nitfix: Alt+M/Ctrl+M)

Still incorrect with duplicate cmd_reorderAttachments in command controller.

Comment 10

[Thomas D. (:thomas8)]

Attachment: Patch V.1.3 (needs attachment 8938896): Meet the interactive attachments pane header, incl. polished bucket behaviour (nitfix: - duplicate cmd_reorderAttachments)

We're getting there... this should rectify the commands in command controller

Comment 11

[Richard Marti (:Paenglab)]

Comment on attachment 8938934 [details] [diff] [review]
Patch V.1.3 (needs attachment 8938896 [details] [diff] [review]): Meet the interactive attachments pane header, incl. polished bucket behaviour (nitfix: - duplicate cmd_reorderAttachments)

Works good, what I tested and all makes sense you added. :)

Comment 12

[Richard Marti (:Paenglab)]

Attachment: Patch V.1.3.1 (needs attachment 8938896): Meet the interactive attachments pane header, incl. polished bucket behaviour (nitfix: - duplicate cmd_reorderAttachments) with CSS added

Thomas, this is your code added with the needed CSS styles.

It's not possible to make the button the same height because the identity menulist uses the bottom border directly as his own border and it would look weird when the attachment list border would partly used as button border. But my solution should work too.

Comment 13

[Thomas D. (:thomas8)]

Comment on attachment 8938948 [details] [diff] [review]
Patch V.1.3.1 (needs attachment 8938896 [details] [diff] [review]): Meet the interactive attachments pane header, incl. polished bucket behaviour (nitfix: - duplicate cmd_reorderAttachments) with CSS added

Awesome!!! So I think this is ready to go...

Comment 14

[Richard Marti (:Paenglab)]

Comment on attachment 8938948 [details] [diff] [review]
Patch V.1.3.1 (needs attachment 8938896 [details] [diff] [review]): Meet the interactive attachments pane header, incl. polished bucket behaviour (nitfix: - duplicate cmd_reorderAttachments) with CSS added

ui-r+ but what should be added, is the accessibility through keyboard. The button should be accessible either through tabbing or a access key. The access keys in the popup make now not much sense when the popup can't be opened through keyboard.

This patch does no more apply after bug 1426344. I'll attach one which applies.

Comment 15

[Richard Marti (:Paenglab)]

Attachment: 1427092_composeAttachmentHeaderButton.patch v1.3.1.1

Updated to tip and gave a revision level more ;)

Comment 16

[Thomas D. (:thomas8)]

Attachment: Patch Variant A, V.2: Implement Interactive attachments pane header, add cmd_removeAllAttachments, polish bucket behaviour

Updated patch. Now requires bug 1427037.

Unfortunately, I was not aware of Richard's new patch coming in while I was also working on this. Richard, did you change anything else apart from just updating because such changes would not be included in this patch?

It would be great to get reviews from both Aceman and Jörg for this, especially for the changes to removeAllAttachments() function.

Eventually, we'll also need someone to actually test all of our new attachment pane goodies with "file link" attachments.

Changes:
* update to tip
* fixed RemoveAllAttachments() routine which was unused before this bug and not maintained, now in sync wit RemoveSelectedAttachment().
* nitfixed some command controllers' isEnabled conditions
* polished attachments header bar CSS (Windows only)

Richard, let's not squeeze the new button for a false sense of alignment with the sender in "From" field. I think it looks much better, more relaxed and generous like this. Also consistent and in perfect symmetry with the "Contacts" title of contacts side bar on the left. There is no structural difference between those two bars, so we'll be more pleasing to the eye to keep them in sync and adhere to our visual standards for titlebars/toolbars. It's also better now because we offer a normal-size click target, just like any other button out there. Squeezing the button at the bottom of the attachment header bar looks like "gewollt und nicht gekonnt" (we've tried, but failed to get it right).

I've long wondered why that caption "3 attachments" looks so stuck-on and somewhat lost or out-of-place. It's because it's really "out-of-place".
This is a proper title on a proper header bar, more so now as a toolbar button. Titles and toolbar buttons are always vertically centered on their bars.
Sender is quite far away and there's not much reason to expect alignment with that. Our big lines are perfectly aligned, that's what meets the eye immediately.

Comment 17

[Richard Marti (:Paenglab)]

No, it was only updated to tip.

Comment 18

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #16)
> Created attachment 8939105 [details] [diff] [review]
> Richard, let's not squeeze the new button for a false sense of alignment
> with the sender in "From" field. I think it looks much better, more relaxed
> and generous like this. Also consistent and in perfect symmetry with the
> "Contacts" title of contacts side bar on the left. 

Btw, my proposal also makes the attachment header bars of (a draft in) message reader and composition look consistent, which also reduces visual processing load and improves recognition (Wiedererkennungseffekt in German, English is so boring... :p)

Comment 19

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #14)
> Comment on attachment 8938948 [details] [diff] [review]
> Patch V.1.3.1 (needs attachment 8938896 [details] [diff] [review]): Meet the
> interactive attachments pane header, incl. polished bucket behaviour
> (nitfix: - duplicate cmd_reorderAttachments) with CSS added
> 
> ui-r+ but what should be added, is the accessibility through keyboard. The
> button should be accessible either through tabbing or a access key.

We can consider that in another bug, unless if someone can share with me a simple way how to do that.
There's a bug (similar to what I fixed in contacts side bar, we should really fix this somewhere deeper one day):
Right-click without any attachment selected must show list context, not item context. That's the main access problem here. N

Not every button must be keyboard accessible as long as all the functions are keyboard-accessible somewhere.
Accessibility of attachment list context menu isn't worse than before (it's now much better for mouse users); it might be clumsy but all commands are keyboard-accessible (e.g. File > Attachments menu).
 
I deliberately did not add "Remove All Attachments" to "Edit" menu because we're already occupying a lot of space there, and having all of "Select All", "Remove Attachments", AND "Remove All Attachments" would be somewhat redundant.

> The access keys in the popup make now not much sense when the popup can't be
> opened through keyboard.

Yes, that's the pre-existing bug I described above.

> This patch does no more apply after bug 1426344. I'll attach one which
> applies.

Thank you, unfortunately I wasn't aware so we were doing the same thing at the same time.

Comment 20

[Jorg K (CEST = GMT+2)]

Comment on attachment 8939105 [details] [diff] [review]
Patch Variant A, V.2: Implement Interactive attachments pane header, add cmd_removeAllAttachments, polish bucket behaviour

Hmm, I've tried this, but I'm not really so enthused. I think you're overloading the UI with options that are available elsewhere:
"Select All" is Ctrl+A, or Click, Shift+Click. BTW, what would you do with select all, if not remove?
"Attach File", "Attach Web Page", "Remind me later" are on the Attach button.
"Reorder Attachments" is on the right-click/context menu.
"Remove All" is "Select All", hit delete.

What about UX economy and orthogonality? Do we need to offer so many functions that we need to maintain later on?

Sigh, I'd much rather have some product planning and focus development effort where it is desperately needed instead of over-polishing and over-loading the product. But sadly you can't tell volunteers what they should do.

Since Magnus is also UX peer these days, he should let us know what he thinks of this.

Comment 21

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #20)
> Comment on attachment 8939105 [details] [diff] [review]
> Patch V.2 (needs attachment 8939061 [details] [diff] [review]): Implement
> Interactive attachments pane header, add cmd_removeAllAttachments, polish
> bucket behaviour
> 
> Hmm, I've tried this, but I'm not really so enthused. I think you're
> overloading the UI with options that are available elsewhere:

Answered in private mail with some more emotion.

> "Select All" is Ctrl+A, or Click, Shift+Click.

What about mouse-only? There are different types of users we have to cater for.

> BTW, what would you do with select all, if not remove?

Drag and drop.

> "Attach File", "Attach Web Page", "Remind me later" are on the Attach button.

Yes, freaking far away on the far left, completely disconnected from the panel. Annoying every day.

> "Reorder Attachments" is on the right-click/context menu.
> "Remove All" is "Select All", hit delete.

I thought you don't like "Select All"?

> What about UX economy and orthogonality? Do we need to offer so many
> functions that we need to maintain later on?

UX-minimalism is not an end in itself, it must be weighed against UX-discovery and UX-efficiency. Redundancy is a natural by-product of UX-efficiency, and we have that everywhere. UX-efficiency is our brand core.
But I'm not violating UX-minimalism here, on the contrary: This smoothly fitting, low-noise UI is a perfect blend scoring on all 3 criteria. There is no maintenance burden worth speaking of.

> Sigh, I'd much rather have some product planning and focus development
> effort where it is desperately needed instead of over-polishing and
> over-loading the product. But sadly you can't tell volunteers what they
> should do.

Thank God you can't! Pls just let me do what I'm best at doing, it's not nice to feel guilty for volunteering (and pls don't exaggerate, I'm certainly NOT overloading the PRODUCT with a paperclip and a 3mm dropdown arrow), I'm here to enjoy myself and as an advocate of improved UX for both keyboard and mouse users. There's nothing wrong with polishing, and I'm not seeing many others into this sort of thing.
That said, I've also fixed and caused/prepared fixes to a good lot of functional bugs in various areas, going quite deep into the code, and still going deeper every time. I'm doing my best, but I'm not getting paid (that's exclusively about ME), so it's fun and success and love for the product (or even frustration about its shortcomings) which keeps me going. Thank you for understanding.

> Since Magnus is also UX peer these days, he should let us know what he
> thinks of this.

Sure. This already has ui-r+ from Richard, without any discussion or complaints. I'm open for any second opinions which are transparently and evidently based on UX-principles. I'd also appreciate if my painstaking UX-analysis is fully understood (which requires *reading* first), considered, and responded to. I'm not just randomly planting buttons and piling up menus, a lot of thought has gone into this. I believe the net result looks great and will be highly useful to many users at a near-zero cost (assuming you're not against the ux-consistent branding of the paperclip, we're talking about a 3mm dropdown arrow in the primary UI, conveniently exposing the existing attachment list context menu, which is otherwise hard to get at)...

Btw, "in-place" UI is another fundamental UX principle...
Pls try it for some time before you trying to shoot it down - you might very well end up loving it, as you did with the new interactive language button in composition's status bar, which follows exactly the same motivations/principles as our button here. As for myself, after only two days of using this, I'd never want to go without...

Comment 22

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere) from comment #21)
> > BTW, what would you do with select all, if not remove?
> Drag and drop.
Hmm, you're dragging the attachments out after just attaching them?? I think that's a very unlikely use case.

> > Sigh, I'd much rather have some product planning and focus development
> > effort where it is desperately needed instead of over-polishing and
> > over-loading the product. But sadly you can't tell volunteers what they
> > should do.
> Thank God you can't! Pls just let me do what I'm best at doing, it's not
> nice to feel guilty for volunteering ...
This comment wasn't meant personal and no one needs to feel "guilty" about volunteering, quite the opposite. However, lack of product planning and total lack of people who accept orders is absolutely fatal to the product. It is an absolute embarrassment that for example bug 519202 and "friends" isn't fixed in almost a decade (I had to revisit it yesterday to give it more "friends"). Personally I'd like to see (volunteer) effort applied broadly and not just to some areas. And whilst I understand that volunteers work for their own "enjoyment", keeping TB on the road an bugs at bay isn't all that joyful. People who consider themselves part of the "core team" should accept a minimum amount of overall product responsibility.

Again, nothing of this is to be taken personally. I think the "reorder attachments" function is great and you've contributed many improvements lately that were mentioned in the release notes. Only, IMHO, this new function is a little "over the top".

Comment 23

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #22)
> (In reply to Thomas D. (currently busy elsewhere) from comment #21)
> > > BTW, what would you do with select all, if not remove?
> > Drag and drop.
> Hmm, you're dragging the attachments out after just attaching them?? I think
> that's a very unlikely use case.

Forwarding/edit as new/you name it of a message (business, confidential, whatever), or collecting attachments from various folder locations into the message first, then I realize I want to double-check if I really attached the right things. You never know what people do - unlikely or not (which we don't really know) if it's technically possible, we must get it right. Dragging them them out will not remove them, but copy them to the target folder, that's a simple and safe way of looking at my attachments, given all the bugs in TB which can make me end up with the wrong version or spoiling my original files.

> > > Sigh, I'd much rather have some product planning and focus development
> > > effort where it is desperately needed instead of over-polishing and
> > > over-loading the product. But sadly you can't tell volunteers what they
> > > should do.
> > Thank God you can't! Pls just let me do what I'm best at doing, it's not
> > nice to feel guilty for volunteering ...
> This comment wasn't meant personal

Good to know, because "focus... instead of over-polishing and over-loading the product" in the context of this bug did sound pretty personal, but in the sense of "a bit over the top" it's certainly your own opinion to which you are entitled.

> and no one needs to feel "guilty" about
> volunteering, quite the opposite. However, lack of product planning and
> total lack of people who accept orders is absolutely fatal to the product.
> It is an absolute embarrassment that for example bug 519202 and "friends"
> isn't fixed in almost a decade (I had to revisit it yesterday to give it
> more "friends").

You are 100% right about the embarrassment part, and I believe after almost 9000 comments of mine and almost 4000 bugs poked I am certainly in an excellent position to understand your sense of frustration.

Trust me, if I had reason to believe that I could fix some of Thunderbird's search bugs with my personal programming skillset and without losing my sanity and an even more abnormal amount of life time, I would probably try it. I was actually looking at the mime line parser yesterday where you said it's doing the wrong thing when looking for HTML tags, and figured this would probably be too deep for me to fix in a language which I don't know.

> Personally I'd like to see (volunteer) effort applied
> broadly and not just to some areas. And whilst I understand that volunteers
> work for their own "enjoyment", keeping TB on the road an bugs at bay isn't
> all that joyful. People who consider themselves part of the "core team"
> should accept a minimum amount of overall product responsibility.

Fortunately, given my continuous volunteer engagement since 2007, with almost 22.000 activities on TB and Mailnews core bugs alone, and thousands of comments on thousands of bugs in all products (see above), in addition to many other activities for the project, I have definitely accepted an extraordinary *maximum* of "overall product responsibility" so there's really no way I should or could take this personal, member of the core team or not, just because I'm not fixing exactly the type of bugs from the unlimited pool of TB bugs which you'd personally like to see fixed (and you're not wrong)...

Different people, different skills, different preferences and benefits to the project... I strongly believe that UX matters, and I've got something to give in that area. Workflow impediments for everyday tasks like attachments do affect our users including myself, and I've got the right skillset to fix some of them in a limited amount of time, so I'm more motivated and in a better position to do that... Dedicating my personal time to UX is NOT irresponsible to the project, after all what I've done already in the last decade.

> Again, nothing of this is to be taken personally. I think the "reorder
> attachments" function is great and you've contributed many improvements
> lately that were mentioned in the release notes. Only, IMHO, this new
> function is a little "over the top".

If you'd avoid exaggerations like "over-loading the product" and the personal political talk in public about what volunteers of a certain calibre should or shouldn't do in your opinion, that would go a long way to focus on the matter at hand in an objective manner and avoid needless and undesirable personal escalations. Thank you.

Comment 24

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere) from comment #21)
> > "Select All" is Ctrl+A, or Click, Shift+Click.
> What about mouse-only? There are different types of users we have to cater
> for.
They can use the context-menu.

Remove all attachments: Select all, remove attachments. To add an attachment, you can double-click into the bucket.

I really don't see the point repeating things from the context-menu on a pull-down in very close proximity.

Weniger ist mehr! And KISS.

Comment 25

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #24)
> (In reply to Thomas D. (currently busy elsewhere) from comment #21)
> > > "Select All" is Ctrl+A, or Click, Shift+Click.
> > What about mouse-only? There are different types of users we have to cater
> > for.
> They can use the context-menu.

Oh can they, really? With our default settings, and without further user intervention, after adding only 5 attchments, the click target for *list* context menu becomes so small as to be inconvenient. Starting from 6, your click target for the list context menu is *gone* unless you start dragging your entire header UI bigger, which is neither intuitive nor efficient nor nice, because it'll take up a lot of your screen real estate, so you also have to drag it back when you're done. Sadly, getting at the list context menu is hardest when its most needed, with more attachments. With my tiny addition of the dropdown arrow (again, we're talking 3mm for a tiny triangle on the header bar), attachment *list* context menu will be:
- highly discoverable
- in a stable position
- click target always available, never hidden, no clumsy extra moves to find your list whitespace
- intuitive/no-brainer

> Remove all attachments: Select all, remove attachments.

Why 3 clicks when with "Remove All Attachments" command, and only 6 items in the list including that, we can get the same action wit only 2 clicks? It's just more convenient, and the costs are low.

> To add an attachment, you can double-click into the bucket.

Oh, can you really? Dito, starting from 5 attachments, you can't without fiddling with your entire header area. And again, why waste my focus trying to find whitespace, when I can just have the same thing at a convenient, persistent position?
Also, I'm not sure if clicking on whitespace to add attachments is immediately intuitive, although I've made it more discoverable with tooltips now...
Btw, I've reverted this to single-click again which is current behaviour, only with selected attachments you have to click twice. Inconvenient again: sometimes one, sometimes 2 clicks. I'd much prefer that big click target of "3 attachments", which turns into a button exactly when I need it.

What you are demonstrating here very well is that without the dual button, every action needs a different approach, i.e. a lot of user attention: sometimes two-step (opening context menu twice), sometimes single-step, sometimes single-click, sometimes double-click, sometimes context menu, sometimes whitespace, sometimes dragging my header pane around to create whitespace first, then right-click, then left-click... Whereas with the dropdown of the header button, everything becomes a no-brainer: just 1 click away, at a stable and never hidden spot, conveniently and neatly presented in a single (context) menu at your fingertips exactly when you need it. When you don't need it, it doesn't disturb you. That sounds like a perfect congruence of ux-discovery, ux-efficiency and ux-minimalism to me...

> I really don't see the point repeating things from the context-menu on a
> pull-down in very close proximity.

Starting from 5 or 6 attachments in your list, it's no longer "in very close proximity", but a hassle, as I've shown above.
So I really don't see the point of NOT having a 3mm dropdown arrow which comes with so much comfort and convenience.

Btw, the dropdown arrow also helps to discover the main button part for adding attachments, which is otherwise much less discoverable. And that's the best part: There couldn't be any more convenient spot of adding attachments than right there where they are. (So I truly hope we're only arguing about the dropdown part of the button, not the button itself, isn't it?).

> Weniger ist mehr! And KISS.

In this case, I think a tiny and unobtrusive dropdown arrow less isn't more, but a significant loss in terms of ux-efficiency and ux-discovery. And RTFM. I've explained most of these thing already starting from comment 0.
What do others think?

Comment 26

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #24)
> (In reply to Thomas D. (currently busy elsewhere) from comment #21)
> > > "Select All" is Ctrl+A, or Click, Shift+Click.
> > What about mouse-only? There are different types of users we have to cater
> > for.
> They can use the context-menu.
> 
> Remove all attachments: Select all,

Btw, thank you for silently acknowledging that "Select All" on the context menu is needed for mouse-only operation...

Comment 27

[Thomas D. (:thomas8)]

Attachment: Screenshot1 (Variant A): New attachment header with dual-button on demand: Attach files in-place!

Fyi, here's a screenshot of the new attachment header implemented by this bug, and an illustration of "in-place" attaching of files (vs. status quo).

Comment 28

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere) from comment #26)
> Btw, thank you for silently acknowledging that "Select All" on the context
> menu is needed for mouse-only operation...
Yes, but it's on the context menu, even if you have 10 attachments and no empty space.

Looking at the patch again, your drop-down with 7 functions is identical to the context menu when right-clicking on white-space. OK, when there is no white-space and you right click on an attachment, the context menu is different and you lose some options which are on your drop-down. So why not just beef up the context menu?

Thomas' drop-down identical to white-space context menu:
1) Select All *
2) Attach File -
3) File Link - 
4) Attach Web - 
7) Remind Me Later -
6) Reorder *
7) Remove all + 

Other context menu:
1) Open
2) Rename
3) Reorder
4) Remove (one or more)
5) Convert to
6) Select all

The items marked * are already on both context menus. I'd add "Remove all to the "other" context menu and be done. The items marked - are on the attachment button, which I have not used once since 2010, BTW. I use drag&drop.

I really think a (split) button on a header is going in the wrong direction.

Comment 29

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #28)
> (In reply to Thomas D. (currently busy elsewhere) from comment #26)
> > Btw, thank you for silently acknowledging that "Select All" on the context
> > menu is needed for mouse-only operation...
> Yes, but it's on the context menu, even if you have 10 attachments and no
> empty space.
> 
> Looking at the patch again, your drop-down with 7 functions

For the average user, that's 6 functions, I don't think there are a lot of people out there using File Link.

> is identical to
> the context menu when right-clicking on white-space.

Yes, because it IS the attachment *list* context menu (as opposed to the attachment *item* context menu), and that's what I said all along... Lesen hilft... And I'm surprised that you're only starting to do proper analysis now *after* you have already moved to discredit my proposal... Personally, I work the other way round, analyse first, then comment...

> OK, when there is no
> white-space and you right click on an attachment, the context menu is
> different and you lose some options which are on your drop-down. So why not
> just beef up the context menu?

I admit that I've sometimes advocated for mixing item context and list context myself, but I don't think that's a good idea. Imagine a multiple selection, 2 out of 10 attachments selected. Following your proposal to add "Remove All Attachments" to *item* context, this results in having *both* "Remove Attachments" and "Remove All Attachments" on the same context menu. Imho, that's an absolute no-go because of ux-error-prevention, users can rightly expect only selection-relevant commands on a selection context menu, and they end up removing all where they only wanted to remove some.

> Thomas' drop-down identical to white-space context menu:
That's *List* context, with functionality focussed on to the list, not selected items.
> 1) Select All *
> 2) Attach File -
> 3) File Link - 
> 4) Attach Web - 
> 7) Remind Me Later -
> 6) Reorder *
> 7) Remove all + 
> 
> Other context menu:
That's *Item* context, for selected attachment(s)
> 1) Open
> 2) Rename
> 3) Reorder
> 4) Remove (one or more)
> 5) Convert to
> 6) Select all
> 
> The items marked * are already on both context menus. I'd add "Remove all to
> the "other" context menu and be done.

As I said, that's a no-go in terms of ux-error-prevention.

> The items marked - are on the
> attachment button, which I have not used once since 2010, BTW.

If you're not even using a button to add your attachments, I wonder why you're so keen to speak against more convenience for button users.

> I use drag&drop.
> 
> I really think a (split) button on a header is going in the wrong direction.

Can you please clarify if you would find a simple button acceptable or not (appearing only on hover, so normally it just looks like a label)?
There's nothing special or "wrong" about using a header bar as a mini-toolbar with just *one* focal point of action. The point is to offer functionality where users would search for it, and that's in-place. That's a solid, fundamental, and modern UX concept, just think Android. There's not a single millimeter in your typical Android App where tapping on anything wouldn't do something that is useful in that context. Android apps are using triple lines or triple dots to symbolize contextual menus. We can also do that here if we agree on that, but personally I think the traditional dual button with a tiny dropdown marker makes a lot more sense here:
- the dropdown marker makes the main button part (the "3 attachments" label) discoverable as clickable.
- intentionally clone the "Attach" button from main toolbar to be available in-place, because when adding more attachments to an existing list of attachments, it's quite counter-intuitive going back to the far left of you screen for every new attachment whilst they all come out on the far right, and NOT having a simple and discoverable way of adding attachments in-place, where attachments actually are (because with Jörg's proposal, "Attach File(s)" and friends will remain on *list* context exclusively, which is only available from whitespace, which is hard to get at when there are more than 5 attachments). That's like going to town 10 km away from your home in the village every day to buy your bread because you despise your baker next door.

For illustration as to why "in-place" is the superior UX, please see attachment 8939160 [details].
That said, I'm not here to remove the existing attach button (yet), so essentially my implementation doesn't change anything except that clicking the header will now do something useful.

> I really think a (split) button on a header is going in the wrong direction.

I'm still failing to see even one strong reason against offering contextual functionality in-place on the very discoverable and accessible header, for those who like it. If you don't like it, don't use it. I'm not taking any existing functionality away from you, so you can still drag along your favorite attachments given that you don't like using buttons. So everybody can find his most convenient way of doing things, but we're adding a highly convenient way here where it really makes most sense. I can only say again that it feels awesome to use this. We're not Microsoft forcing ribbons onto the whole world...

Comment 30

[Thomas D. (:thomas8)]

Tapping/clicking right where you want to add something is really THE current UX concept in the entire mobile world of Apps, because it's intuitive. For adding your profile picture at the top of your profile, you'd typically tap right where your profile should go, not in some other remote corner of the screen. You don't usually run to press the doorbell five houses away only to run back and expecting someone to open the door right in front of you. You don't usually switch your bathroom light in the bedroom - unless here in Africa where I am. Trust me, that sort of remote control for what should be in-place functionality isn't convenient, at all. Just take my word for it :)

Comment 31

[Jorg K (CEST = GMT+2)]

Hmm, I'm just against a) repeating UI, like the drop-down repeats the *list* context and b) against turning a column heading into a button. The arrow could be read as a sort order.

> Can you please clarify if you would find a simple button acceptable or not ...
Actually, right, I don't even like the split button. The button action is simply adding a new attachment, right? If a drop-down at all, then just a drop-down with no button at all.

> I'm not here to remove the existing attach button (yet), ...
I don't use it :-) - However, your stuff only works when the attachment bucket shows, so you can't remove the attach button since there wouldn't be a way to summon the bucket, unless of course, by drag and drop.

Comment 32

[Jorg K (CEST = GMT+2)]

Comment on attachment 8939105 [details] [diff] [review]
Patch Variant A, V.2: Implement Interactive attachments pane header, add cmd_removeAllAttachments, polish bucket behaviour

Remove reference to landed patch in attachment name.

Comment 33

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #31)
> Hmm, I'm just against
> a) repeating UI, like the drop-down repeats the *list* context, and

And *why* are you against that, when it adds more convenience for the user (ux-efficiency, ux-discoverability)?
I think repeating isn't the right word. We're not duplicating the menu for the sake of duplicating, we're exposing the existing list context menu because it's hard to reach from attachment pane whitespace which may not even exist.

> b) against turning a column heading into a button. The arrow
>    could be read as a sort order.

Hmmm, not really. This is NOT a /column/ heading (which would need to read "Attachment name | Size"). This is a pane header, and nothing is stopping us from dynamically blending/re-interpreting that as a toolbar (because header bars and toolbars look alike). Misreading the arrow as sort order would need a lot of imagination on the side of the user, and violation of ux-consistency on our side. Column headers with sort order toggle look quite different (white background, smaller and closed triangle, triangle before, not after the column splitter, triangle at the far right end of the column). This has all the looks of a typical dual button, and I don't see any potential for confusion here.

> > Can you please clarify if you would find a simple button acceptable or not ...
> Actually, right, I don't even like the split button. The button action is
> simply adding a new attachment, right? If a drop-down at all, then just a
> drop-down with no button at all.

A drop-down without button? I don't understand, I think this paragraph is jumbled. Maybe you wanted to say this:
> Actually, right, I *especially* dislike the *split* button. The button action
> is simply adding a new attachment, right? If a *button* at all, then just a
> *plain button* with no *dropdown* at all.
Is that what you meant?

And again, I'm surprised that at this stage of the discussion, you're till *asking* what the button actually does? Have you even tried it?

> > I'm not here to remove the existing attach button (yet), ...
> I don't use it :-) - However, your stuff only works when the attachment
> bucket shows, so you can't remove the attach button since there wouldn't be
> a way to summon the bucket, unless of course, by drag and drop.

I don't know if you've noticed that when you remove all attachments, or show attachment pane on a new mail with Alt+M (now works to unhide the pane), the button dynamically changes to look exactly like the "Attach" dual button on toolbar. My idea is to never hide the attachment pane header (at the right side of From field), but to only show/hide the actual bucket as needed. Then we'd only have *one* permanent position for the attach button, conveniently in-place. But that's just an idea, which needs to be tried and tested how it feels and works out.

We could also try this variant:
- Move existing attachment button to the far right of toolbar (so that all the attachment handling and displaying is bundled on the right side).
- Leave existing attachment pane header as-is (or allow the label to buttonize anyway - why not - but no dual button).
That's less functional than what I propose here (unless we add to the button menu), and not sure if it looks better.

Comment 34

[Thomas D. (:thomas8)]

Oh, by the way, on which OS are you testing this? Maybe the button looks different on Linux/MAC? On Windows, the new dual button is all but invisible (as seen in attachment 8939160 [details]) until you hover it, that's when the button shape becomes apparent.

Maybe we should have a try build so as to allow others (including users) to play with this easily?

Comment 35

[Jorg K (CEST = GMT+2)]

Attachment: Screenshot2 (Variant A, Detail): Two attach buttons (extreme edge case)

Since I'm doing other work, I don't have the patch applied always, so I can't try all the details all the time. Yes, I did click the button and that prompts to attach a file.

Let me restate my concern: There is something that looks like a column heading (with a sort arrow) and when you hover/click it, it turns into a split-button. Before, on Windows, it's not immediately recognisable as a button.

Call it what you want, you're showing the same UI in very close proximity, in the button and the list context, which isn't always accessible in a crowded bucket.

I've just tried the new "Focus Attachments Pane", and without attachments, you now have two "Attach" buttons. How confusing is that?

Summarising: Whilst there is room for improvement in the attachments handling, the solution presented here "duplicates" the UI which IMHO is not desirable (and also introduces a hydra of a column heading that turns into a button).

Before investing any more days into discussion or patches, I'd like to see a mock-up of an integrated solution. Without thinking too much about it, there could be an all-happy-making "Attach" button on the far right below which the bucket opens. That button would also allow to summon the bucket. It would preferably not turn into a column heading. (Remember the language button you opposed: That changed its label to show the selected language, a bit irritating, like the button that turns into a header and vice versa.)

Maybe we should also give others like Aceman and Magnus the chance to try the patch.

Comment 36

[Jorg K (CEST = GMT+2)]

Attachment: Screenshot3 (Variant A, Detail): Button dropdown provides reliable access to list context menu

Comment 37

[Magnus Melin [:mkmelin]]

I don't like the single-click opens - too easy to mis-click when trying to select. Also the "attachments" text is gray on linux, was black earlier and much more readable.

In general UI should be minimalistic, and this is not exactly that. Like the "Select all" of the list view is not likely very useful. It does fix some problems such as not getting to the "list" commands when there's no space in the view. 

All in all though, I guess it's a net win.

Comment 38

[Richard Marti (:Paenglab)]

Attachment: Screenshot 4 (Variant A, Detail, Linux): Dual-button header in Linux (incl. color nitfix)

Hmm, here it is not gray on Linux Mint.

Comment 39

[Jorg K (CEST = GMT+2)]

I agree, it's a net win. But getting two "Attach" buttons is a very confused UI, so I hope there is a better way to streamline attachment handling.

Comment 40

[Richard Marti (:Paenglab)]

(In reply to Magnus Melin from comment #37)
> Also the "attachments" text is gray on linux, was black earlier and much
> more readable.

Fixed in my patch now.

Comment 41

[Thomas D. (:thomas8)]

I'll answer first and then file a patch with another approach for comparison.

(In reply to Jorg K (GMT+1) from comment #35)
> Created attachment 8939195 [details]
> Screenshot with two attach buttons

This screenshot distorts reality, because in real life it will practically never occur as displayed.
- Nobody shrinks their window to this size. On most wide-screens with a normal-size or maximized window, the two buttons are far apart, as seen in my screenshot of attachment 8939160 [details].
- Edge case scenario, probably rare: only occurs when starting with alt+m to show attachment pane (where Ctrl+Shift+A is first choice), or after removing all attachments.

> Let me restate my concern: There is something that looks like a column
> heading (with a sort arrow) and when you hover/click it, it turns into a
> split-button. Before, on Windows, it's not immediately recognisable as a
> button.

Repeating does not make this true: From the actual design, this is highly unlikely to be confused with a column header with sort arrow, because this looks quite different and it does look like any other dual button.
All toolbar buttons on Windows and Linux are flat and only buttonize when hovered.
You are right there's a new thing here in that the button caption also acts as a caption, not an action. But from other UIs, again there's nothing unusual to click on an existing object icon or description in order to change that object.
I'm actually thinking to make the button caption change on hover from "5 attachments" into "Attach" (while preserving button size), that would bring out the action button nature even more clearly and easier to discover. 
But otherwise there's nothing wrong with this dual button, the only question is if we want a dual button here or not, which is more like a question of personal taste.

> Call it what you want, you're showing the same UI in very close proximity,
> in the button and the list context, which isn't always accessible in a
> crowded bucket.

You make it sound as if users could end up with two of the same menus on their screen, which is not the case.
Proximity is a weird description when de facto the other access point isn't always available.

> I've just tried the new "Focus Attachments Pane", and without attachments,
> you now have two "Attach" buttons. How confusing is that?

Not very confusing, because in 99% of cases they will be distinctly apart to the left and right of the screen (as explained above in this comment), not exactly underneath each other, so this is just an artificial scenario.

> Summarising: Whilst there is room for improvement in the attachments
> handling, the solution presented here "duplicates" the UI which IMHO is not
> desirable (and also introduces a hydra of a column heading that turns into a
> button).

If we remove the exaggeration of multi-headed dragons, I appreciate your point and there is some truth in that we're trying to solve the current problem of distance/disconnection between the attach button (far left) and the attachment pane (far right) by making an unintrusive variant of the same available.
Technically, you may call that duplication.
Visually, it does not usually come about as duplication.
In terms of "where to find actions", yes, we can now do the same actions in two places (which might be considered unfortunate in terms of ux-minimalism as we have two similar action points for the button functionality).
As Magnus said, it's a net win. But maybe we can do better.

> Before investing any more days into discussion or patches, I'd like to see a
> mock-up of an integrated solution. Without thinking too much about it, there
> could be an all-happy-making "Attach" button on the far right below which
> the bucket opens. That button would also allow to summon the bucket. It
> would preferably not turn into a column heading.

I'm surprised you seem to introduce this here as if it was a new idea of yours, but that's exactly my idea which I suggested we should try to address your concerns, in the comment you were responding to:

(In reply to Thomas D. (currently busy elsewhere) from comment #33)
> We could also try this variant:
> - Move existing attachment button to the far right of toolbar (so that all
> the attachment handling and displaying is bundled on the right side).
> - Leave existing attachment pane header as-is (or allow the label to
> buttonize anyway - why not - but no dual button).

> (Remember the language
> button you opposed: That changed its label to show the selected language, a
> bit irritating, like the button that turns into a header and vice versa.)

Yeah, there are similarities and differences (OT).

> Maybe we should also give others like Aceman and Magnus the chance to try
> the patch.

Comment 42

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #37)
> I don't like the single-click opens - too easy to mis-click when trying to
> select.

Hmm, that's existing behaviour in release version and no one ever complained about it, so I'm not going to remove that here. I temporarily replaced it with double click which was undiscoverable and felt awful (hence I'm just restoring the current behaviour here, but better). That said, it's actually *very hard* to mis-click because you'd have to a) miss your 20px wide click target item by clicking several pixels below the attachment name. b) ignore well-known and OS-consistent visual feedback where hovered items change their background color (so if you miss it, you don't get that over effect). So that's a non-issue.

In fact, I've made it even harder to mis-click because
- with selected attachments, first click on whitespace deselects as expected and required by standards/ux-consistency.
- tooltip "Attach files" when single-clicking will add attachment
This is a highly convenient way of adding attachments, especially when there are no attachments yet (or you removed them all), to just have a big and simple click target of whitespace, exactly where one would want to add more items, so highly intuitive and now more discoverable and less error-prone.

> Also the "attachments" text is gray on linux, was black earlier and
> much more readable.

Fixed by Richard.

> In general UI should be minimalistic, and this is not exactly that. Like the
> "Select all" of the list view is not likely very useful.

I thought the same at first, but a) it was there before, and b) it's required for efficient mouse-only operation.

> It does fix some problems such as not getting to the "list" commands when there's no space in
> the view. 
> All in all though, I guess it's a net win.

Thanks. Now let's try variants and see what where we can go from here, or if we just take the "net win" for now.

Comment 43

[Thomas D. (:thomas8)]

Attachment: Patch Variant B = Take2, V.1: Move attach button to the right for 'in-place' UX, add cmd_removeAllAttachments and polish attachment bucket

So inspired by Jörg's critical comments, here's another approach as first proposed in my comment 33:

(In reply to Thomas D. from comment #33)
> We could also try this variant:
> - Move existing attachment button to the far right of toolbar (so that all
> the attachment handling and displaying is bundled on the right side).
> - Leave existing attachment pane header as-is

This addresses the same functional problems which my first patch was addressing.
Aesthetics a bit odd at first, but I guess I could get used to that because just like my first variant, this is a LOT more practical as it offers a convenient, discoverable and always-available-in-the-same-spot starting point for attachment actions. So this is certainly a net-win, too.

I'm still dreaming of morphing the main button into the header (similar to my first patch), but I suspect that's a lot more work so we could go with this for now.

Feedback welcome on my first variant (attachment 8939105 [details] [diff] [review]) and "Take2" (this patch in what should be comment 43).

Comment 44

[Thomas D. (:thomas8)]

Attachment: Screenshot 5 (Variant B aka "Take2", Windows): Attachment button moved to the right

Here's a screenshot of the alternative approach ("Take 2", patch attachment 8939368 [details] [diff] [review]) where we move the existing attachment button to the very right of the toolbar, so it's right on top of the attachment pane when that is shown (following UX-in-place).

Comment 45

[Thomas D. (:thomas8)]

Attachment: Screenshot 6 (Variant B, Detail): UI states with attach button on the right

So here are the possible UI states of Take 2 approach.

1) Before adding attachments (or after hiding attachment pane with attachments)
2) When attachments have been added (and panel not hidden)
3) After removing all attachments (or when showing attachment pane with Alt+M before adding attachment)

@ 3): Note that after all attachments have been removed, we don't currently close the panel (and rightly so, because user might want to add others again), but we should at least /allow/ the user to close it by offering a close button. When there are attachments, the pane should not be hidden in the current dispensation, so there's no need for a close button.

Btw the current behaviour where user can hide pane with existing attachments without any trace in the UI (by dragging pane splitter) feels very wrong and is error-prone, we must at least keep showing "N attachments" somewhere (but that's for another bug).

Comment 46

[Thomas D. (:thomas8)]

Attachment: Screenshot 7 (B vs. A, Details): UI States of Variant B and A compared (caveat: image wrongly labelled, A vs. B.)

So here's a comparison of the status quo. Note that for variant A), the existing attach button on the right side of the toolbar is always available (but not depicted).

A) Dual-Morph-button on attachment header
B) Attach Button on top of current attachment header

My first impressions:

a) A and B are actually quite similar (which is no surprise, as they are solving the same problem.
b) There's a bit of a gap in the initial stage of A, as there's no immediately obvious way of adding attachments in-place. Technically there is, as my patches implement Alt+M to show attachment pane at any time. We could solve this:
- Keep attachment header always visible, but bucket collapsed
- place the legacy Attach button on the header: [Attach | v] (when 0 attachments)
c) B separates all functionality clearly; on the downside, it is a bit odd and bulky with Attach Button on top of attachment pane header.
d) A blends the same functionality into less space which looks more pleasant; on the downside, users will still start on the right before getting the in-place convenience (but see b) for a possible solution).
Behaviour of "3 Attachments" main button part:
- onhover: tooltip "Attach files" (we could also change the button label to "Attach" to make this even more discoverable, preserving button width).
- onclick: "Attach files" dialogue.

So Variant B is a solid albeit slightly odd and bulky net improvement which works as-is.
Variant A, while providing same net improvement of status quo, could still take some fine-tuning to become a slick and lean one-stop solution with less UI.

Fine-tuning Variant A would require being able to collapse just the attachment bucket (without header), which is currently technically impossible, so that takes a bit more work with the box model. But I imagine it could come out nicely because users could actually hide the bucket when they are happy with it, but still have an "3 attachments | v" status indicator and all-in-one access point for attachment management. After adding or removing attachments, the bucket will show, but it can be hidden if the user so wishes, much like the current behaviour of the attachment bucket of message reader.

Comment 47

[Thomas D. (:thomas8)]

Comment on attachment 8939380 [details]
Screenshot 7 (B vs. A, Details): UI States of Variant B and A compared (caveat: image wrongly labelled, A vs. B.)

Ooops, I labeled the image the wrong way round, which is a perfect recipy for confusion when talking about this...

Comment 48

[Jorg K (CEST = GMT+2)]

Comment on attachment 8939368 [details] [diff] [review]
Patch Variant B = Take2, V.1: Move attach button to the right for 'in-place' UX, add cmd_removeAllAttachments and polish attachment bucket

I was keen to try this since I like the screenshot, but something is wrong with this patch. The "Attach" button hasn't moved to the right and "Focus Attachment Pane" is also not on the menu. However, I have the patch applied since I see "Remove All Attachments" in the list context. What's going on?

Comment 49

[Thomas D. (:thomas8)]

Attachment: Screenshot 7* (B vs. A, Details): UI States of Variant B and A compared

So here's the corrected image comparing the two variants as-is, I'll re-add the comment so that it links up correctly with the attachment (sorry). Note that Variant B is displayed on top.

(In reply to Thomas D. (currently busy elsewhere) from comment #46)
So here's a comparison of the status quo. Note that for variant A), the
existing attach button on the right side of the toolbar is always available
(but not depicted).

B) Attach Button on top of current attachment header
---------
A) Dual-Morph-button on attachment header

My first impressions:

a) A and B are actually quite similar (which is no surprise, as they are
solving the same problem.
b) There's a bit of a gap in the initial stage of A, as there's no
immediately obvious way of adding attachments in-place. Technically there
is, as my patches implement Alt+M to show attachment pane at any time. We
could solve this:
- Keep attachment header always visible, but bucket collapsed
- place the legacy Attach button on the header: [Attach | v] (when 0
attachments)
c) B separates all functionality clearly; on the downside, it is a bit odd
and bulky with Attach Button on top of attachment pane header.
d) A blends the same functionality into less space which looks more
pleasant; on the downside, users will still start on the right before
getting the in-place convenience (but see b) for a possible solution).
Behaviour of "3 Attachments" main button part:
- onhover: tooltip "Attach files" (we could also change the button label to
"Attach" to make this even more discoverable, preserving button width).
- onclick: "Attach files" dialogue.

So Variant B is a solid albeit slightly odd and bulky net improvement which
works as-is.
Variant A, while providing same net improvement of status quo, could still
take some fine-tuning to become a slick and lean one-stop solution with less
UI.

Fine-tuning Variant A would require being able to collapse just the
attachment bucket (without header), which is currently technically
impossible, so that takes a bit more work with the box model. But I imagine
it could come out nicely because users could actually hide the bucket when
they are happy with it, but still have an "3 attachments | v" status
indicator and all-in-one access point for attachment management. After
adding or removing attachments, the bucket will show, but it can be hidden
if the user so wishes, much like the current behaviour of the attachment
bucket of message reader.

Comment 50

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #48)
> Comment on attachment 8939368 [details] [diff] [review]
> Patch Variant B = Take2, V.1: Move attach button to the right for 'in-place'
> UX, add cmd_removeAllAttachments and polish attachment bucket
> 
> I was keen to try this since I like the screenshot, but something is wrong
> with this patch. The "Attach" button hasn't moved to the right

Nothing wrong with the patch. It's a transition problem which we also need to solve if we want to land this.
Customize your Composition toolbar, then "Restore default set".

> and "Focus Attachment Pane" is also not on the menu.

Moved to "View" menu so that we can see where we like it better.
Also now with dynamic label, so when your attachment pane is hidden (without or with attachments), it'll say "Show attachment pane", otherwise "Focus attachment pane".
- Showing and hiding panes is traditionally in view menu (in favor of view menu)
- Focusing attachment pane is required for many attachment "editing" actions, which are found on Edit menu (in favor of Edit menu)

> However, I have the
> patch applied since I see "Remove All Attachments" in the list context.
> What's going on?

Magic!!! Hexerei!!! :p

Comment 51

[Thomas D. (:thomas8)]

Two glitches noticed with attachment 8939368 [details] [diff] [review]:

1) cosmetic: I've worked very hard to align those bloody header labels with as little CSS as possible, but it seems the size is still 2px down. Just add "margin-top: -2px; to the bucketSize thing:

#attachmentBucketSize
{
  margin-top: -2px;
  padding-inline-end: 2px;
  color: GrayText;
}

2) functional (apart from the need for transitioning existing setups):
Looks like it is possible to start a new message with attachment bucket open, which isn't intended at this point (but we should definitely offer that as an option, just like "Initially show attachment pane" option for message reader.
Not everybody wants the bucket hidden for new messages, it may make a nice drop target, or convenient extra-large click target for adding attachments.

Comment 52

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere) from comment #51)
> Two glitches noticed with attachment 8939368 [details] [diff] [review]:
> 2) functional (apart from the need for transitioning existing setups):
> Looks like it is possible to start a new message with attachment bucket
> open

Scrap #2, I was already fixing the next thing and did something wrong.

Comment 53

[Richard Marti (:Paenglab)]

(In reply to Thomas D. (currently busy elsewhere) from comment #50)
> (In reply to Jorg K (GMT+1) from comment #48)
> > I was keen to try this since I like the screenshot, but something is wrong
> > with this patch. The "Attach" button hasn't moved to the right
> 
> Nothing wrong with the patch. It's a transition problem which we also need
> to solve if we want to land this.
> Customize your Composition toolbar, then "Restore default set".

You need to add migration code in mailMigrator.js.

Comment 54

[Jorg K (CEST = GMT+2)]

Now we're cooking with gas ;-)

I like option B. Some remarks:
- Alt+X was removed.
- The "Attach" drop-down could also be used to summon the bucket.
- The "Attach" drop-down doesn't have all the options of the list context.
  I thought the idea was to have a "net gain" for when the bucket is full.
  Oh, right, I was against the duplication.

My apologies should those remarks have already been addressed in comments above.

Comment 55

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #54)
> Now we're cooking with gas ;-)

Cooking with gas *rocks*, I've had some recient exposure due to lack of electricity :)

> I like option B. Some remarks:
> - Alt+X was removed.

No, but it has outsmarted you. Try again with at least 2 attachments, because otherwise there's nothing to sort... ;)

> - The "Attach" drop-down could also be used to summon the bucket.

Can you clarify? you mean, adding "Show/focus attachment pane" to the dropdown menu?

> - The "Attach" drop-down doesn't have all the options of the list context.
>   I thought the idea was to have a "net gain" for when the bucket is full.
>   Oh, right, I was against the duplication.

Indeed, so you need to make up your mind now...
Not yet on dropdown:
- Select All
- Remove All
Ah well. Select All is really an odd thing, although I wouldn't dump it. It's available from item context (always available) and list context (sometimes unavailabl). So damn it. I'm no longer sure if we need to put that on the dropdown menu. Do you want it?
Ah well. Remove All is somewhat of an edge case, and still available with an extra step via Select All -> Remove All (which would typically be a keyboard operation, Ctrl+A, DEL. So it's up to you if you want it on the dropdown menu or not. We could add it as a complementary opposite action (Adding vs. Removing all = Undo all adding). But we must be aware it will be the only command which is *not* about adding, as it's the opposite of the button label "Attach". What do you think?

Comment 56

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere) from comment #55)
> Cooking with gas *rocks*, I've had some recient exposure due to lack of
> electricity :)
I agree. But you're aware of https://www.urbandictionary.com/define.php?term=cooking%20with%20gas
(no offence intended).
 
> > I like option B. Some remarks:
> > - Alt+X was removed.
> No, but it has outsmarted you. Try again with at least 2 attachments,
> because otherwise there's nothing to sort... ;)
Or maybe it outsmarted *you* ;-) Alt+X was to summon the bucket.

> > - The "Attach" drop-down could also be used to summon the bucket.
> Can you clarify? you mean, adding "Show/focus attachment pane" to the
> dropdown menu?
Yes. Not useful?

> Indeed, so you need to make up your mind now...
> Not yet on dropdown:
> - Select All
> - Remove All
> Ah well. Select All is really an odd thing, although I wouldn't dump it.
> It's available from item context (always available) and list context
> (sometimes unavailabl). So damn it. I'm no longer sure if we need to put
> that on the dropdown menu. Do you want it?
Hmm, before you argued that the the drop-down menu should be comprehensive and duplicate the list context and now when you've almost convinced me, you've changed your mind and I need to argue your previous point. I guess it wouldn't hurt for "max net gain" ;-)

> Ah well. Remove All is somewhat of an edge case, and still available with an
> extra step via Select All -> Remove All (which would typically be a keyboard
> operation, Ctrl+A, DEL. So it's up to you if you want it on the dropdown
> menu or not. We could add it as a complementary opposite action (Adding vs.
> Removing all = Undo all adding). But we must be aware it will be the only
> command which is *not* about adding, as it's the opposite of the button
> label "Attach". What do you think?
Again, I would include it for "max net gain". Remove all attachments is something I use, like when I edit a message as new and want to get rid of the attachments. Sure, there are other ways (like select all + del/remove), but IIRC you fixed the function, we might as well have it.

But let's here from others whether they like the right-aligned button. I think it makes a lot of sense to have a multi-function button close to the bucket.

P.S.: I think I saw that the bucket has an (X) to close it now. That's great, I always wanted to close empty buckets.

Comment 57

[Thomas D. (:thomas8)]

Attachment: Patch B, V. 2: Move attach button to the right for 'in-place' UX, add cmd_removeAllAttachments and polish attachment bucket behaviour (more "net gain" actions on dropdown, finetune behaviour)

(In reply to Jorg K (GMT+1) from comment #56)
> (In reply to Thomas D. (currently busy elsewhere) from comment #55)
> > > I like option B. Some remarks:
> > > - Alt+X was removed.
> > No, but it has outsmarted you. Try again with at least 2 attachments,
> > because otherwise there's nothing to sort... ;)
> Or maybe it outsmarted *you* ;-) Alt+X was to summon the bucket.

Since bug 1427037, Alt+X has always focused the attachment bucket and still does. Not for you?
After removing all and re-adding attachments, there was a pre-existing UI flaw that there'll be no currentItem, i.e. no visible focus as we removed bucket focus border because with any focused attachment it's just confusing, useless and non-standard. Only occurs when focus remains in bucket; bucket getting focus from somewhere else will set first item as currentItem if there's no other.
So before this patch, focus could be invisible sometimes, although correctly placed. We still need to make this a bit smarter so that when there are no attachments and bucket has focus, we must show bucket focus border anyway. 

> > > - The "Attach" drop-down could also be used to summon the bucket.
> > Can you clarify? you mean, adding "Show/focus attachment pane" to the
> > dropdown menu?
> Yes. Not useful?

Yeah, useful for anyone who wants to start out with the pane when it's not shown, or when you've dragged it away (which should be illegal without better indication of current attachments, ux-error-prevention).

> > Indeed, so you need to make up your mind now...
> > Not yet on dropdown:
> > - Select All
> > - Remove All
> > Ah well. Select All is really an odd thing, although I wouldn't dump it.
> > It's available from item context (always available) and list context
> > (sometimes unavailable). So damn it. I'm no longer sure if we need to put
> > that on the dropdown menu. Do you want it?
> Hmm, before you argued that the the drop-down menu should be comprehensive
> and duplicate the list context and now when you've almost convinced me,
> you've changed your mind and I need to argue your previous point. I guess it
> wouldn't hurt for "max net gain" ;-)

We're both moving, that's good.

> > Ah well. Remove All is somewhat of an edge case, and still available with an
> > extra step via Select All -> Remove All (which would typically be a keyboard
> > operation, Ctrl+A, DEL. So it's up to you if you want it on the dropdown
> > menu or not. We could add it as a complementary opposite action (Adding vs.
> > Removing all = Undo all adding). But we must be aware it will be the only
> > command which is *not* about adding, as it's the opposite of the button
> > label "Attach". What do you think?
> Again, I would include it for "max net gain". Remove all attachments is
> something I use, like when I edit a message as new and want to get rid of
> the attachments. Sure, there are other ways (like select all + del/remove),
> but IIRC you fixed the function, we might as well have it.

Remove All looks more useful to me, too. Select All, maybe less useful (only for dragging currently), but skipping just one command might be odd, too. "Max net gain" is the killer argument against ux-minimalism hehe...

> But let's hear from others whether they like the right-aligned button. I
> think it makes a lot of sense to have a multi-function button close to the
> bucket.
> 
> P.S.: I think I saw that the bucket has an (X) to close it now. That's
> great, I always wanted to close empty buckets.

Thanks for positive feedback.

Can we have some feedback from others? There's a screenshot in attachment  8939375 [details], but not yet showing the extended dropdown menu on the button as it integrates some more contextual actions for the bucket.

Comment 58

[Jorg K (CEST = GMT+2)]

Comment on attachment 8939544 [details] [diff] [review]
Patch B, V. 2: Move attach button to the right for 'in-place' UX, add cmd_removeAllAttachments and polish attachment bucket behaviour (more "net gain" actions on dropdown, finetune behaviour)

I like this 100% :-) - Remove all, close bucket, nice!

The only thing I'd change is make "Select All Attachments" consistent also on the list context menu.

P.S.: Sorry about the confusion re. Alt+X. I finally got outsmarted ;-(. Yes, Alt+X was also for reorder attachments and it summons the bucket. In an earlier version there was "Focus Attachment Pane" under "Edit" (now under "View") and I erroneously remembered that it had Alt+X. My mistake.

Comment 59

[Thomas D. (:thomas8)]

cmd_selectAll isEnabled status is messed up, probably because of its hermaphrodite (Zwitter) status between the main controller (or whereever it's controlled for msg body) and attachment controller. Add attachments without touching the bucket, then bucket dropdown - select all disabled. What happens is that updateAttachmentItems() gets correctly called from onpopupshowing of button-dropdown, but the isEnabled of attachments cmd_selectAll is never executed, imo bc the attachmentBucket controller doesn't have control when we just click the toolbar button without focusing attachment pane first. Those conglomerate commands are not ideal, better to split them up and swap in menus.
I guess it would work if there was a way of giving control to the bucket controller (ideally *without* placing focus there).
Aceman, any insights?

Comment 60

[Richard Marti (:Paenglab)]

Comment on attachment 8939544 [details] [diff] [review]
Patch B, V. 2: Move attach button to the right for 'in-place' UX, add cmd_removeAllAttachments and polish attachment bucket behaviour (more "net gain" actions on dropdown, finetune behaviour)

On wide windows it looks a bit weird with the button alone on the right but this minimizes the complexity with multiple elements doing the same.

This needs still thinking about the migration (do we want to migrate all installations or only new users? What about configurations which have removed this button? etc.).

I have a patch with simpler styles and no negative margins. If this solution is chosen then I can do the CSS for Linux and Mac.

Comment 61

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #60)
> Comment on attachment 8939544 [details] [diff] [review]
> Patch B, V. 2: Move attach button to the right for 'in-place' UX, add
> cmd_removeAllAttachments and polish attachment bucket behaviour (more "net
> gain" actions on dropdown, finetune behaviour)
> 
> On wide windows it looks a bit weird with the button alone on the right but
> this minimizes the complexity with multiple elements doing the same.

Yes, it looks a bit weird at the beginning, but it's enormously practical to have the button with the attachment panel. I've run with this for some time now and I no longer notice the weirdness. When I go back to release version, I find myself looking for that button when it's not there.

> This needs still thinking about the migration (do we want to migrate all
> installations or only new users? What about configurations which have
> removed this button? etc.).

What if we do this?
- migrate both new and existing installations
- configurations which have removed the button, we shouldn't put it back. But if possible to make sure their defaultset updates so that if they use that, they should find the button in the new position.

I'm not sure if I'll get round to migration code, and I've never done it before.

> I have a patch with simpler styles and no negative margins. If this solution
> is chosen then I can do the CSS for Linux and Mac.

Thanks, that's good.

Comment 62

[Richard Marti (:Paenglab)]

(In reply to Thomas D. (currently busy elsewhere) from comment #61)
> (In reply to Richard Marti (:Paenglab) from comment #60)
> > This needs still thinking about the migration (do we want to migrate all
> > installations or only new users? What about configurations which have
> > removed this button? etc.).
> 
> What if we do this?
> - migrate both new and existing installations

Then we need the migration code.

> - configurations which have removed the button, we shouldn't put it back.
> But if possible to make sure their defaultset updates so that if they use
> that, they should find the button in the new position.

The defaultset is automatically ready with your changes.

> I'm not sure if I'll get round to migration code, and I've never done it
> before.

I've done it one time. And when I can do this, you can do this too. :) I's mostly searching in this file a similar case and copy/modify it. And don't forget to increment the UI_VERSION in this file. ;)

Comment 63

[Richard Marti (:Paenglab)]

Comment on attachment 8939105 [details] [diff] [review]
Patch Variant A, V.2: Implement Interactive attachments pane header, add cmd_removeAllAttachments, polish bucket behaviour

Removing ui-r? as it's likely not the way we go.

Comment 64

[Jorg K (CEST = GMT+2)]

How relevant is this after landing bug 1461170? Do the patches still apply? Do they still need review/feedback?

Comment 65

[Thomas D. (:thomas8)]

Comment on attachment 8939105 [details] [diff] [review]
Patch Variant A, V.2: Implement Interactive attachments pane header, add cmd_removeAllAttachments, polish bucket behaviour

Most of this patch has been landed in the other bugs in one way or the other, except for the merging of the attach button and the "N attachments" label into a dual button (per concept of Variant A, see screenshot attachment 8939160 [details]).

In a perfect world, we might want to file a followup bug for the problem of comment 59 which this patch was trying to address for attachment bucket:
> cmd_selectAll isEnabled status is messed up, probably because of its
> hermaphrodite (Zwitter) status between the main controller (or wherever it's
> controlled for msg body) and attachment controller.
Trying to improve this for attachment bucket must ensure not breaking the behaviour for message body's "Select All".

Comment 59 would become relevant again if we added "Select All" to the attach button dropdown, which we haven't so far, so clearing ni?aceman.

Comment 66

[Thomas D. (:thomas8)]

Comment on attachment 8939544 [details] [diff] [review]
Patch B, V. 2: Move attach button to the right for 'in-place' UX, add cmd_removeAllAttachments and polish attachment bucket behaviour (more "net gain" actions on dropdown, finetune behaviour)

Right, we've implemented the key concept of this patch (move attachment button to the right for in-place UX) and much of its code in bug 1428631 and bug 1461170, which technically makes patch obsolete.

We have *not* added some more "net gain" actions to the dropdown of the attachment button yet (Select All, Remove All Attachments, Reorder Attachments), which we could now that it is positioned on top of the attachment bucket, to make those actions more discoverable.

Comment 67

[Óvári]

(In reply to Thomas D. (currently busy elsewhere) from comment #66)
> We have *not* added some more "net gain" actions to the dropdown of the
> attachment button yet (Select All, Remove All Attachments, Reorder
> Attachments), which we could now that it is positioned on top of the
> attachment bucket, to make those actions more discoverable.

Could "Bug 1468704 - Enable attaching a Template when creating a message" be added to the "net gain" please?

Comment 68

[Thomas D. (:thomas8)]

Most of comment 0 has been implemented in "depends on" bugs, so this has become a meta bug.
Let's say we're done here.