Composition: With more attachments than attachment pane height, context menu for adding attachments is unavailable, as we lost extra white-space margin at the bottom (regression) and horizontal whitespace is ignored [multiple, many attachments]

NEW
Unassigned

Status

Thunderbird
Message Compose Window
6 years ago
5 years ago

People

(Reporter: Thomas D., Unassigned)

Tracking

(Blocks: 1 bug, {regression})

Trunk
regression

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
STR

1) compose msg with many attachments, more than can fit into attachment pane's default height (or current height, for that purpose)
2) Try to access whitespace context menu for adding more attachments

Actual

- with few attachments, can right-click on whitespace below attachment list to get the context menu (ok)
- with many attachments, cannot get at context menu as there is no whitespace left to click on (this bug)
- no way of in-place adding of more attachments from attachment pane

Expected
- when list of attachments is longer than attachment pane height (scrollbar shows up), we should add some extra vertical white-space margin at the bottom of attachment pane, so that user can consistently use the same method of adding more attachments without resizing the pane (which may not even be possible for large numbers of attachments, depending on screen and window size).
- extra vertical whitespace should have same height as one attachment list item (row), to make it an easy and intuitive click target
- to be internally consistent (with 3-pane attachment pane), and externally consistent (with Windows OS, can't test others), right-clicking on the *horizontal* whitespace behind attachment file names, including size label, should also show the whitespace context menu (as in 3-pane). Jim, do you want a separate bug for /horizontal/ whitespace?

This is a regression (at least for the vertical whitespace), probably fallout from Bug 630759.

Jim, can we assign this to you?
(Reporter)

Updated

6 years ago
Summary: Composition: With more attachments than attachment pane height, context menu for adding attachments is unavailable, as we lost extra white-space margin at the bottom (regression) [multiple, many attachments] → Composition: With more attachments than attachment pane height, context menu for adding attachments is unavailable, as we lost extra white-space margin at the bottom (regression) and horizontal whitespace is ignored [multiple, many attachments]

Comment 1

6 years ago
This was intentional. I could make click-through work like in the reader, but I'm not keen on adding whitespace at the bottom again. It wasn't a very good UI to begin with, since it was just working around the inability to click through a listitem. We might as well just fix it properly instead of re-adding the workaround.

While I'm here, I should probably remove the "single click empty space to add an attachment", since that UX is really unintuitive. I'd expect that action to deselect all the attachments, not bring up a modal dialog.
(Reporter)

Comment 2

6 years ago
(In reply to Jim Porter (:squib) from comment #1)
> This was intentional. I could make click-through work like in the reader,
> but I'm not keen on adding whitespace at the bottom again. It wasn't a very
> good UI to begin with, since it was just working around the inability to
> click through a listitem. We might as well just fix it properly instead of
> re-adding the workaround.

I assume clicking "through" a listitem means clicking on the horizontal whitespace in the list item row of attchments whose filenames are shorter than the column width. Yes, please allow click-through for the attachment list items in composition, that's a useful addition to be consistent with 3-pane.

However, imho, click-through is not so intuitive after all; in fact, even as an advanced user I tend to avoid it because you can't always be sure if what looks like whitespace might still be part of the item, depending on the program(mer). Worse, click-through will not always be available depending on attachment pane size and length of file names. If attachment pane is a bit narrow, and all file names are just a bit wider than column width, there may not be any horizontal whitespace to click through. And resizing may not help for long filenames and/or lots of files. So "click-through" alone *cannot* fix the problem of this bug. 

There are two functions of always ensuring some whitespace below attachments list:
1) safe and easy click target for right-click (attachment pane context menu, esp. for adding attachments, this bug)
2) safe and easy click target for single left-click (deselecting and/or adding attachments)

