725507 - Toolbar in message-header pane lacks icons present in the main toolbar, no longer accessible in a message tab

Status: NEW

(Thunderbird :: Toolbars and Tabs, defect)

Description

[rsx11m]

With the introduction of "tabs on top" by bug 644169 the main toolbar is now hidden in a message tab. Only the message-specific action icons in the message header are available, and only to the extent that the user didn't remove them by customization. Specifically, the following icons are covered:

 - reply
 - reply all / reply to list (as a combination button with reply)
 - forward
 - delete
 - archive
 - junk

The following message-specific icons are present in the main toolbar but cannot be put into the message-header toolbar:

 - file
 - mark
 - tag
 - print

Thus, these functions are now only available through menus or keyboard shortcuts (if known).

(1) The "simple" solution might be to just add those icons to the toolbar in the message-header pane, but then - if the user chose to keep them in the main toolbar - they may be unnecessarily be replicated.

(2) An alternative solution might be to add those icons to the customization palette but introduce a second toolbar which is only visible in a message tab, thus avoiding that the icons are replicated (that's important for users who chose to retain the message-specific icons in the main toolbar).

(3) Allow the main toolbar optionally to be visible also in a message tab, thus avoiding the need to recustomize the message-header toolbar.

The rationale for setting the tracking flags for aurora and beta channels is that this is potentially a major UX issue for users being unable to perform such fairly basic functions for an individual message if opened in a tab.

Comment 1

[Jim Porter (:squib)]

(In reply to rsx11m from comment #0)
> The following message-specific icons are present in the main toolbar but
> cannot be put into the message-header toolbar:
> 
>  - mark
>  - print

These are in the "Other Actions" button.

>  - file

This isn't visible by default, and since you can make it available on all tabs (see below), I don't think this is a problem.

> - tag

This is the only one I see as a real issue, since it used to be there by default, but now it isn't.

> (3) Allow the main toolbar optionally to be visible also in a message tab,
> thus avoiding the need to recustomize the message-header toolbar.

Already possible, more-or-less. Just add the buttons to the tab bar or the menu bar.

Comment 2

[rsx11m]

> These are in the "Other Actions" button.

Hmm, missed that one; so you have a 1-click option in the main toolbar and message window but need a 2-click path to get to it from a message tab (ux-consistency?).

Also, in general, users of herb's CompactHeader extension will run into this trap since they'll likely not have any such option accessible unless they switch to the full headers.

> Just add the buttons to the tab bar or the menu bar.

That's a lot to ask for a "regular" user and likely hard to figure out without guidance (ux-discovery?).

So, what's wrong with (3) simply leaving the main toolbar active in a message tab?

Comment 3

[Jim Porter (:squib)]

(In reply to rsx11m from comment #2)
> > These are in the "Other Actions" button.
> 
> Hmm, missed that one; so you have a 1-click option in the main toolbar and
> message window but need a 2-click path to get to it from a message tab
> (ux-consistency?).

It's not really ux-consistency, since in the default UI, the "mark read" and "print" actions are in the same places: either the main menus, or the Other Actions button. We could add these to the toolbar palette, but I don't think the issue is as pressing as it is for the Tag button, which is part of the default primary UI (i.e. always visible in the 3pane).

> Also, in general, users of herb's CompactHeader extension will run into this
> trap since they'll likely not have any such option accessible unless they
> switch to the full headers.

That's an add-on issue, and should be addressed in the add-on (e.g. by always showing the message header toolbar in a message tab).

> > Just add the buttons to the tab bar or the menu bar.
> 
> That's a lot to ask for a "regular" user and likely hard to figure out
> without guidance (ux-discovery?).

It's no harder than adding custom buttons to any other toolbar. For 3 of the 4 buttons you mentioned, they aren't on any toolbar to begin with, so users with those buttons present are by necessity familiar with toolbar customization (or they know someone who is).

> So, what's wrong with (3) simply leaving the main toolbar active in a
> message tab?

It would be less work to add the relevant buttons to the message header toolbar, which we should do, but I don't agree that we need to track this for 11.0, except for the Tag button.

For 11.0, I don't think we need to address anything but the Tag button, though Mark and Print are probably easy enough to do alongside it. I'm ok with adding Mark and Print (at least eventually), since I plan to eventually make the Other Actions button show all the actions not currently on the message header toolbar. Since Mark and Print are in that list, they'll need to become optional buttons. However, I'm not convinced that File needs to come along too; I'd be interested to see how many people even use that button.

Comment 4

[rsx11m]

(In reply to Jim Porter (:squib) from comment #3)
> > That's a lot to ask for a "regular" user and likely hard to figure out
> > without guidance (ux-discovery?).
> It's no harder than adding custom buttons to any other toolbar. For 3 of the
> 4 buttons you mentioned, they aren't on any toolbar to begin with, so users
> with those buttons present are by necessity familiar with toolbar
> customization (or they know someone who is).

The discovery issue is more like figuring out that one *can* move those buttons to the menu or tabbar rather than just adding them to the toolbar you are currently customizing. Also, the more I think about this workaround the less I like it, given that the main reason for introducing tabs on tab was to allow the toolbar to vary depending on the content displayed. If you "hard wire" those on either bar, that's looking weird to start with and is against that philosophy assuming they'd show up in the composition and address-book tabs as well once those features are implemented:

(Quoting Mike Conley (:mconley) from bug 724213 comment #5)
> This is also quite restrictive.  Thunderbird's UI trajectory is tending
> towards more tab types (Search, Instant Messaging, eventually Compose in a
> tab, eventually Address Book in a tab).  Having the toolbar exist *within*
> the tabs allows us a separation between these functions - and allows for a
> greater degree of customization *within* those tabs.

Comment 5

[Joe Sabash [:JoeS1]]

I think that "discovery" that you can customize the menu-bar is a problem.
Especially since I think you must first drag them out of the mail-toolbar before they become available for the menu-bar (at least I think that step is required)
Maybe an option to automagically transfer what the user had customized into the mail-toolbar might be feasible. But then there is no guarantee that they would all fit.
I predict this is going to cause great confusion. Maybe as much as the pre-enabled features in TB 3.0

Comment 6

[rsx11m]

FWIW, the stand-alone message viewer (Open Message in New Window) has a full main-like toolbar as well, which can be customized separately from the 3-pane window toolbar. So, this toolbar could be "recycled" for the message tab as a variant of option (3).

Comment 7

[Joe Sabash [:JoeS1]]

As far as using the menu-bar as an alternative see bug 725554

Comment 8

[Matthew Atkinson]

I've been using Thunderbird since it was Mozilla, and I didn't realise that you could drag buttons to the tab bar until I read this bug. So, discovery is definitely an issue there. I have the menu bar hidden, because it moves around between my Vista box at home and XP at work, and I can't cope with that (or customise the problem away), so the only place I could put the buttons is on the Tab bar. However, buttons on the Tab bar don't work properly, as they don't display the text next to the picture, so that renders them useless for me. It would be brilliant if this did work properly, as I could get rid of the Mail Toolbar altogether and put the icons all in the Tab Bar where there is always lots of space.

So for me at least, Jim Porter's suggestion to add to the other toolbars doesn't work because of other problems inherent in these toolbars.

I also agree with rsx11m that you shouldn't take an existing UI and change it without doing it properly. This has happened too many times recently, and makes Tbird look like it's developed by people who don't care. You've only to look at Extra Columns (still broken), Menus on Aero Glass (which only this alleviates), and the attachment summary to see what I mean. Please make this right before it's released, don't let it out there half-baked.

Comment 9

[Joachim Herb]

> The following message-specific icons are present in the main toolbar but
> cannot be put into the message-header toolbar:
> 
>  - file
>  - mark
>  - tag
>  - print
> 
These four buttons can be added to the header toolbar if CompactHeader is installed.

If you use the two line mode of CompactHeader the toolbar is always visible. Starting with version 2.0 and Thunderbird 10.0 you can move the header toolbar to the left or right of the message (preview) pain. Then you have the toolbar even in single header mode. 

With discovery: Until now I do not show any page after an upgrade of CompactHeader. Do you think this would be a good idea to show users the customization of the header toolbar/the positioning of the toolbar?

I know that by cloning these (and other buttons) into the header toolbar (palette) CompactHeader violates the assumption that XUL elements with a certain ID should only exist once. But it looks like it's working.

Comment 10

[Thomas D. (:thomas8)]

Missing Tag button on mail header toolbar is Bug 456169, open since 2008.

Comment 11

[rsx11m]

Thomas, thanks for identifying the related bugs.

To add this to the record, there was also a comment from Blake in the GS thread in support of option (3) or its variant in comment #6 (please correct me if I'm reading your post wrong):

(Quoting Blake Winton (Official Rep) from http://gsfn.us/t/2mtnc#reply_8000544):
> While I agree that disabling tabs-on-top is unlikely to happen, I
> still think that there are other things we could do to fix the
> original poster's problem. For instance, showing the toolbar, or
> perhaps better, showing a message-specific toolbar, and getting rid
> of the buttons in the message header...

The last part of "getting rid of the buttons in the message header" is specifically interesting in light of this discussion.

Comment 13

[rsx11m]

Reopening per discussion in bug 728309 which intends to implement variant (3) at least for 11.0, so this bug here can be used to investigate further where to go from there (including all considerations and concerns stated so far in the previous comments).

Comment 14

[rsx11m]

I'm making a few adjustments now that the mitigating fix from bug 728309 has been checked in and the main-toolbar users aren't faced with a loss of functionality any more once 11.0 comes up. Thus, we can concentrate here on any work to be done for trunk without the constraints of the upcoming release.

Comment 15

[rsx11m]

So, the current status based on 11.0 beta 3 is:

 - Both message and search tabs have a main toolbar again;
 - this tab is shared, i.e., any customization in one tab will
   result in corresponding changes in the other tab;
 - View > Toolbars > Mail Toolbar affects all tabs equally.

Possible direct follow-up modifications:

 - Per comment #6, share message-tab toolbar with stand-alone window;
 - View > Toolbars > Mail Toolbar should be separated per tab.


It may also be worth reiterating what likely usage scenarios are:

(A) There is the user just started and hasn't done any customization at all, thus the current implementation may be fine with that user class already.

(B) A user may have migrated from 2.0 or earlier over 3.x to a current version and chose at that time in the Migration Assistant to retain the 2.0 toolbar customizations; consequently, that user may have cleared out the message-header toolbar and/or is hiding it along with the "other actions" button with the suggested userChrome.css overrides, thus performing all action from the main toolbar (with the bug 728309 now allowing this scenario again).

(C) The user has only basic icons/buttons on the main toolbar but wants to maximize the actions possible from the header-pane toolbar.

(D) The user wants to minimize any visible icons to either use keyboard shortcuts or the "other actions" menu instead.

(E) A user aiming for minimizing window height (i.e., likely using the CompactHeader add-on) would probably like to hide the main toolbar in a message tab and put all icons needed into the message-header pane, which according to comment #9 seems to be possible.

So, the intended solution should satisfy at least those.

(In reply to Jim Porter (:squib) from comment #3)
> ... plan to eventually make the Other Actions button show all the  
> actions not currently on the message header toolbar.

That's actually a good idea which got lost in the overall discussion, and it should be a good way to balance (C) vs. (D) while avoiding redundancy between the buttons and the menu.

Comment 16

[Mark Banner (:standard8)]

Not tracking for this as the main issues are resolved and the remaining issues seem like nicer follow-ups.