535021 - Folder pane: Arrows in header are too subtle

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Ben Bucksch (:BenB)]

several users somehow unintentionally switched the view in the folder pane to only "unread folder", "fav", .., and didn't know how to change it back or that it's even possible. the little arrows there are maybe too subtle. They are tiny (just a few pixels high) and back on gray.

If you don't notice the arrows and have the wrong view, you must conclude that TB3 is unusable, and some users did, at least one quite vocally.

(This is a good example how important standard GUI elements with standard look are. It may be boring, but helps usability tremendously.)

Suggestion: Maybe, instead of the horizontal arrows, make the "all folders" header (which is currently not even clickable) a normal dropdown, with more or less normal GUI styling.

Comment 1

[Wayne Mery (:wsmwk)]

related factors -- xref 
bug 534312 Arrows to switch between folder views are too small 
Bug 492854  View / Folders menu unaware of the folder view set with the folderview-cycler 

This is a common theme in forums also. Perhaps also on gsfn. Perhaps having both arrows and dropdown would be useful

Comment 2

[Ben Bucksch (:BenB)]

Attachment: Screenshot, gnomestrip (Linux)

I don't know which platform the user above was on, but they are tiny for me on Linux as well. Looking at the zoomed picture, the arrows are only 3-5 px high.

I don't think making them merely bigger will solve the problem, though.

Comment 3

[rsx11m]

(In reply to comment #1)
> bug 534312 Arrows to switch between folder views are too small 

This one is specific to the active area where you can click on the arrows, not the arrow size itself (and also for Windows Classic rather than the Vista/Win7 desktop theme).

Comment 4

[Wayne Mery (:wsmwk)]

right, bigger arrows doesn't improve discoverability or understanding.  However,  people who currently use arrows would likely morn losing them.

Comment 5

[Ben Bucksch (:BenB)]

I'd argue a dropdown is even faster. You can select the right option with 1-2 clicks (click and hold, select one of several options that open) rather than 3-5 clicks to page through the options until you have the one you like. The dropdown (whole header) is also a *much* bigger click target.

Comment 6

[rsx11m]

Well, you could keep the arrows and just make sure they can be actually used, then add clicking on the heading left to it opening the drop-down menu. This would make both sides happy.

Comment 7

[Bryan Clark (DevTools PM) [:clarkbw]]

We have some styling problems with the buttons in certain themes which makes them tremendously small.  I think we could fix those issues to make the arrows a usable size again however I agree with Ben that we might as well take the time to make the system better.

The arrows are fast for switching views but a drop down menu would let you select exactly the view you want instead of cycling through views you don't.  Also I think there will be a benefit from making the widget look more like a selection widget than it does now.

Lets just try to put some kind of a combo selector together.  I think we'll need some specific styling on this so it doesn't pop out too much in this view but it seems like it's worth a shot.

Comment 8

[Bryan Clark (DevTools PM) [:clarkbw]]

I'm going to mark this blocking the 3.0.1 release even though that's a tight time frame I think this is going to be very important plus it's fairly simple with a lot of positives for those upgrading to a new default.

Ben, are you going to work on this? or should I find someone else?

Comment 9

[Ben Bucksch (:BenB)]

Can you find somebody else, please? Although I'd like to get it fixed, I won't have time. Sorry. :(

Comment 10

[Mark Banner (:standard8)]

(In reply to comment #9)
> Can you find somebody else, please? Although I'd like to get it fixed, I won't
> have time. Sorry. :(

I'll push this in Andreas' directory to start off with then.

Comment 11

[Andreas Nilsson (:andreasn)]

All right, I'll see what I can do about this one!

Comment 12

[Andreas Nilsson (:andreasn)]

Attachment: in progress fix

This turns things into a dropdown.
Two issues I would need some help with:
* If I remove <label id="folderpane-title"/> things stop working. Why?
* I can't figure out a good way to insert the string called "Folders" so now it's called only "Smart" instead of "Smart Folders".

Comment 13

[Andreas Nilsson (:andreasn)]

Attachment: in progress fix v2

this takes care of the folders part, but still have the previous issue remaining.
I also noted that I need to make sure the dropdown change accordingly when changed via View > Folders > Foo

Comment 14

[Andreas Nilsson (:andreasn)]

Attachment: in progress fix v3

Comment 15

[Andreas Nilsson (:andreasn)]

Attachment: working fix

This takes care of all the issues I could see in the previous patches. Code-wize not optimal at all probably, but it fixes the issue :)

Comment 16

[Andreas Nilsson (:andreasn)]

Attachment: without commented out parts

noted a small part I had commented out in one of the files instead of removing it all together

Comment 17

[Andreas Nilsson (:andreasn)]

Attachment: screenshot to ease review

Comment 18

[Ben Bucksch (:BenB)]

Andreas, the dropdown is way too big. Please make sure that the dropdown gets only as much space as needed. I.e. keep the <spacer flex="1"> and remove the flex from the <menulist>.

Comment 19

[Wayne Mery (:wsmwk)]

I like the drop down, but expanding on my comment 1 re: cycle arrows ...

I think removing well established UI (even though for some it's not great) that existing users are accustomed to, and introducing it without testing feedback and in mid release is a bad idea.  IMO they should be retained for now.

Comment 20

[David Ascher (:davida)]

re: Comment #19, the problem that this bug is addressing is the fact that many (how many?) users of TB2 never even "saw" the UI, and the switch to Smart Folders therefore looked undoable.  I agree that introducing any new UI in a .0.x release is risky, but I also think we can't switch away from Smart Folders as a default due to the string baggage implied in the Migration Assistant.

Three options I can think of:

1) keep existing UI, just make the arrows bigger/more visible
2) do what's in andreas's patch
3) add more words in the web-hosted page explaining about smart folders and somehow mitigate the problem through words (& maybe pictures of UI).

I'm not sure how many of the above we could do simultaneously.

Comment 21

[Ben Bucksch (:BenB)]

Wayne, see comment 7.

Comment 22

[Andreas Nilsson (:andreasn)]

I'll whip up a patch with bigger arrows as well so we have more to choose from.

Comment 23

[Mark Banner (:standard8)]

(In reply to comment #20)
> Three options I can think of:
> 
> 1) keep existing UI, just make the arrows bigger/more visible
> 2) do what's in andreas's patch
> 3) add more words in the web-hosted page explaining about smart folders and
> somehow mitigate the problem through words (& maybe pictures of UI).

For 3.0.1 I think it is too late for option 2. I think we should give it a try on trunk, and give the opportunity for general feedback as well as for the l10n teams to provide feedback re landing it on 3.0.x, 2-3 days isn't enough for that.

I therefore think we could also try out option 1 in 3.0.1. We'll still likely get some users upgrading from 2 to 3.0.1 and so I'd expect some feedback there.

Comment 24

[Andreas Nilsson (:andreasn)]

Attachment: arrows patch (gnomestripe part)

Here is a patch using bigger arrows. Windows patch coming up after reboot! :)

Comment 25

[Andreas Nilsson (:andreasn)]

Attachment: arrows patch (gnomestripe part) v2

forgot the graphics :)

Comment 26

[Andreas Nilsson (:andreasn)]

Attachment: gnomestripe+qute patch with arrows

Here is a patch for both Linux and Windows. Are the indicators on Mac good enough already?

Comment 27

[Blake Winton (:bwinton) (:☕️)]

Attachment: Screenshot of the current version for the Mac.

You tell me.  ;)

I think they're a little small, but then, I only use them once per profile, so I don't know if having them bigger would be any better.

Later,
Blake.

Comment 28

[Andreas Nilsson (:andreasn)]

Attachment: solid button approach

here is another approach closer to the one used on Mac for Linux and Windows (make them look like buttons always, not only on hover)

Comment 29

[Wayne Mery (:wsmwk)]

(In reply to comment #27)
> Created an attachment (id=420544) [details]
> Screenshot of the current version for the Mac.
> 
> You tell me.  ;)
> 
> I think they're a little small, but then, I only use them once per profile, so
> I don't know if having them bigger would be any better.

IMO that looks great, because of the outline plus the light background.  Far better than windows' black on medium dark grey/blue background - and the arrows which visually disappear as in the gnomestrip screen shot  attachment 417831 [details]

Comment 30

[Andreas Nilsson (:andreasn)]

Attachment: screenshot of that patch in action

Here is a screenshot of patch 420545 in action

Comment 31

[Wayne Mery (:wsmwk)]

screenshot done without mouse over the buttons?
if so, that's nice

Comment 32

[Andreas Nilsson (:andreasn)]

(In reply to comment #31)
> screenshot done without mouse over the buttons?

Yup!

Comment 33

[Andreas Nilsson (:andreasn)]

Attachment: screenshot of the patch 420543

and here is a screenshot of the patch in comment #26

Comment 34

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 420066 [details] [diff] [review]
without commented out parts

Thanks for this patch Andreas!  I think it's been agreed on that there has been too little time available for testing of this change so we should go with something simpler like the alternate proposals.  We can develop this solution further for the 3.1 release.

Comment 35

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 420729 [details]
screenshot of the patch 420543

I like this larger arrow in the button approach though I haven't seen this in Windows yet so it might make sense to get a try-server build done so that could be tested by tonight.

Comment 36

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 420543 [details] [diff] [review]
gnomestripe+qute patch with arrows

Tried out the try server build and it looks good on Vista in a couple different theme variations.

http://s3.mozillamessaging.com/build/try-server/2010-01-08_13:[e-mail]-st8-folderpane/[e-mail]

Comment 37

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 420543 [details] [diff] [review]
gnomestripe+qute patch with arrows

Does anyone want to take the code review on this?

The only thing I see that I don't quite understand is why we have this rule for gnomestripe

 .folderview-cycler {
   -moz-padding-end: 0px !important;
+  min-height: 24px;
+  min-width: 24px;
 }
 
and not the same for qute?

Comment 38

[Andreas Nilsson (:andreasn)]

(In reply to comment #37)
> The only thing I see that I don't quite understand is why we have this rule for
> gnomestripe

Without it, the target area on hover isn't as big as it is under Windows.

Comment 39

[Andreas Nilsson (:andreasn)]

Attachment: updated bigger arrows patch

"Without it, the target area on hover isn't as big as it is under Windows."

Seems this was incorrect, here is a updated patch without the height and width of 24 in it.

Comment 40

[Andreas Nilsson (:andreasn)]

Attachment: and one more bigger arrows patch

Mark noted the jar.nm file referred to the files foldercycler-arrow-left.png and foldercycler-arrow-right.png one time too many (two is ok, because of XP and aero, but three is not)

Comment 41

[Mark Banner (:standard8)]

Comment on attachment 420985 [details] [diff] [review]
and one more bigger arrows patch

r+a=Standard8

Comment 42

[Mark Banner (:standard8)]

Checked into trunk: http://hg.mozilla.org/comm-central/rev/2927fc566fc8
and branch: http://hg.mozilla.org/releases/comm-1.9.1/rev/716660302fc1

Marking as fixed for 3.0.1 - I suggest we deal with follow-ups or other options in separate bugs.