516294 - Right-click on attachment pane whitespace does not deselect attachments

Status: REOPENED

(Thunderbird :: Message Reader UI, defect)

Description

[Thomas D. (:thomas8)]

When right-clicking on white-space within attachment pane, selected attachments are not deselected. This in turn brings up the wrong context menu, i. e. we get the context menu for single attachment file instead of the general context menu for attachment pane that has "save all" command. Currently you need three clicks to get there.

Comment 1

[Wayne Mery (:wsmwk)]

why would r-click whitespace deselect?

Comment 2

[Phil Ringnalda (:philor)]

Probably because that's what the Finder, the Gnome File Browser, and Windows Explorer, where most people get their expectations for the behavior of icons representing files, all do.

Comment 3

[Thomas D. (:thomas8)]

Though the bug as such is certainly minor, its effects are quite annoying: I had forgotten about this bug, and I wasn't able to find the "Save all attachments" command from within attachment pane *at all*, although I'm an experienced user. I conclude that less experienced users have no chance of ever finding the "save all attachments" command, because it's missing for selected attachments, and even for right-clicks outside attachments icons, due to this bug, you only get it after having deselected all attachments, which is very counter-intuitive.

Comment 4

[Thomas D. (:thomas8)]

Bug 533921 with more detailed STR shows that this bug is actually worse than reported here: Right-clicking on attachment area blank space can even bring up the context menu of a previously selected attachment from a completely different message. Weird.

-> Forward-Duplicate to 533921.

So altogether, attachment pane is really up for surprises:
- (shift)Del on a focussed attachment deletes the msg instead of attachment
- Ctrl+A with focus in attachment pane selects all msgs instead of all attachments
- right-clicking on an attachment will not focus it
- right-clicking on blank attachment area will not unfocus selected attachments and can even bring a totally unrelated context menu from another msg (this bug)

Along the lines of Phil's comment 2: What if we could just make attachment pane UI behave like any other list of files in Finder, Gnome File Browser, and Windows Explorer? For a start, respect focus for keyboard inputs. Always.

Comment 5

[Jim Porter (:squib)]

De-duping this, since bug 533921 didn't change anything for this particular case.

Comment 6

[Thomas D. (:thomas8)]

Correct. Thank you, Jim!

Related:
Bug 466060 - show "Save All", "Detach All", "Delete All" context menu items when one or more attachments are selected, like in Thunderbird 2

The common purpose of these two bugs is to make "save all" etc. easily and efficiently available from the respective contextual menus (i.e. in-place).

Comment 7

[Jim Porter (:squib)]

Fixed by bug 630759.

Comment 8

[Thomas D. (:thomas8)]

Earlybird 8.0a2 2011-08-19 on Win7

Reopening. Right-clicking on whitespace outside selected attachments still does *not* deselect them, even though we are now showing the correct context menu for *all attachments*.

Right-clicking on whitespace should deselect other attachments because
a) OS File Managers do the same, as per comment 2
b) it is confusing to get a context menu for *all* attachments while at the same time still having an active selection of *some* attachments - certainly we are violating one or more ux-principles here.

I suspect this is easy to fix.

Comment 9

[Jim Porter (:squib)]

(In reply to Thomas D. from comment #8)
> b) it is confusing to get a context menu for *all* attachments while at the
> same time still having an active selection of *some* attachments - certainly
> we are violating one or more ux-principles here.

ux-feedback, I suppose. And ux-consistency for the OS, but we're being totally consistent with the rest of Thunderbird, since right-clicking never changes the selection. Aside from the fact that in-app consistency is a higher priority than OS consistency, I think this behavior is correct: we should be trying to minimize the number of actions that destroy state (in this case, the selected attachments). This was one of clarkbw's main objections to the attachment pane: it's too easy to accidentally deselect all the attachments (or all but one). We should probably try to avoid doing this unless absolutely necessary (to adhere to ux-control and ux-error-prevention). However, we should probably update the UI to temporarily show no attachments selected.

That said, I don't feel terribly strongly about this.

Comment 10

[Thomas D. (:thomas8)]

Reopening per comment 8.

First of all, I'm still thankful every day for Jim's great work to improve the UX of the attachment panes. We've gone a long way in returning user control and standard-conforming design and behaviour to the attachment panes. It's my hope we'll continue along those lines...

