Closed Bug 738916 Opened 12 years ago Closed 10 years ago

Icons of unfocused selected attachments should not be faint (both message reader & composition)

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 32.0

People

(Reporter: thomas8, Assigned: Paenglab)

Details

Attachments

(2 files, 2 obsolete files)

Something minor which caught my eye...

STR

1 read or compose mail with some (say 3) attachments of same file type
2 select one or more, but not all attachments using ctrl+click
3 move focus to msg body

Actual result

- we preserve the selection (arguable, but intended)
- file names of selected attachments have grey background shade to indicate unfocused selection (ok)
- file icons of unfocused selected attachments are faint, hence visually very distinct from non-selected attachments (see attached screenshot):
Imo, this is confusing UX because on Windows OS, faint icons signal that this file has been cut. Especially now with filelinks around, user starts to wonder if there is something wrong with those faint-iconed attachments: Are they missing, or broken, or not fully uploaded, or what?

Expected result

- file icons of unfocused (!) selected attachments should not be visually different from normal attachment file icons
- especially, they should not be faint because faint icons wrongly suggest that these files have been cut or deleted or are inaccessible or simply that there is any significant difference between unfocused(!) selected and unselected attachments, which is confusing und not consistent with external applications.
- We already indicate unfocused selection with grey shade on file name, that's unambiguous and sufficient.
For comparison, this doesn't happen in SeaMonkey 2.9 (Gecko 12.0) in either the Message Viewer or Composition windows, so that may be either a simple theme issue or something related to the way how those panes are populated.

Given that the highlighting changes already between focused and unfocused pane, I'd agree that graying the icon itself isn't helping much to convey that status and just makes it more difficult to identify which file type was selected.
I'm wondering about the behaviour which causes this bug, namely that we preserve selection of attachments even after attachment pane is already inactive/de-focused (e.g. focus/cursor now in body for typing). What's the usecase for preserving selection?

Preserving a /single-attachment/ selection doesn't help much at all imho.
Atm, the only possible actions on /multiple/ selected attachments are "Remove" or "Convert attachment to > Normal | YouSendIt etc."
So I imagine that for those actions (or any other we might allow in the future), users will make their selection and then act on it immediately (e.g. delete them).

I can't think of any scenario where preserving attachment selection when focus is no longer in attachment pane makes sense. Anybody?

Preserving stale selections even comes with risks: if there's a previously selected attachment which is currently out of view (due to scrolling), user might forget existing selection and e.g. start to Ctrl+select some other attachments in the visible area. But the hidden selection will still be preserved, potentially resulting in dataloss (for remove command) or other erroneous behaviour. We've had the same problem for Contacts Side bar, and have eliminated it there because of ux-error-prevention.