As explained above in this comment, removing the bottom whitespace can result in users having no way of adding attachments from inside attachment pane, at all (Bug 707432 might help, but it's not sufficient). So regardless of our views on 2), I think we still need to keep bottom whitespace because of 1). I don't see anything wrong with a bit of guaranteed bottom whitespace (TB 2 had around 6px); when adding new files in my OS file explorer, it's exactly the same procedure: on the big blank below existing files, right-click > New > X-File. That feels intuitive and natural in the attachment pane, too, and should not depend on screen size or file name length or number of attachments.

> While I'm here, I should probably remove the "single click empty space to
> add an attachment", since that UX is really unintuitive. I'd expect that
> action to deselect all the attachments, not bring up a modal dialog.

I'm torn on this one. You are right, single-left click on whitespace outside selection should deselect. I was about to file that as a bug when I realized the great comfort of single-click-add-attachment, which certainly has tremendous value for all who use it even though it may not be immediately intuitive for the novice user (we could change that by adding a tooltip, fwiw). I think we'll get a lot of screaming if we remove that comfort entirely without offering equally good alternatives (single-click, mind you!). I've cracked my head but I don't see immediate alternatives with the same degree of comfort, not least because whitespace is often quite a /big/ and thus easy click target. Imo it is also very intuitive once you know it.

But I still agree with you that single-left click on whitespace outside an existing selection should deselect. Thinking about it, why don't we just do this:

UI Proposal for single-left-clicks on whitespace (standards-conform, yet everyone happy)

without selection:
- single click to add attachments (as we do now)
if there's a selection:
- *first* single click deselects (as expected, with immediate visual feedback)
- next single click to add attachments (as expected, and otherwise no reason to click!)

So we handle the manual selection case correctly according to the rules, while still offering the comfort of single-click-add-attachments for cases where otherwise single click does not do anything (which should be the majority of cases, so it works reliably for adding attachments). No dangers, because without selection, there is no reason for users to single-left-click unless deliberately for adding attachments. Everyone happy!

For extra points - Add tooltip on whitespace:
- without selection: "Add attachments"
- if there's a selection: "Deselect" or "Deselect Attachments"
  then, after first single click: "Add attachments"

(In addition, we could consider allowing double-click on whitespace to add attachment, as a safe-guard for too fast single clicks)

Comment 3

6 years ago
(In reply to Thomas D. from comment #2)
> Worse, click-through will not always be available depending on
> attachment pane size and length of file names.

It'll actually always be available, since the size column can be clicked-through. This isn't very intuitive, but we also have the header for that. Let's ask bwinton, though.

> I think we'll get a lot of screaming if we remove that comfort
> entirely without offering equally good alternatives (single-click, mind
> you!).

There already is a single-click option to add an attachment: the "Attach" button. I agree that we'll probably get complaints, since people complain any time something changes that requires them to adjust, but we should still eliminate non-standard UX that can cause confusion. We've currently got 5 ways of adding an attachment (File > Attach, the Attach toolbar button, drag-and-drop, right-click the attachment list, single-click empty space in the attachment list). The first four are all pretty standard, but the last one isn't, and causes problems already mentioned.

Just to see what happens, I tried double-clicking in the empty space of a Windows Explorer / GNOME Nautilus window: both do nothing.

> without selection:
> - single click to add attachments (as we do now)
> if there's a selection:
> - *first* single click deselects (as expected, with immediate visual feedback)
> - next single click to add attachments (as expected, and otherwise no reason to click!)

This still isn't a standard UX, and it would still annoy me. Clicking in the empty space also shifts focus to the attachment list, and sometimes I want to click-to-focus and then switch to using the keyboard.

I'd be ok with a "double-click to add attachment" tooltip to help transition people to the new UX, though.

Comment 4

6 years ago
Blake, what do you think about adding some empty space at the end of the attachment list in the composer so that people can more easily get at the context menu for the entire list? Do you think we should add that even if people can right-click on the whitespace after the attachment name to get the whole-list context menu as well?
(Reporter)

Comment 5

6 years ago
(In reply to Jim Porter (:squib) from comment #3)
> (In reply to Thomas D. from comment #2)
> > Worse, click-through will not always be available depending on
> > attachment pane size and length of file names.
> 
> It'll actually always be available, since the size column can be
> clicked-through. This isn't very intuitive,

I don't think it will be obvious for people that they can get an all-attachment context menu when they right-click on the size label of a single attachment. So practically, there is no visible whitespace (and thus no obvious access to the context menu), even though technically, it might be available from size column.


> but we also have the header for
> that.

Which header, for what? Does that mean that you agree we should do Bug 707432 (all-attachments context menu on attachment header bar of composition)?

> Let's ask bwinton, though.
> 
> > I think we'll get a lot of screaming if we remove that comfort
> > entirely without offering equally good alternatives (single-click, mind
> > you!).
> 
> There already is a single-click option to add an attachment: the "Attach"
> button.

Unfortunately, that option is quite far away from the attachment pane, so it's no alternative to in-place adding...

> I agree that we'll probably get complaints, since people complain
> any time something changes that requires them to adjust, but we should still
> eliminate non-standard UX that can cause confusion.

I don't see much confusion if single left-click correctly deselects existing selections.

> We've currently got 5
> ways of adding an attachment (File > Attach, the Attach toolbar button,
> drag-and-drop, right-click the attachment list, single-click empty space in
> the attachment list). The first four are all pretty standard, but the last
> one isn't, and causes problems already mentioned.

The number of ways is not as relevant as their efficiency / comfort. We've got a number of ways to do /anything/ in our UI, that's no argument in itself.
The "problems already mentioned" are mostly avoided by my UI proposal of comment 2.
 
> Just to see what happens, I tried double-clicking in the empty space of a
> Windows Explorer / GNOME Nautilus window: both do nothing.

Of course not. Attachment pane is /similar/ to a file explorer /in many respects/, and should have similar behaviour, but after all, it's not exactly the same as a file folder /in all respects/. So the non-standard function of adding attachments with single-click on whitespace is something TB has deliberately added because the main function of attachment pane in composition is, using the CRUD terminology, Creation and Updating. :)
So we also have to think of attachment pane (whitespace) as "the place where you add attachments", for which it makes perfect sense that adding them should be as easy as possible (e.g. single-click on whitespace).

> > without selection:
> > - single click to add attachments (as we do now)
> > if there's a selection:
> > - *first* single click deselects (as expected, with immediate visual feedback)
> > - next single click to add attachments (as expected, and otherwise no reason to click!)
> 
> This still isn't a standard UX,

Not for a file manager, but possible for an attachment pane, as explained above.

> and it would still annoy me. Clicking in the
> empty space also shifts focus to the attachment list, and sometimes I want
> to click-to-focus and then switch to using the keyboard.

I would be interested to hear more about that use case.
If you are trying to add an attachment, and we keep single-click-whitespace-to-add-attachment behaviour, you are right there. If you want to rename/remove/open a specific attachment, you can move the focus right there by clicking on the attachment directly. If you want to work on several attachments, you'll have to start with /one/, at least, so what's the point of clicking anywhere in the wild of whitespace (which may not always be visibly available)? And, do you really think many users will click on whitespace just to shift focus? But yes, it's true that if we keep single-click logic, clicking whitespace just to shift focus to attachment pane won't work. Maybe it should.

> I'd be ok with a "double-click to add attachment" tooltip to help transition
> people to the new UX, though.

Does that mean that you would agree to introduce functionality of "double-click on whitespace to add attachment" as a replacement for "single-click on whitespace to add attachment"?

Which new UX exactly?

Comment 6

6 years ago
(In reply to Thomas D. from comment #5)
> The number of ways is not as relevant as their efficiency / comfort. We've
> got a number of ways to do /anything/ in our UI, that's no argument in
> itself.

I think it's a reasonable compromise to expect people to choose between "double-click" or "move and single-click". Besides, from a file explorer POV, single-click always means "select" and double-click means "do something". I'd argue that "double-click to add an attachment" follows the principle of least surprise here.

> I would be interested to hear more about that use case.

What I usually end up doing is clicking anywhere on the attachment list (usually an empty spot), then hitting Ctrl+A and Delete to delete all attachments. Obviously, I could be careful and just click on an actual attachment first, but I'd rather *not* be careful.

> > I'd be ok with a "double-click to add attachment" tooltip to help transition
> > people to the new UX, though.
> 
> Does that mean that you would agree to introduce functionality of
> "double-click on whitespace to add attachment" as a replacement for
> "single-click on whitespace to add attachment"?

Correct. I figure there are at least some people who are used to the current method (single-click). I'm sure they'll be confused when it doesn't work, but the tooltip will helpfully inform them that now you have to double-click. My goal here is to minimize confusion both for new users (for whom single-click to attach is unintuitive), and experienced users (who are used to single-click to attach).
(Reporter)

Comment 7

6 years ago
(In reply to Jim Porter (:squib) from comment #6)
> (In reply to Thomas D. from comment #5)
> I think it's a reasonable compromise to expect people to choose between
> "double-click" or "move and single-click".

Clearly, "double-click in-place" still wins over "move across the screen and single-click attachment button"... ;)

Btw, could single-left-click on attachment header bar to add attachments be an option?

> Besides, from a file explorer
> POV, single-click always means "select" and double-click means "do
> something". I'd argue that "double-click to add an attachment" follows the
> principle of least surprise here.

Point taken. Jim knows I cannot resist offers that have a "100% standard-conform" tag... Although, I do get tempted with 95% standard conform and 75% single-click comfort... ;)

> > I would be interested to hear more about that use case.
> 
> What I usually end up doing is clicking anywhere on the attachment list
> (usually an empty spot), then hitting Ctrl+A and Delete to delete all
> attachments. Obviously, I could be careful and just click on an actual
> attachment first, but I'd rather *not* be careful.

That's a good and valid point, especially for advanced users. I think we should keep some whitespace at the bottom (as we used to have in earlier versions) so that it's easier for Jim to hit an empty spot without being careful!!! ;)

> > Does that mean that you would agree to introduce functionality of
> > "double-click on whitespace to add attachment" as a replacement for
> > "single-click on whitespace to add attachment"?
> 
> Correct. I figure there are at least some people who are used to the current
> method (single-click).

...and we have no idea of how many they are. Just don't say I didn't warn you when we get the screaming... But honestly, I can't even guess.

> I'm sure they'll be confused when it doesn't work,
> but the tooltip will helpfully inform them that now you have to
> double-click. My goal here is to minimize confusion both for new users (for
> whom single-click to attach is unintuitive), and experienced users (who are
> used to single-click to attach).

I'm not sure if perhaps it's the other way round: We might hurt the simple users (for whom single-click might be intuitive) and serve advanced users (who are used to standard-conform single-clicking on blank spots to continue with Ctrl+A on keyboard...). But still, Jim's goal is noble, and double-click whitespace to add attachments looks like reasonable compromise for all parties involved. Plus, it's sooo standard-conform... omg I'm loving it... ;)

Thanks Jim for immediate feedback!

Comment 8

6 years ago
(In reply to Thomas D. from comment #7)
> I'm not sure if perhaps it's the other way round: We might hurt the simple
> users (for whom single-click might be intuitive) and serve advanced users
> (who are used to standard-conform single-clicking on blank spots to continue
> with Ctrl+A on keyboard...).

We might be talking about different types of users (this is one of the big dangers with trying to program towards user stereotypes). I'm just trying to split users into two categories based on their experience with Thunderbird in particular, not with computers in general.

In any case, it sounds like we both agree that double-clicking to add attachments is a reasonable implementation. Though now that I think about it, there is one place in Windows where single-clicking does something other than selection: renaming. However, the click target on that is pretty small - just the actual text - and it doesn't pop up a dialog window. It's also sort of a selection event, i.e. click once to select the file, click again to select the name of the file. That doesn't change my opinion that double-clicking to attach is more consistent with how file browsers treat clicks, though. :)
(Reporter)

Updated

5 years ago
Duplicate of this bug: 98635
(Reporter)

Updated

5 years ago
See Also: → bug 707432
You need to log in before you can comment on or make changes to this bug.