(In reply to Jim Porter (:squib) from comment #9)
> (In reply to Thomas D. from comment #8)
> > b) it is confusing to get a context menu for *all* attachments while at the
> > same time still having an active selection of *some* attachments - certainly
> > we are violating one or more ux-principles here.

I've gone through the current design and behaviour in a more systematic way, trying to find out why - even in view of our hidden agenda of semi-permanent selections a la Bryan - this still feels odd, for the particular problem of this bug.

> ux-feedback, I suppose. And ux-consistency for the OS, but we're being
> totally consistent with the rest of Thunderbird, since right-clicking never
> changes the selection.

Imho, that's another big problem (which needs to be discussed elsewhere).

> Aside from the fact that in-app consistency is a
> higher priority than OS consistency, I think this behavior is correct: we
> should be trying to minimize the number of actions that destroy state (in
> this case, the selected attachments). This was one of clarkbw's main
> objections to the attachment pane: it's too easy to accidentally deselect
> all the attachments (or all but one). We should probably try to avoid doing
> this unless absolutely necessary (to adhere to ux-control and
> ux-error-prevention).

OK, let's look at the use cases for "right-clicking on whitespace": When user deliberately right-clicks on whitespace outside selection, does it make sense to preserve an existing selection of one or more out of all attachments?

*** 3-Pane ***

Some facts about the current behaviour:

1) whitespace context menu only allows acting on *all* attachments
2) whitespace context menu correctly *does not* allow acting on *some* selected attachments
3) In all other applications and every OS (except us!), right-clicking outside selection will deselect the old selection

So what are the intentions of a user who right-clicks outside selection?

a) because of 3), we can safely assume that a majority of users have undergone extensive habit formation by OS and application experience, so they *do not* expect to act on the selection when they deliberately click /outside/ the selection. On the contrary, they will correctly expect (or even want!) their current selection to be deselected (like Jim correctly expecting single /left-click/ on whitespace to deselect in composition, bug 707424, comment 1).

b) some users might wrongly assume that they can act on the selection when right-clicking /outside/ the selection. Given 1) and 2), we correctly do *not* let them act on some selected attachments because they clicked outside the selection (so eventually, they'll have to right-click *inside* the selection anyway to get the job done). However, our UX-feedback is very confusing and ambiguous for such users:
- whitespace context menu correctly has action-all only, truthfully indicating that they *cannot* act on the selection from that external menu
- however, at the same time we do *not* deselect the partial selection! That's misleading, because they can even wrongly assume that whitespace context menu refers to and allows them to act on that selection (as in "Open all [of current selection]"! (violation of UX-feedback)

Let's face it (conclusion):
1) The only way to act on some selected attachments is right-clicking *within/on* the selection.
2) Deselecting ("losing") the selection for outside clicks within the list is a very good and clear way of *helping* users to understand the correct use pattern, instead of confusing them with mixed messages and ambiguous ux-feedback.
3) Furthermore, deselecting on outside right-click is externally consistent with all other Apps/OS out there. Anything else will be unexpected and confusing to both expert and novice user.


*** composition ***

For completeness, I'd like to test the same for composition's attachment pane, too... Basically, everything said for the 3-pane above also applies to composition (see above).

There's a small variant about what you can currently do with the whitespace context menu:
1 whitespace context menu allows adding attachments, select all, but *no* actions for all attachments yet (inconsistent with 3-pane!).
2 whitespace context menu *does not* allow acting on *some* selected attachments.

So currently on whitespace context, there are *no* actions at all to act upon existing (selected) attachments. It's much more likely users just use whitespace-right-click to add more attachments. So again, there is absolutely no point in keeping an old selection, on the contrary, we are just supporting bad habits for a minority of users who wrongly assume they can act on selection from outside selection.

> However, we should probably update the UI to
> temporarily show no attachments selected.

As shown above, it's very unlikely that temporary deselection has any benefit over just deselecting. Users intending to act on partial selection will and can easily do so by right-clicking *inside* selection (which is technically the only way to do so). Our current UI has not been designed for permanent selections, and as a matter of fact, current selections are volatile for the majority of possible interactions, with whitespace right-click being a confusing exception to that rule (this bug).

> That said, I don't feel terribly strongly about this.

That's helpful for getting this bug out of the way, for which your coding experience would be much appreciated! :)