So can't we just deselect all attachments when attachment pane loses focus (within TB)?
Flags: needinfo?(squibblyflabbetydoo)
Flags: needinfo?(josiah)
Flags: needinfo?(acelists)
This is intentional, and it works just like Windows Explorer and other file managers. We could drop the icon highlight, since I now notice that Windows XP's Explorer doesn't highlight the icons of selected items when unfocused (although I'm fairly sure I checked that state when I checked the original patch in).

(In reply to Thomas D. from comment #2)
> I can't think of any scenario where preserving attachment selection when
> focus is no longer in attachment pane makes sense. Anybody?

Any time you're attempting to multitask (e.g. you need to open another window for something, or you realized you should type another sentence into the message body before you forget).

> Preserving stale selections even comes with risks: if there's a previously
> selected attachment which is currently out of view (due to scrolling), user
> might forget existing selection and e.g. start to Ctrl+select some other
> attachments in the visible area.

I don't buy this as an actual problem. If we're worried about dataloss here, we should throw up a prompt, at least saying "Are you sure you want to delete these N files?" (Or maybe even listing the files.) Allowing Undo would be nice too, but my experience with the undo manager in Mozilla is that it's a bit complex.

Furthermore, if you're trying to Ctrl+select, generally, you only start holding Ctrl after you've already selected something. At least to me, "Ctrl" means "Select more", so I'd never do that if I wanted to start making a new selection set.

Frankly, it sounds more to me like the color of the icon is bothering you, and you're trying to present an argument for changing the theme. That's reasonable (since it's wrong), but I don't think there's much of an argument to change the behavior of the attachment pane.

> We've had the same problem for Contacts Side bar, and
> have eliminated it there because of ux-error-prevention.

I think this was the wrong decision, but then I don't use the Contacts Sidebar (and frankly don't see why anyone would when there's autocomplete).
Flags: needinfo?(squibblyflabbetydoo)
Attached patch attachementIconFilter.patch (obsolete) — Splinter Review
I'm with Jim, removing the selections because they aren't focused isn't the right way and is not the topic of this bug. Explorer and also the tools on Linux and OS X aren't deselecting items when they are scrolled out of view.

This patch removes the filter on attachmentcell-icon on Linux and Windows. On both platforms I don't see such a behavior on selected icons when in list view.
Assignee: nobody → richard.marti
Status: NEW → ASSIGNED
Attachment #8424342 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 8424342 [details] [diff] [review]
attachementIconFilter.patch

Can we keep the image filter for the selected-and-focused state? That's consistent with both Windows XP and Linux (I'm using Mint, but I imagine it's the same on Ubuntu).
Attachment #8424342 - Flags: review?(squibblyflabbetydoo) → review-
Oh, and note that on Windows Aero platforms, we *don't* use the image filter at all (which is consistent with the rest of Windows), so there's nothing to do for Aero.
Attached patch attachementIconFilter.patch (obsolete) — Splinter Review
I clicked on a row in not focused Explorer and the icon wasn't selected. But when I selected a other row then the icon is also selected. So okay you're right.
Attachment #8424342 - Attachment is obsolete: true
Attachment #8424347 - Flags: review?(squibblyflabbetydoo)
(In reply to Jim Porter (:squib) from comment #3)
> This is intentional, and it works just like Windows Explorer and other file
> managers.

True.

> We could drop the icon highlight, since I now notice that Windows
> XP's Explorer doesn't highlight the icons of selected items when unfocused
> (although I'm fairly sure I checked that state when I checked the original
> patch in).

Indeed, Windows XP isn't consistent about the highlighting of icons, especially in detailed list mode (when selected and un-focused, icon highlight is at first wrongly preserved in that mode; but goes away when you focus another app and go back to explorer). Any other mode with bigger icons un-highlights the icons of selected files if not focused, which looks like the intended behaviour.

> (In reply to Thomas D. from comment #2)
> > I can't think of any scenario where preserving attachment selection when
> > focus is no longer in attachment pane makes sense. Anybody?
> 
> Any time you're attempting to multitask (e.g. you need to open another
> window for something, or you realized you should type another sentence into
> the message body before you forget).

Fair enough, I see.

> > Preserving stale selections even comes with risks: if there's a previously
> > selected attachment which is currently out of view (due to scrolling), user
> > might forget existing selection and e.g. start to Ctrl+select some other
> > attachments in the visible area.
> 
> I don't buy this as an actual problem. If we're worried about dataloss here,
> we should throw up a prompt, at least saying "Are you sure you want to
> delete these N files?" (Or maybe even listing the files.) Allowing Undo
> would be nice too, but my experience with the undo manager in Mozilla is
> that it's a bit complex.

Well, let's keep it as-is for now, attachments are usually not the original files so I think users will prefer to delete them without confirmation.

> Furthermore, if you're trying to Ctrl+select, generally, you only start
> holding Ctrl after you've already selected something.

Generally yes, but nothing stops users from pressing Ctrl when selecting the first item, too.

> Frankly, it sounds more to me like the color of the icon is bothering you,
> and you're trying to present an argument for changing the theme. That's
> reasonable (since it's wrong), but I don't think there's much of an argument
> to change the behavior of the attachment pane.

True, and thanks for correcting me correctly :)
I'm happy with that approach as it fixes the problem of comment 0.

> > We've had the same problem for Contacts Side bar, and
> > have eliminated it there because of ux-error-prevention.
> I think this was the wrong decision,

Sorry, I misremembered that one, so it's not like I said.
The problem on contacts side bar was sticky focus and/or selections when you *change* between ABs or search filters, in which case applying previous focus/selection on an entirely unrelated set of contacts didn't make sense, and just focusing but not selecting the first entry on a virgin list (like Windows Explorer) was considered sufficient, consistent and less error-prone for Ctrl+Select (Bug 900541, Bug 715573, Bug 364760).

> but then I don't use the Contacts
> Sidebar (and frankly don't see why anyone would when there's autocomplete).

Oh, there are very interesting usecases for contacts side bar when you're dealing with varying subsets of contacts (like mailing lists, but more flexible). Autocomplete basically handles only one address at a time, which isn't useful for "tagged" groups of contacts. With side bar and intelligent pseudo-tagging on AB cards (say you add +tbux+ to display name of all TB UX contributors), you can then filter on various sets based on "tags" or company name etc. without defining fixed mailing lists, and then add the entire result set into recipient area in one go (as opposed to having to add each person sequentially via autocomplete, which would be *very* clumsy the further down you get in the list).

And before the landing of Bug 529584 and Bug 558931, for which a certain notorious UX contributor persistently campaigned, it was not even possible to search for anything but the beginning of AB fields, so you couldn't even have searched for "+tbux+" when the display name was "John Doe +tbux+", and much less for "John +tbux+" or "+tbux+ +tbqa+" when the display name was "John Doe +tbux+ +tbcoder+ +tbqa+", all of which are now possible, and we're even planning to finally include Nick Name field and some others into the AB/contacts side bar search, can you believe it... (Bug 118624).
Flags: needinfo?(josiah)
Flags: needinfo?(acelists)
(In reply to Richard Marti (:Paenglab) from comment #7)
> Created attachment 8424347 [details] [diff] [review]
> attachementIconFilter.patch

Richard, thanks for picking this up; I'll be happy to see this fixed.

And while this bug is trivial in terms of functional severity, I think the potential uneasyness/confusion for average users should not be underestimated (like why some attached files are strangely dimmed off as if in a Cut and Paste operation...)
Comment on attachment 8424347 [details] [diff] [review]
attachementIconFilter.patch

Review of attachment 8424347 [details] [diff] [review]:
-----------------------------------------------------------------

r-, but this is pretty close to what we want. See comments below.

::: mail/themes/linux/mail/attachmentList.css
@@ -50,5 @@
>  }
> -
> -attachmentlist:focus > attachmentitem[selected="true"] .attachmentcell-icon {
> -  filter: url("chrome://messenger/skin/imageFilters.svg#selected-focus");
> -}

Other way around, please. Keep this CSS block and remove the other. That's the behavior I see on WinXP/Linux (selected-and-focused has a filter, selected-but-not-focused has nothing).

::: mail/themes/windows/mail/attachmentList.css
@@ -50,5 @@
>  }
> -
> -attachmentlist:focus > attachmentitem[selected="true"] .attachmentcell-icon {
> -  filter: url("chrome://messenger/skin/imageFilters.svg#selected-focus");
> -}

Ditto.
Attachment #8424347 - Flags: review?(squibblyflabbetydoo) → review-
Yep, this should do it.
Attachment #8424347 - Attachment is obsolete: true
Attachment #8424418 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 8424418 [details] [diff] [review]
attachementIconFilter.patch

Review of attachment 8424418 [details] [diff] [review]:
-----------------------------------------------------------------

rs=me. Thanks for the patch!
Attachment #8424418 - Flags: review?(squibblyflabbetydoo) → review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/83d9d43c13c5
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 32.0
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: