Implement a new vertical toolbar, which we could call "Spaces", in order to better organize all the toolbar buttons that open a different View/Tab, like Calendar, Tasks, Chat, Address Book, etc.

This toolbar will be collapsible in case users don't want to see it, turning into a overflow popup panel container to list all the toolbar buttons available.

We might also consider offering an API for add-on developers in order to automatically add their "generig" add-on button in case they need to open another view or tab.

In this first screenshot, I'm listing all the actions inconsistencies of our current main toolbar organization.

Here's a mock-up of the potential implementation.

I like the concept and you should definitively implement this.

Things you might consider which I find not optimal from your mock-ups:

1. The buttons in the main toolbar are moving with the state of the spaces toolbar.
2. You collapse the toolbar at the bottom of the window but expand it at the top.

What about making the spaces toolbar a little bit higher up to the level of the main toolbar? Always keep the expand/collapse button in the first position of the main toolbar, but have an optical separation from the other buttons of the spaces toolbar since it doesn't open a tab but influences the toolbar itself.

The buttons in the main toolbar are moving with the state of the spaces toolbar.

Sorry, I'm not sure I understand what you mean.
If you're referring to the Chat and Calendar buttons, those would not be there anymore but only in the Spaces toolbar (unless a user customizes the main toolbar to put them back).

What about making the spaces toolbar a little bit higher up to the level of the main toolbar?

Ah yes, I had a note about this but I forgot to update the mock-up. Good point.

Always keep the expand/collapse button in the first position of the main toolbar, but have an optical separation from the other buttons of the spaces toolbar since it doesn't open a tab but influences the toolbar itself.

I'll consider that, thanks.
The "expand" button is not really an expand, but it opens a popup panel with the menu list of button + label, and then a menu item to "Expand" again the toolbar.

(In reply to Alessandro Castellani (:aleca) from comment #3)

Sorry, I'm not sure I understand what you mean.

In your mock-up, the Get Mail button is the first button in the main toolbar when the spaces toolbar is expanded, but only the second button when it is collapsed.

Ah yeah, I see.
Well, yes, that's because the overflow button for that bar gets revealed once the bar is collapsed.
I don't see it as a big deal as the collapsing of a toolbar is an action that shifts the UI and it's triggered by a user.
Anyway, is definitely something to consider once we see it in action.

There are (at least) two issues here: The spaces bar itself, and the tabs.

I don't have a strong opinion on the spaces bar as such; though I don't like the use of icons-only rather than icons+text. They're a bit too vague, and require too much mental effort to figure out. This is especially true due to their monochromaticity (sp?) . The lack of visible text ("Calendar", "Tasks") is perhaps a benefit of the current two buttons for Tasks and Calendar - but only in that it makes it easy to ignore them... if you do want to be aware of them, then the text is missing.

Of course, if one does go with Icons+Text, then the spaces bar becomes pretty large, and may no longer make sense. A couple of other possibilities:

1. Change the menu layout, so that one of the menus has these navigation commands prominently at the top. Perhaps like the "Window" menu in other applications.
2. Have spaces be a toolbar which can be placed either to the right of the main toolbar, or at the left, right or bottom edge of the window; and like other toolbars, allow the choice of icons, icons+text or text only.

The other point is that I really don't want the address book in a tab! It's important that it be in its own window. I am also kind of skeptical about Tasks in its own tab, because it seems like too much real-estate for tasks rather than combining them somehow with some other content. But - I don't have any intuition about what I would do with Tasks exactly.

There is also the 'Home' tab. I don't see how that's a good idea. That seems redundant.

Have spaces be a toolbar which can be placed either to the right of the main toolbar, or at the left, right or bottom edge of the window; and like other toolbars, allow the choice of icons, icons+text or text only.

Good suggestion. We will consider this.

It is a good start indeed... thank for tackling it...

I would suggest:

• Make each icon bigger + less space between the icons (a bit like a taskbar/dock OS style) to ease identification, access and therefore navigation
• A mouse over the icon could expand the column to the right to show text in addition of icon - so icon only when not moused over - icon+text when mouse over... some may not like it so you could have an option to disable this feature possibly... don't know...
• Allow end-users to expand the column towards the right to show more icon maybe up to four on one line? A bit like Gimp tool panel...
• Add horizontal line separation from top icons (belonging to TB core features) and others icons that may come from add-on, favorites, etc... possibly (long term)

Some additional suggestions following open discussion here https://thunderbird.topicbox.com/groups/ux/T6f0a27ad65e1fac5/proposal-implement-a-spaces-toolbar

• Allow access to Settings - My suggestion: add one Settings button to access all Settings in TB - Settings Tab (or else way) as per separate discussion https://thunderbird.topicbox.com/groups/ux/Tf01ae86e0bf67311/merging-all-tb-options-account-settings-add-on-settings-customise-settings-view-settings-into-one-settings-tab-view
• Ability to Pin/Unpin the Space Bar - Making it available as a menu icon
• Hamburger menu and Space Bar both allow navigation into TB so in fine could be merged into one (if you think about it) :-)
• API for add-on developers which they can use to add their add-on icon/button to the Space Bar - So it need to be consider as part of the layout/theme and mock-up... to show more icons and see how it would look like...
• Create consistency - open a new tab vs new window
• Find a good balanced between default showed icons (most used) and those less used by end-users but still allowing them to access - Email, Contacts, Calendar, Tasks, Chat, etc... but in the future possibly Notes, Feeds, etc...
• Allow collapse - manual and automatic (aka auto-hide) with a visual aide to easily show it back via click on a visible icon or mouse-over to the edge where panel is hidden...
• Allow customisation - hide non-used icon - re-arrange order etc... a bit like toolbar icon customisation in Firefox
• Allow relocation - left (by default? Probably make the most sense in a left-to-write reading mode), bottom, right, top
• Integrate "Search" Button/View? - This may be rediscussed in a separate topic/bug on how to improve search and bring consistency to it all over TB

I am conscious that all will not be dealt with in this bug (probably follow up ones) but still worth mentioning to see the big picture from the start...

Question for John.
I'm working on this implementation and I would like to guarantee an easy and usable location for all extensions to add custom buttons.
This is not gonna be an actual customizable toolbar, so I was wondering if you have some pointers on what should I do to guarantee the ability to access this area to all ad-ons developers, and maybe add some limitations (e.g.: you can't add a new button above the Mail tab button).

Hi Alessandro, thanks for those information.

WebExtAPI allow to add buttons in 5 locations:

• browser_action: main_toolbar and tabs_toolbar (next to the current calendar and tasks icons)
• message_display_action: message_header_toolbar
• compose_action: compose_toolbar and format_toolbar

For all these buttons the add-on defines a name, an icon and some other props and the API generates the core code to actually add the button.

We can change the API to use different code to add the button, but we need to keep the interface compatible (see https://webextension-api.thunderbird.net/en/latest/composeAction.html). We can also move the locations, if the UI changes.

Completely removing a location is probably a no-go, we have to come up with an alternative place, where those buttons can be added (the add-on must work as before without having to change something).

Will you drop the tabs_toolbar after the spaces_toolbar has landed? I think we can just move those buttons. But adding a dedicated space_action is also something we should consider. I would take care of implementing that.

What is problematic is "too many add-on buttons", which why I am planning to add an overflow container to the existing toolbars, but this probably should go hand-in-hand with a general overhaul of the customization UI. Are you planing to add an overflow container to the spaces_toolbar? At the moment users can customize the toolbar buttons including the add-on buttons. How is this going to be in the space toolbar? Is there a reason to not make it customizable like the others?

Besides raising questions on my own, did this answer your questions?

(In reply to John Bieling (:TbSync) from comment #11)

Will you drop the tabs_toolbar after the spaces_toolbar has landed?

Not at all for now. I'll only remove those buttons from there, but the final goal it to give users the ability to "restore" how things are now (before the spaces toolbar).
Maybe we will drop that location after the next ESR, but I want it to be a slow and gentle process, with plenty of time to adapt and find solutions.
Also, I'm okay with keeping that toolbar if it doesn't add any complexity or issue.

But adding a dedicated space_action is also something we should consider. I would take care of implementing that.

Yes, that would be awesome.
Another thing I'd like to add is making it color customizable. Is this something we can do by adding a variable to the add on manifest?

Are you planing to add an overflow container to the spaces_toolbar?

Yes.

Is there a reason to not make it customizable like the others?

The short answer is " we have too many customizable toolbars and it's getting messy".
Our customizable UI is completely different from the one used in Firefox, so we're supporting something completely foreign that it was intended to work with 1 main toolbar and nothing else. Adding another customizable toolbar is not optimal.

Also, toolbar customization is not keyboard accessible at all, so only "mouse-centric" users can benefit from that.
Since the Spaces toolbar is gonna be the primary/default hub to open the main tabs, I want that to be fully accessible and customizable via keyboard.
The customization of "Spaces" will be limited at first, with only the option to show/hide the toolbar, but later on I'd like to add menupopup options to change the order of buttons and hide unwanted buttons.

Besides raising questions on my own, did this answer your questions?

This is prefect, thank you so much!

Another thing I'd like to add is making it color customizable. Is this something we can do by adding a variable to the add on manifest?

I would use the themes API for that and add a new key to it, which can be used to style the space area like other parts of the UI, independent of a potential spaceActions API.

Is there a reason to not make it customizable like the others?

The short answer is " we have too many customizable toolbars and it's getting messy".
Our customizable UI is completely different from the one used in Firefox, so we're supporting something completely foreign that it was intended to work with 1 main toolbar and nothing else. Adding another customizable toolbar is not optimal.

Also, toolbar customization is not keyboard accessible at all, so only "mouse-centric" users can benefit from that.
Since the Spaces toolbar is gonna be the primary/default hub to open the main tabs, I want that to be fully accessible and customizable via keyboard.
The customization of "Spaces" will be limited at first, with only the option to show/hide the toolbar, but later on I'd like to add menupopup options to change the order of buttons and hide unwanted buttons.

Understood. In my head there is something wobbling that is like the new Firefox customization page, which is customizing the entire pane/window and not an individual toolbar. That would solve so many issues. (including the message header toolbar bug which you picked up recently). Just throwing that in here, since you seem to move towards a new/better kind of customization.

"Better" I don't know :D
We will see how users react to that, but I'm not firm on my approach or proposals, so if something better and easier to maintain is suggested, I'm totally okay with rethinking my plans.

Maybe after some of the initial patches land and the spaces toolbar is usable, we can discuss some ideas.

First of many patches ready for a review.
The feature is not complete but it's in a pretty usable state right now.

What's included in this patch:

• Spaces toolbar visible by default, removed Calendar and Tasks button but left that customizable toolbar at the top for extensions.
• The ST (Spaces Toolbar) can be collapsed, which will reveal an ST overflow toolbar button to switch between sections.
• The ST overflow button can be removed entirely, so users can completely ignore the ST and return to the old state of things if they want.
• The ST creates a spacesToolbar.json file in order to store its state. For now it's limited to the hide/show state, but in the future we can use it to store many more things (order of buttons, visibility of buttons, custom shortcut keys, extra buttons added via add-ons, etc.)

John, do you want to take a look at the patch and tell me if you see any potential red flag for a add-on developers?

Next steps

• If this approach is approved, I'll first implement tests to cover this new behavior.
• Improve the focus ring and keyboard navigation of those buttons.
• Implement context menu to change buttons order, show/hide buttons, and define custom keyboard shortcuts.
• Color customize the background and select color.
• Improve a11y.

I'm invested enough in this feature; +100 for adding a preferences/settings button and the account settings button to the Spaces bar.

To add to that, my requests/ideas are

(1) to add the "Go Offline" button to the Spaces bar as well. Go offline is the most undervalued, feature in Thunderbird IMO and more people ought to be aware of it.
(2) to add a switch for dark-mode / light-mode; I know, people can set it to follow system theme, but that does not work for everybody.
(3) to add the Add-ons button to it. This opens the add-on / extensions tab
(4) Filter-presets / search-presets of emails by "starred" or "labels" or whatever-else.

Placing dark-mode switch and offline switch in the Spaces bar will ease my - and others - workflows a lot. Of course these should be default with configuration options to remove them if users don't see value in having them there for their workflows.

(In reply to YG from comment #16)

(1) to add the "Go Offline" button to the Spaces bar as well. Go offline is the most undervalued, feature in Thunderbird IMO and more people ought to be aware of it.
(2) to add a switch for dark-mode / light-mode; I know, people can set it to follow system theme, but that does not work for everybody.
(4) Filter-presets / search-presets of emails by "starred" or "labels" or whatever-else.

Are those really Spaces? Therefore would the Spaces bar be the best location for those?
What about instead adding a toggle button (to switch light/dark) next to the already existing "Go Offline" button in status bar?
The "Go offline" is pretty easy to find and use where it is...

As for the Add-ons button perhaps but already pretty easily accessible from TB Menu.

I would rather see in Space bar one Settings button that lead to a Settings tab to access all the areas related to parameters, a bit similar to (Preferences panel on Mac computer) as per proposal and mockup available here https://thunderbird.topicbox.com/groups/ux/Tf01ae86e0bf67311-Mc8d2c6505ca5093a47f3536d/merging-all-tb-options-account-settings-add-on-settings-customise-settings-view-settings-into-one-settings-tab-view
One can imagine that a right click on such Settings button could also open a context menu for quick access the most fequently used ones e.g Preferences, Account Settings, add-ons, etc...

The Spaces bar could be devided in three areas one for buid in TB features TB Menu, Email, Calendar, Contact, Chat, etc..., one for Add-on spaces (to access their UI), one for the Settingd button... if place as a left column it would be in that order top, middle, bottom...

Just my 2 cents input...

I'm invested enough in this feature; +100 for adding a preferences/settings button and the account settings button to the Spaces bar.

I'm glad you like this new feature.
The settings button is already in the patch, right at the bottom.
I'm not sure about adding account settings, but we will explore that later.

(1) to add the "Go Offline" button to the Spaces bar as well. Go offline is the most undervalued, feature in Thunderbird IMO and more people ought to be aware of it.

We have other plans to better expose that feature as this toolbar should be reserved for "Spaces", AKA buttons that open tabs.

(2) to add a switch for dark-mode / light-mode; I know, people can set it to follow system theme, but that does not work for everybody.

We can consider exposing the dark/light toggle switch in another bug, but that opens up a can of worms which can be hard to manage. Remember that Thunderbird, as for Firefox, is not dark/light themed only but it comes with various themes not strictly related to light/dark variation.
Let's discuss that in another bug.

(3) to add the Add-ons button to it. This opens the add-on / extensions tab

Maybe not by default, but potentially we will give the option to show it.
This toolbar is mostly focused on giving quick access to sections users tend to interact often with. I'm not sure the add-ons tab requires constant access for day to day use.

(4) Filter-presets / search-presets of emails by "starred" or "labels" or whatever-else.

That's unrelated to this toolbar, also potential discussion for another bug.

(In reply to Richard Leger from comment #17)

I would rather see in Space bar one Settings button that lead to a Settings tab to access all the areas related to parameters

Yup, this is already in the uploaded patch.

The Spaces bar could be devided in three areas one for buid in TB features TB Menu, Email, Calendar, Contact, Chat, etc..., one for Add-on spaces (to access their UI), one for the Settingd button... if place as a left column it would be in that order top, middle, bottom...

Yes, it's already like this :D

(In reply to Alessandro Castellani [:aleca] from comment #18)

The settings button is already in the patch, right at the bottom.

Right where it should be!

We can consider exposing the dark/light toggle switch in another bug, but that opens up a can of worms which can be hard to manage. Remember that Thunderbird, as for Firefox, is not dark/light themed only but it comes with various themes not strictly related to light/dark variation.

Yep. Let's not clutter the Spaces bar with tons of icons related to settings that can be easily found and/or placed elsewhere (e.g top toolbar, main menu).

(3) to add the Add-ons button to it. This opens the add-on / extensions tab

Maybe not by default, but potentially we will give the option to show it.
This toolbar is mostly focused on giving quick access to sections users tend to interact often with. I'm not sure the add-ons tab requires constant access for day to day use.

I think it does make sense to have a section for "addon spaces" because some of them have internal pages that can be used often. So yes, it's definitely worth to open a feature request for that.

I have a suggestion from playing around with the spaces bar:

Could the top of the spaces bar be a "header" just like with the agenda sidebar on the right side? For me, this would produce a better picture, as the toolbar would continue to extend to the very left. If the spaces bar is shown, the header could include the "hide" toggle icon. If the spaces bar is not shown, the header could include the "show" toggle icon as with the current implementation.

Comment on attachment 9246998 [details]
WIP: Bug 1665511 - Implement a Spaces toolbar to collect all tab opening buttons.

To reduce complications with WebExensions, I think the most simple approach is to implement something like addSpaceButton and removeSpaceButton functions, which your own implementation is using as well. So when the WebExt API later use the same functions to add additional buttons, we do not run into additional issues.

Do you plan to support context menus on those space buttons?

(In reply to John Bieling (:TbSync) from comment #20)

I have a suggestion from playing around with the spaces bar:

Could the top of the spaces bar be a "header" just like with the agenda sidebar on the right side? For me, this would produce a better picture, as the toolbar would continue to extend to the very left. If the spaces bar is shown, the header could include the "hide" toggle icon. If the spaces bar is not shown, the header could include the "show" toggle icon as with the current implementation.

Thanks for the suggestion, but we're moving in a slightly different direction.

The Spaces Toolbar will span for the full height of the window, so will include also the tabbar and the status bar.
When collapsed, we will not show that "overflow" button, as forcibly showing/hiding elements unprompted. Users can re-enable the toolbar through the menubar or app menu, and a "Spaces" toolbarbutton will be available for users that want to customize their toolbar and have a single button to jump to different tabs.

(In reply to Alessandro Castellani [:aleca] from comment #22)

When collapsed, we will not show that "overflow" button, as forcibly showing/hiding elements unprompted.

I didn't get the meaning of this, I think there are missing words?

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/58db526a877f
Implement a Spaces toolbar to collect all tab opening buttons.r=mkmelin,Paenglab

The first part of this feature just landed on trunk.
The next steps to bring this feature to a useful and interesting state are:

• Make the UIDensity affect this new toolbar. DONE
• Add tests to cover all aspects of the toolbar. DONE
• Show a pinned button in the titlebar to give quick access to the main spaces. DONE
• Make the chat button reactive to chat notifications. DONE
• Add an entry point to allow extensions to add buttons. DONE
• Add customization options to change background and accent color. DONE
• Add default shortcuts for the primary buttons and to quick toggle the visibility of the toolbar.
• Add a context menu to the buttons to open the tab in a new window. And, when/if we properly support multiple tabs of the same type in the same window, an option to open a new distinct tab in the same window. DONE
• Add full keyboard a11y and controlled focus ring. IN PROGRESS

Anything else you'd like to add to this list, or any concerns about what I planned?

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/883784b14b05
Fix busted tests due to the changed toolbar buttons.r=darktrojan

The proposals sounds good. I could help with the UIDensity.

What also should be done is a highlighting of the tabbar-toolbar when in customize mode to show the user he can place something there. Before we had the calendar buttons but now it's not obvious that this is a drop place.

(In reply to Alessandro Castellani [:aleca] from comment #26)

The first part of this feature just landed on trunk.
The next steps to bring this feature to a useful and interesting state are:

• Make the UIDensity affect this new toolbar.
• Add tests to cover all aspects of the toolbar.
• Make the chat button reactive to chat notifications.
• Add an entry point to allow extensions to add buttons.
• Add customization options to change background and accent color.
• Add default but customizable shortcuts for the primary buttons and to quick toggle the visibility of the toolbar.

Anything else you'd like to add to this list, or any concerns about what I planned?

I would prioritize

• Add tests to cover all aspects of the toolbar.
• Make the UIDensity affect this new toolbar.
• Add an entry point to allow extensions to add buttons.

Given that there are many other priorities, I'm not sure the other items need any prioritization.

(In reply to Alessandro Castellani [:aleca] from comment #26)

Anything else you'd like to add to this list, or any concerns about what I planned?

I like the way it looks. I especially like that you cleaned out the tab buttons from the toolbar!

Some things to add/change would be:

• Instead of <aside> use <div role="toolbar" aria-orientation="vertical"> and manage focus with up/down arrow keys. I'm not sure about (Shift+)Tab: either it could duplicate the arrow key navigation, or it could take you directly in/out of the toolbar. The advantage of the second approach is that we can remember the last focussed button on leaving the toolbar, and on returning to it we focus that same button, which would save the user navigating past the "collapse" and "settings" buttons every time.
• Add a context menu to the buttons to open the tab in a new window. And, when/if we properly support multiple tabs of the same type in the same window, an option to open a new distinct tab in the same window.
• Make the focus styling on the current buttons more obvious. It currently just makes the button look slightly bigger because they share the same color. Having a transparent gap between the button's border edge and the focus outline might help.
• Change the background color and maybe make the inline-end border thicker. On the light and system themes, it's another grey that's slightly different from the grey used for the settings navigation: rgb(232, 232, 232) vs rgb(235, 235, 239). And the thin border makes them sort of blend together. There's the same problem with the address book tab. And, in a less noticeable way, with the background color of the selected calendar in the calendar/task tab, and the selected folder in the mail tab.
• It looks strange next to the settings navigation. They have an uncanny similarity because of their vertical layout and their overlapping icon sets, but in different orders and the icons are much bigger in the settings. This is more prominent if you shrink the window horizontally until the settings navigation only uses icons. Similar with addon settings.
• I think the spaces toolbar should be between #toolbar-menubar and #tabs-toolbar in the document structure and in the tab sequencing. It is currently after the tabs, but the visual reading order is before the tabs.

I'm a little bit concerned about always having both the "spaces" toolbar and "tabs" bar, since the tab functionality is split between them. One opens tabs, the other is needed to close tabs, but both can be used to switch tabs.

This is similar to the GNOME file browser, which uses both places (Recent, Home, Documents, etc) and tabs. The difference is that in the GNOME file browser, clicking a place will replace the current tab with the new place. You need to use the context menu to open in a new tab, and it only shows you the tabs bar if you have more than one tab.

I wonder if that could make more sense in the future once we make tabs more stand alone: clicking a space replaces the shown page in the current tab with the selected space, and the context menu allows you to open the space in a new tab.

I think this "replace" behaviour would be really useful because the annoying thing about tabs is having to clean up after yourself. And a lot of regular use of thunderbird could be done in a single tab (so you would never need to see the tab bar).

I'm a little bit concerned about always having both the "spaces" toolbar and "tabs" bar, since the tab functionality is split between them. One opens tabs, the other is needed to close tabs, but both can be used to switch tabs.

Personally, I'd like a way to hide the tabbar completely since it's a bit redundant now that we have the spaces toolbar. In the scenario where there's multiple tabs of the same space, there could be a small dot indicators on the right side of the icon à la Gnome or macOS dock.

(In reply to Magnus Melin [:mkmelin] from comment #31)

I would prioritize

• Add tests to cover all aspects of the toolbar.
• Make the UIDensity affect this new toolbar.
• Add an entry point to allow extensions to add buttons.

Sounds like a good a plan!

Instead of <aside> use <div role="toolbar" aria-orientation="vertical"> and manage focus with up/down arrow keys.

Yup, that's planned.

Add a context menu to the buttons to open the tab in a new window. And, when/if we properly support multiple tabs of the same type in the same window, an option to open a new distinct tab in the same window.

Great suggestion!

Make the focus styling on the current buttons more obvious.

Yes, the focus styling and navigation will follow mostly what Firefox does in their main toolbar, with Tab to focus on a major area and then arrow keys to loop through the buttons of that area, and the focus ring will be a 2px outline.

Change the background color and maybe make the inline-end border thicker...

The background color will be customizable. Once I implement that the inline border will be a darker box shadow with opacity, or a pseudo element with opacity on top of the toolbar, so it changes the tint based on the selected background color.

It looks strange next to the settings navigation...

It doesn't loop too strange to me as I can clearly distinguish their purpose and sections, but you bring up good points so we can explore some better visual separation and organization.

I think the spaces toolbar should be between #toolbar-menubar and #tabs-toolbar in the document structure and in the tab sequencing. It is currently after the tabs, but the visual reading order is before the tabs.

Welcome to my struggle.
Unfortunately, I was forced to put the spaces toolbar in the "body" after the #navigation-toolbox due to how the structure and styling are done to build our "header" area and render the window decorations in every OS.
Having the spaces toolbar physically in the navigation toolbox made it impossible to span the full height of the application since the header box and the tabmail box are separate entities.
You're more than welcome to give it a try if you can find a solution.

I'm a little bit concerned about always having both the "spaces" toolbar and "tabs" bar, since the tab functionality is split between them. One opens tabs, the other is needed to close tabs, but both can be used to switch tabs.

This is a transition state.
If you recall from my design system presentation, the long term goals is to less and less rely on tabs for our primary sections (mail, calendar, chat, etc). So yeah, it's weird right now, but it will improve and change with time and mostly follow what you suggested.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/5f9f939d0a76
Implement UI Density variations to the Spaces Toolbar.r=Paenglab
https://hg.mozilla.org/comm-central/rev/a6fcd3ce559e
Hide spaces toolbar in calendar test to not interefere with the drag and drop. r=darktrojan

On Windows, clicking on the top "mail" icon after having clicked on calendar or something else, it does not bring me back to the mail tab. A double click on the "mail" icon however resizes my TB from full-screen to window and brings me back to the mail tab. A double click on all other icons in the spaces bar does not do anything alike.

No errors in the console. How could I assist?

(In reply to John Bieling (:TbSync) from comment #40)

On Windows, clicking on the top "mail" icon after having clicked on calendar or something else, it does not bring me back to the mail tab. A double click on the "mail" icon however resizes my TB from full-screen to window and brings me back to the mail tab. A double click on all other icons in the spaces bar does not do anything alike.

No errors in the console. How could I assist?

Do you have the tabs in the title bar (Customize -> "Title Bar" is checked) and/or the menu bar hidden?

I can't reproduce on linux. But since double clicking the title bar maximises the window, my guess is that this is because the spaces toolbar element overlaps the #titlebar (it has a negative block-start margin), and the title bar is grabbing the click event instead of the "mail" button. The spaces toolbar should have a higher z-index so the click should only be going to the spaces toolbar, but maybe there's something weird going on with the #titlebar on windows.

You could test this by putting debugging "click", "mousedown" and "mouseup" handlers on the #titlebar and spacesToolbar and see which ones get fired. And test with tabs not in the title bar, and with the menu bar shown.

It might be a z-index problem.
Can you simply increase the spaces toolbar z-index to something silly like 9999 in the dev tools, and see if that fixes it?
I'll test it on my crappy windows laptop in a minute.

Found the issue, it's only affecting Windows for some reason.
I'll have a patch ready for review in a few minutes, thanks for the report.

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/25451e3b3295
Fix titlebar alignment with spaces toolbar. r=Paenglab
https://hg.mozilla.org/comm-central/rev/e3b0910aa649
Highlight the customizable toolbars when customizing. r=aleca

Hi, a question: Is it possible to use another English name? I'm afraid the name "spaces toolbar" is very difficult to translate. The toolbar contains the partial programs of Thunderbird.

@Alessandro: Did not have an earlier timeslot for testing. Your fix works for me. Great!

(In reply to Michael Wolf from comment #46)

Hi, a question: Is it possible to use another English name? I'm afraid the name "spaces toolbar" is very difficult to translate. The toolbar contains the partial programs of Thunderbird.

What would you suggest?
We called it "Spaces toolbar" because the purpose of this toolbar is to collect all buttons that open a dedicated Tab, so a new "space". This toolbar won't have any button opening a popup, or a dialog, or affecting the layout of the currently visible tab.

(In reply to John Bieling (:TbSync) from comment #47)

@Alessandro: Did not have an earlier timeslot for testing. Your fix works for me. Great!

No problem,I'm glad it works.
I will later next week add some entry points for extension developers and I'll ping you for a review.

(In reply to Alessandro Castellani [:aleca] from comment #48)

What would you suggest?
We called it "Spaces toolbar" because the purpose of this toolbar is to collect all buttons that open a dedicated Tab, so a new "space". This toolbar won't have any button opening a popup, or a dialog, or affecting the layout of the currently visible tab.

Hi Alessandro, there are buttons to the TB partial programs for now. I don't really know what you mean with "space". A space is a generic term. Maybe there will be still other buttons in this toolbar. According to the buttons the toolbar have now I wuld suggest "component toolbar".

IMPLEMENTATION OVERVIEW

Overview of how the Spaces Toolbar was implemented, its features, and expected behavior.
First landed in v98.

OBJECTIVE

The Spaces Toolbar is a vertical area to collect and organize all those buttons opening a dedicated Tab. The name "Space" is to reference a standalone view or dedicated Tab.

This toolbar will not be a standard customizable toolbar, and shouldn't be used to add buttons that don't open a Tab, nor it should be a drop target for any <toolbarbutton>.

Buttons that open dialogs, popups, reveal or collapse UI panels, etc., should be implemented as <toolbarbutton> inside the standard customizable toolbar.

HTML

The Spaces Toolbar is a simple <div role ="toolbar"> element that vertically collects all buttons opening a tab. The toolbar only exists in the messenger.xhtml file since it's not needed in any standalone window nor dialog.

The Spaces Toolbar visually wraps around the entire Application Window. In order to achieve that, some extra wrapper tags were implemented.

This is the current structure of the main messenger.xhtml file:

• The <box id="navigation-toolbox-background"> which includes the titlebar, menubar, and tabs bar.
• The <hbox id="messengerContainer"> which wraps the Spaces Toolbar and the entire content of the tabmail tabs as a flex element in order to properly align them.
• The Spaces Toolbar alongside the <vbox id="messengerBody"> which actually encapsulates the rest of the UI (tabmail with all tabs, statusbar, and notification area).

Keeping this current structure is vital in order to guarantee correct alignment of the Spaces Toolbar no matter its visibility state, or the state of tabs in titlebar and menubar.

JAVSCRIPT

In progress...

INTEGRATION WITH THE TITLEBAR

In progress...

EXTENSIONS API

In progress...

CUSTOMIZATION

In progress...

(In reply to Michael Wolf from comment #49)

I don't really know what you mean with "space". A space is a generic term. Maybe there will be still other buttons in this toolbar.

"Space" does have a lot of different meanings. But in this case, you can think of a "space" as one of the main "sections" or "areas" of the application. Clicking one of these buttons should move the user to a completely different section of the application (currently, this just means switching to a different tab). I would say that "component" isn't quite right since it implies something more specialised and smaller.

In general, you can think of "space" as in the sentence "this space is used for chatting".

Does that make sense? What language are you thinking of?

Hi Henry,

thank you for your reply. "Space" does not mean section or area in German and Sorbian languages. German uses "Raum" (room), Sorbian languages "rum". Similar terms are German "Bereich" (area), Sorbian "wobłuk/wobceŕk" and German "Abschnitt" (section), Sorbian "wotrězk/wótrězk". "Space" is something where nothing is or what is empty, "space bar" (key without text on keyboard), "whitespace" (empty area) and the like.

Well, I have a perspicuous idea about "space" now.

Depends on D135946

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/379cb86de4fb
Implement tests for the Spaces Toolbar.r=darktrojan
https://hg.mozilla.org/comm-central/rev/41ed4d4648b6
Initialize spaces toolbar also when the application is used without any account. r=darktrojan

Some potential pointers for the context menu items for each buttons:

Mail button

• Open in a new Tab
• Open in a new Window
• separator
• Close all tabs (Or another wording for closing all tabs except the primary mail tab)

Settings button

• Open Settings
• Open Account Settings
• Open Add-ons and Themes

I updated the work in progress patch with more context menu options.

Currently, all buttons share the same context menu with the items

• "Replace current tab" - Shown when the current tab can be closed (i.e. not the main mail tab). E.g. if you open the calendar tab, then you can select this to replace it with the task tab.
• "Open in new tab" - Shown when there is no existing tab for a space, or if a space can have multiple tabs (currently only the mail space).
• "Open in new window" - Shown when a space can have multiple tabs (currently only the mail space).
• "Switch to [tab title]" - Shown when there is an existing tab. There can be multiple items if more than one tab is in this space (current only the mail space).

The way "Replace current tab" works is a little bit clunky: open a new tab, close the current tab and move the new tab to its index. But it is actually quite fun to use! A step in the direction of "No tabs if possible".

Anyone who is interested, feel free to apply the patch locally and play around with it. Just note that opening a new mail tab is currently buggy because I haven't found a way to properly choose an initial folder for the new tab.

The clicking behaviour of the buttons is essentially:

• If we're already in the given space, do nothing.
• Else if there is an existing tab for the space, switch to the first one.
• Else open a new tab for this space.

I wonder if we could change this to prefer replacing the current tab, if possible.

(In reply to Alessandro Castellani [:aleca] from comment #56)

Some potential pointers for the context menu items for each buttons:

Thanks for the suggestions. I'll be adding separators later.

Mail button

• Close all tabs (Or another wording for closing all tabs except the primary mail tab)

I'm not sure about this because there can be multiple tabs belonging to the mail space. So would this also close the other tabs in the space? It might be better to use the existing "Close Other Tabs" in the first tab's context menu because this seems tab-specific rather than a space-specific.

Settings button

• Open Settings
• Open Account Settings
• Open Add-ons and Themes

I quite like the idea of making these other settings accessible. This implies that "Account Settings" and "Add-ons and Themes" tabs would be part of the same "Settings" space. I'm open to this, but I'm unsure of what to do in the following situation. You have two tabs open:

1. the default mail tab, which is the current tab, and
2. an add-ons tab.

If you press the button for the Settings space, should thunderbird:

1. switch to the add-ons tab, or
2. open a new "Settings" tab?

I can't decide because whilst the add-ons tab is considered part of the "Settings" space, it is not the main tab for this space.

It might be cleaner to just add separate buttons for add-ons and account settings.

There are a lot of "Tab" mentioned. Shouldn't this be changed to "Space" because this is the Spaces toolbar? So "Replace Current Space", "Open in New Space" etc.

(In reply to Henry Wilkes [:henry] from comment #57)

The way "Replace current tab" works is a little bit clunky: open a new tab, close the current tab and move the new tab to its index. But it is actually quite fun to use! A step in the direction of "No tabs if possible".

That's is an interesting concept but I'm not sure we should pursue it right now.
It feels not very intuitive when trying to use it and it's a bit out of context right now as it would probably better live in the context menu of the tab handler itself.
I'd recommend to not adding this for now and postpone for a dedicated patch. We might need to write down some specs for it and define all scenarios.
Great idea, nonetheless.

The clicking behaviour of the buttons is essentially:

• If we're already in the given space, do nothing.
• Else if there is an existing tab for the space, switch to the first one.
• Else open a new tab for this space.

This sounds great!

I wonder if we could change this to prefer replacing the current tab, if possible.

Better not to as we shouldn't arbitrarily close or replace the current tab of the user. We never know what kind of workflow they're trying to achieve so we shouldn't make this decision for them.

If you press the button for the Settings space, should thunderbird:

Always open the "Settings" tab. That's the primary tab linked to that button and the left click should always result in the same outcome. Having extra tabs int he context menu (account settings and add-ons) is to offer quick access within the same context, but not replace the primary behavior of that button.

It might be cleaner to just add separate buttons for add-ons and account settings.

Better not for now. We don't want to fill up the spaces toolbar with too many buttons. We can later add some telemetry and collect data about clicking behavior. If we notice that the amount of clicks to access those settings tabs is equal or pretty similar, we can explore the idea of showing all those buttons. Maybe even offering the user the ability to show or hide those buttons through customization.

(In reply to Richard Marti (:Paenglab) from comment #58)

There are a lot of "Tab" mentioned. Shouldn't this be changed to "Space" because this is the Spaces toolbar? So "Replace Current Space", "Open in New Space" etc.

Not for now. The "Spaces" name is only used as a reference to this toolbar and it's kinda new. Users are familiar with "tabs" and we currently still handle those "spaces" like regular "tabs". Better to defer the change of established names after this new toolbar can do everything that it's supposed to do and the user had some time to get used to it.

(In reply to Henry Wilkes [:henry] from comment #57)

• "Replace current tab" - Shown when the current tab can be closed (i.e. not the main mail tab). E.g. if you open the calendar tab, then you can select this to replace it with the task tab.

I should clarify the example for replacing a tab:

1. Open Thunderbird with just the main mail tab.
2. Click the "Calendar" button in the spaces toolbar.
3. Then, whilst still in the "Calendar" tab, right click the "Task" button in the spaces toolbar and select "Replace current tab".

This will close the "Calendar" tab and open the "Task" tab in its place. Basically, it cleans up the current tab for you, so you don't spawn loads of tabs as you move between spaces.

(In reply to Alessandro Castellani [:aleca] from comment #59)

I'd recommend to not adding this for now and postpone for a dedicated patch. We might need to write down some specs for it and define all scenarios.

I agree to not add it now. I put it in there to experiment with a different flow between spaces.

Always open the "Settings" tab. That's the primary tab linked to that button and the left click should always result in the same outcome. Having extra tabs int he context menu (account settings and add-ons) is to offer quick access within the same context, but not replace the primary behavior of that button.

ok thanks!

(In reply to Richard Marti (:Paenglab) from comment #58)

There are a lot of "Tab" mentioned. Shouldn't this be changed to "Space" because this is the Spaces toolbar? So "Replace Current Space", "Open in New Space" etc.

The relation from Space to a Tab is one-to-many, rather than one-to-one. I.e. each Tab can "belong" to up to one Space, and each Space can have between 0 and infinity open Tabs.

@aleca it is too early to know exactly what the spaces toolbar will become, but it might help to expand on the conceptual relation between a Space and a Tab in the documentation.

Based on the existing comments in this bug, I can think of two distinct concepts, which would take us in a different direction.

1. Tabs are containers for Spaces

The key concepts would be:

• The application has one or more Windows, each of which has one or more Tabs.
• We only display the Tab header if there is more than one Tab.
• Each Tab can show up to one Space.
• Clicking a Space on the toolbar switches the Tab to show that Space.
• You can also open a Space in a new Tab or a new Window.

This would be analogous to the Gnome file browser (sorry, I'm unsure for other platforms), where a Tab shows the content of a Folder (in analogue to showing a Space), and there are key locations (like "Documents", "Pcitures", etc) in the side bar (in analogue to the Spaces toolbar).

I think the advantage of this would be that you don't spawn tabs for every space switch, but you still have the flexibility of having more tabs if you need to do distinct things in each. The disadvantage would be each Tab would probably need some memory for each Space so we could support: switch to "calendar"; change the date; switch to "mail" to verify something; switch back to "calendar" and expect to see the same date. Although, this wouldn't be that different from how we do things now where we "fake" opening certain tabs that are actually already loaded in the DOM: basically each Tab would have its own #tabpanelcontainer that contains the current #mailContent, #chatTabPanel, #calendarTabPanel, etc.

2. Spaces own Tabs (one Tab header per Window)

The key concepts would be:

• The application has one or more Windows, each of which has one or more Tabs.
• We can show or hide the Tabs header.
• Each Space owns zero or more Tabs.
• Clicking a Space either opens the Space's existing Tab or spawns a new Tab .

This would be analogous to the Gnome application "Dash" / macOS application dock, where clicking an application icon (in analogue to a Space) either takes you to its existing Window (in analogue to switching Tab) or opens a new Window (in analogue to spawning a new Tab).

The advantage is that it is quite similar to how we do things now. The disadvantage is I think a user would often still need to use the Tab header, in analogue to needing the actual Window layout instead of the application dock. E.g., if you open more than one mail tab to do distinct things and quickly switch between them, you can in principle do this with the Spaces context menu, but clicking on the tab header can be easier.

In addition, unlike the application dock analogue, not every Tab belongs to a Space. For example, "about:rights" or a PDF attachment opened in Thunderbird. You would either need to see the Tab header or have some way to access these unowned Tabs from the Spaces toolbar.

Moreover, if you hide the Tab header, and switch between Spaces through normal use, this will spawn Tabs in the background. Currently, a lot of tabs are also restored on re-opening Thunderbird. So if you ever switch to showing the Tab header again, there will be a list of all the accumulated Tabs.

Maybe someone can think of a clever way to address this.

EDIT

Another approach was given to me by @aleca and this seems to have the best of both!

3. Spaces own Tabs (one Tab header per Space)

The key concepts would be:

• The application has one or more Windows, each of which has a full set of Spaces.
• Each Space has its own Tab header, with one or more Tabs.
• We only display the Tab header for a Space that has more than one Tab.
• Clicking a Space button switches to that Space.

This is really neat because it allows each space to handle its own set of tabs, so the Tab header won't mix tabs from different spaces. If you want to switch from a Mail tab to a Calendar tab, you only need to use one of the Calendar button in the spaces toolbar. This approach means you'll hardly need to see the tab header, whilst still being able to have multiple tabs if needed.

This is also quite similar to what we do now: you could almost implement this now by just hiding all the tabs that are not in the current Space. You would still have to make sure that each Tab belongs to a Space.

(In reply to Michael Wolf from comment #52)

thank you for your reply. "Space" does not mean section or area in German and Sorbian languages. German uses "Raum" (room), Sorbian languages "rum". Similar terms are German "Bereich" (area), Sorbian "wobłuk/wobceŕk" and German "Abschnitt" (section), Sorbian "wotrězk/wótrězk". "Space" is something where nothing is or what is empty, "space bar" (key without text on keyboard), "whitespace" (empty area) and the like.

Well, I have a perspicuous idea about "space" now.

I agree. In Japanese also "Space (スペース)" means "empty place", "available space" or "an interval of items".

I think "Section Toolbar" is preferable.

(In reply to Masahiko Imanaka [:marsf] from comment #62)

I agree. In Japanese also "Space (スペース)" means "empty place", "available space" or "an interval of items".

Maybe try thinking of how you would translate "this space is used for chatting" or "workspace" (e.g. as used for desktops https://en.wikipedia.org/wiki/Workspace#Graphical_interfaces ) or "this corner of the bedroom is my writing space". This might help with finding a good translation.

The way I think of it, we're using "Space" to imply "an enclosed location where related activities can be performed". We can also combine "Space" with another word to imply the activity. So the "Mail Space" is where you read emails, the "Calendar Space" is where you organise calendar events, etc. Out of all the related words, I think "Space" works the best.

I don't think "Space" as used here has a clean one-to-one translation into other languages. I know at least in german, related words -- like "Raum" and "Platz" -- similarly have multiple different meanings. But the translation teams can choose whatever would work best. Hopefully the explanation can help with making the choice.

I think "Section Toolbar" is preferable.

This could work, but words like "Section" (and "Area") are quite generic in english: anything with a heading or is self-contained will be a section. E.g. "the Compose section in Settings". Therefore, most "Spaces" in Thunderbird will already have their own sections. However, in practice you can probably say "Calendar section" and people will know what you mean, but we also use "Calendar Tab" if we want to be clear, but as discussed above a "Tab" is not the same as a "Space".

On the topic of language. I wonder if we should change the button tooltip text from

Switch to the mail tab

to

Switch to the mail space

Both line up with the current behaviour. The first might be closer to well known concepts in Thunderbird, but I like the second because:

• It means we have more references to the word "space" within the "Spaces Toolbar" itself, which would help users understand its name and use.
• "the mail tab" is less clear when there are no existing tabs, or there is more than one tab for the space.
• The second one's wording would continue to work when or if clicking a button doesn't open a new tab or move to an existing tab, but just changes the space.

(In reply to Henry Wilkes [:henry] from comment #63)

I don't think "Space" as used here has a clean one-to-one translation into other languages. I know at least in german, related words -- like "Raum" and "Platz" -- similarly have multiple different meanings. But the translation teams can choose whatever would work best. Hopefully the explanation can help with making the choice.

I can say at least, you shouldn't make another translation for fundamental UI, so users may be confused and it forces support team to do unnecessary work.

(In reply to Henry Wilkes [:henry] from comment #64)

On the topic of language. I wonder if we should change the button tooltip text from to
Switch to the mail space

In general, I agree with this proposed change. I'm not sure if it's a bit too early tho.
Right now the Spaces toolbar is very barebone and the overall concept of "space" is not implemented at all, so I don't know if users might get confused.

I would probably defer this to after we better explore and implement the overall concept of space, with a space owning all the tabs of its context.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/ac5206cd4a48
Show a clickable icon in the status bar to reveal the Spaces toolbar. r=mkmelin

(In reply to Henry Wilkes [:henry] from comment #32)

• use <div role="toolbar" aria-orientation="vertical"> and manage focus with up/down arrow keys.

Regarding this, I think there are a few places where we have toolbars, and managing focus with arrow keys would be useful. Especially as we replace the xul toolbars. E.g. the message header "Reply, Forward, ..." toolbar. What do you think about a new custom element for this?

Also, maybe allow a means to focus the toolbar itself (rather than one of its children) as a means to access the toolbar's context menu, ect?

(In reply to Henry Wilkes [:henry] from comment #70)

What do you think about a new custom element for this?

I'm not sure, maybe, but it's hard to guess without some exploration. We can definitely discuss this.
The behavior should match the focus in the Firefox toolbar, which moves around when you press Tab, but only focuses on the first element in that specific section.
So, if you have 30 add-on buttons, it only focuses on the first and you can move around with arrows, but if you press Tab again, it goes to another section, which is very handy.

Also, maybe allow a means to focus the toolbar itself (rather than one of its children) as a means to access the toolbar's context menu, ect?

Sure. We would need a way to control this because we might have toolbars that don't have a context menu, so we should be able to skip that focus step.

(In reply to Alessandro Castellani [:aleca] from comment #71)

So, if you have 30 add-on buttons, it only focuses on the first and you can move around with arrows, but if you press Tab again, it goes to another section, which is very handy.

Could we have the same concept for the main spaces? 5 Tab stops is quite a lot.

• single Tab stop on "Switch to the mail tab"
• Address Book, calendar, etc. tab buttons can be navigated to with cursor down/up
• If there's a clear separation to the 30 addon/custom buttons on the spaces toolbar, maybe they could have their own single tab stop (followed by arrow navigation for the other 29).
• Or maybe the entire Spaces Toolbar could just have a single tab stop and the rest needs arrow navigation.

That's what I was thinking about.
For the spaces toolbar, I think we could have 3 stops:

• Primary spaces (our default buttons)
• Addons spaces (whatever button is added by extensions)
• Options buttons (Preferences and collapse).

We can see it in a simpler way, dividing the spaces toolbar in 3 blocks, top, center, and bottom.

(In reply to Alessandro Castellani [:aleca] from comment #71)

(In reply to Henry Wilkes [:henry] from comment #70)

What do you think about a new custom element for this?

I'm not sure, maybe, but it's hard to guess without some exploration. We can definitely discuss this.
The behavior should match the focus in the Firefox toolbar, which moves around when you press Tab, but only focuses on the first element in that specific section.
So, if you have 30 add-on buttons, it only focuses on the first and you can move around with arrows, but if you press Tab again, it goes to another section, which is very handy.

Yes, this is what I want: have a custom element with one-directional keyboard navigation that manages focus of its children. Following https://www.w3.org/TR/wai-aria-practices/#toolbar

I think we should avoid having more than one tab stop within a toolbar, since this breaks the convention. Tabbing to the spaces toolbar will likely be for users that don't (yet) know of the corresponding shortcut for the space they are trying to reach, so I think it should be simple. E.g. I'm not sure it would be clear, without a visual representation, why pressing both Tab and Down from the Chat button takes you to Settings, but pressing Tab from Settings takes you out of the toolbar. You could maybe use sub-groupings with different aria-labels to convey this, but I'm not sure how well screen readers would handle this. Alternatively, you could make them separate toolbars, with independent arrow navigation.

Plus, I don't see much benefit for users. If you want to open the calendar tab starting from an open mail tab, with a single tab stop this would be:

1. Shift+Tab from first focusable element in the mail tab takes you to the Spaces toolbar.
2. Down, Down to calendar button.
3. Enter to open calendar tab.
4. Tab to move focus into the calendar tab.

With an extra tab stop on the Options grouping, this would be:

1. Shift+Tab from first focusable element in the mail tab takes you to the Options grouping.
2. Shift+Tab takes you to the default buttons.
3. Down, Down to calendar button. Or press Up, Up to get here from step 1.
4. Enter to open calendar tab.
5. Tab to move focus into the Options grouping.
6. Tab to move focus into the calendar tab.

Even to get to the settings tab, I don't think a single tab stop is much of an issue:

1. Shift+Tab from first focusable element in the mail tab takes you to the Spaces toolbar.
2. Down, Down, Down etc to settings button. Or Up, Up. Or End, Up.
3. Enter to open settings tab.
4. Tab to move focus into the settings tab.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/17ed17aa68d9
Add context menus for the spaces toolbar buttons. r=aleca

While working with the spaces bar and using its settings button quite often now to get around the "address book tab has no toolbar and therefore no hamburger menu to access the settings" issue - I wanted to ask if we could add/move the hamburger menu to the top of the spaces bar, as it would then always be accessible?

(In reply to John Bieling (:TbSync) from comment #78)

While working with the spaces bar and using its settings button quite often now to get around the "address book tab has no toolbar and therefore no hamburger menu to access the settings" issue - I wanted to ask if we could add/move the hamburger menu to the top of the spaces bar, as it would then always be accessible?

Do you mean having the hamburger menu to the top left of the screen and inside the spaces toolbar?
If that's what you're suggesting I'd say no :D

The main app menu makes sense to be at the "end" of the screen (right for LTR or left for RTL). I now there are applications that have it there but it looks fairly odd and visually conflicts if the user shows the main menu bar, which has the same menu items.

Also, the spaces toolbar is an easily collapsable toolbar, which many users might not want since it takes a bit of horizontal space, and segregating the main appmenu in there will meant forcing users to keep it open.

There are some planned fixes an improvements in various areas that will fix all these issues.

• First, we're planning to unify the various toolbars and have a single implementation that dynamically changes the buttons based on the viewed tab. This will solve the inconsistencies.
• Geoff is planning to add the app menu and search bar in the new address book.
• The collapsed spaces toolbar will show a "pinned" button in the tabs bar to quickly access the tabs: https://phabricator.services.mozilla.com/D138983#4525103, so, having also the appmenu there will look extremely busy.

P.S.: I have a patch that I will soon ask you to review, which should allow add-ons to add buttons to the spaces toolbar.

Ok, yeah, that sounds reasonable. Thanks for the details.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/4ebda6f9fbbe
Show a pinned button in the titlebar tabs when the spaces toolbar is collapsed. r=henry,Paenglab

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/5453f7a530f2
Add test for the spaces toolbar context menus. r=aleca

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/14d5990dba8d
Create methods to allow add-ons to add extra buttons in the spaces toolbar. r=john.bieling,darktrojan

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/5c14abd4afae
Make the chat button aware of unread messages. r=freaktechnik

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/cad97be01c00
[Spaces Toolbar] Fix Windows tests for window resizing. r=darktrojan

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/94b3b8209575
Implement color customization for the Spaces toolbar. r=darktrojan,Paenglab
https://hg.mozilla.org/comm-central/rev/8e9a74c5b3e1
Add test for the spaces toolbar context menus. r=aleca

Make some small naming adjustments.

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/8f3d975ededb
Style the Spaces toolbar Customize buttons consistent. r=aleca

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/1e52081248fe
Follow up to: Add test for the spaces toolbar context menus. r=darktrojan
https://hg.mozilla.org/comm-central/rev/655bc8494858
Add tests for the spaces toolbar chat message badge. r=aleca

Seems to be a perma fail in comm/mail/components/im/test/browser/browser_spacesToolbarChat.js

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/9c2a66048e11
Add tests for the spaces toolbar chat message badge. r=aleca

Alessandro,

Just wanted to let you know that your work on the Spaces Toolbar looks very very good as I am testing it in beta version... well done!

Few very small suggestions from my part based on my last experience with it in TB 99 beta 1:

• The vertical line that separates the Spaces Toolbar from the rest of TB could be continuous from top to bottom, currently the top and bottom part (likely to belong to a different "widget" area) are thinner that the middle part of the vertical line - having the same width for the line all the way from top to bottom would be better looking and emphasize properly the separation all the way!

• That separation line could be of a darker grey colour or even black because sometime in certain Space tab left column (on the right side of the Spaces bar) have a grey background colour (e.g address book, chat, etc... By the way maybe those background colour could be harmonised between the different spaces! But discussion for another day!), so the separation between the Space Toolbar and the Space itself is much less contrasted... if I may suggest if not a darker line colour, a stronger vertical shadow along the separation line on the side of the Space Toolbar perhaps? To accentuate contrast/separation a bit more...
  Another alternative would be to change the background colour of the Spaces Toolbar to something different than grey... or a darker grey perhaps... or the blue background colour from the tab header area... you would be better judge :-)

• About the Spaces Menu appearing top left corner when folding the Spaces Toolbar [I like it very much as well as having the arrow icon appearing in status bar - well done very smooth!] I think you could simplify its content which is way to long by replacing "Switch to the mail tab" by just "Mail", replacing "Switch to the address book" but just "Address Book" and so on... it is really self explanatory... eventually replace the "Spaces Menu" alt text by "Switch to Spaces" when mouse over the Spaces Menu icon...

• Also I notice the "Settings" entry (and its wheel icon) is missing in the Spaces Menu, maybe add it before the arrow "show the spaces toolbar" that could be simplified into "-> Show Spaces Toolbar" - with a line separator between the two...

• Finally if you say "Show the space toolbar" in the Spaces Menu, then "Hide the space toolbar" instead of Collapse as a better antonym... or even rather just "Show Space Toolbar" vs "Hide Space Toolbar" to simplify even more as per above suggestion :-)

Those are really minor suggestions, keep the good work! And thank you for it! Great improvement!

Regards,

(In reply to Richard Leger from comment #102)

Just wanted to let you know that your work on the Spaces Toolbar looks very very good as I am testing it in beta version... well done!

Thank you so much, this makes me really happy!

The vertical line that separates the Spaces Toolbar from the rest of TB could be continuous from top to bottom, currently the top and bottom part (likely to belong to a different "widget" area) are thinner that the middle part of the vertical line - having the same width for the line all the way from top to bottom would be better looking and emphasize properly the separation all the way!

Uh, I didn't notice it, definitely a visual bug. Could you share a screenshot of the issue? Thank you for reporting it, definitely this needs fixing.

That separation line could be of a darker grey colour or even black because sometime in certain Space tab left column (on the right side of the Spaces bar) have a grey background colour (e.g address book, chat, etc... By the way maybe those background colour could be harmonised between the different spaces! But discussion for another day!), so the separation between the Space Toolbar and the Space itself is much less contrasted... if I may suggest if not a darker line colour, a stronger vertical shadow along the separation line on the side of the Space Toolbar perhaps? To accentuate contrast/separation a bit more...

Sure, I'll experiment with that, good suggestion.

Another alternative would be to change the background colour of the Spaces Toolbar to something different than grey... or a darker grey perhaps... or the blue background colour from the tab header area... you would be better judge :-)

You're in luck! Because from version 100 the spaces toolbar will be customizable. Here's what it looks like for me as I changed the background and accent color. https://imgur.com/a/RqpDp22

About the Spaces Menu appearing top left corner when folding the Spaces Toolbar [I like it very much as well as having the arrow icon appearing in status bar - well done very smooth!]

Nice :D

I think you could simplify its content which is way to long by replacing "Switch to the mail tab" by just "Mail", replacing "Switch to the address book" but just "Address Book" and so on... it is really self explanatory... eventually replace the "Spaces Menu" alt text by "Switch to Spaces" when mouse over the Spaces Menu icon...

Mh, so showing those menu items more as "buttons" with a simpler text.
I'd be okay with it, but I'm not sure I'm the best person to decide that since English is not my first language.
Ryan, Wayne, how do you feel about this?
Ryan, you said you use the Pinned Menu a lot, do you think those menu items are too verbose?

Also I notice the "Settings" entry (and its wheel icon) is missing in the Spaces Menu, maybe add it before the arrow "show the spaces toolbar" that could be simplified into "-> Show Spaces Toolbar" - with a line separator between the two...

I thought about it but I decided to not add the Settings tab in there because it's already in the main app menu. Maybe too many entry points?
I can add it if you think it would be a more intuitive entry point. It definitely would keep things more consistent.

Finally if you say "Show the space toolbar" in the Spaces Menu, then "Hide the space toolbar" instead of Collapse as a better antonym... or even rather just "Show Space Toolbar" vs "Hide Space Toolbar" to simplify even more as per above suggestion :-)

Makes sense, I'll do that!

Those are really minor suggestions, keep the good work! And thank you for it! Great improvement!

Thank you so much for using beta and providing valuable feedback.
We're improving a lot this section to make more and more useful and customizable. Looking forward to hearing feedback on the color customization aspect once it reaches beta.

I'll soon update the post in the UX list to highlight all the new things that are landing.

Cheers.

This patch takes care of addressing various small improvements.

• Makes the spaces toolbar a draggable area.
• Use the buttons img opacity for hover effects to not affect the unread bubble when visible.
• Dim the buttons when the window is inactive.
• Update the strings for tooltips, buttons, and menuitems in the pinned popup.

Ryan, you said you use the Pinned Menu a lot, do you think those menu items are too verbose?

No, I hadn't even thought about it. I think it makes sense. Maybe we should ask someone who hasn't played with it that much. I'll put it in front of a couple people, but my gut feeling is that this isn't too verbose and may actually be helpful as it tells people what is going to happen.

(In reply to Alessandro Castellani [:aleca] from comment #103)

(In reply to Richard Leger from comment #102)

The vertical line that separates the Spaces Toolbar from the rest of TB could be continuous from top to bottom,(...)
(...)Could you share a screenshot of the issue? Thank you for reporting it, definitely this needs fixing.

See attached. Just realised it may affect only the Home screen.

Indeed when no email account is setup, the Mail Icon entry in Spaces Toolbar leads to the Home screen... should it say then Home with a home icon in that case? The Home screen is in effect the Mail tab but with Home title and Welcome screen... just thinking that current discrepancy may confuse some people... it looks "odd"... to Mail space/icon lead to Home tab... even when you know it :-)

Another alternative would be to change the background colour of the Spaces Toolbar to something different than grey... or a darker grey perhaps... or the blue background colour from the tab header area... you would be better judge :-)
You're in luck! Because from version 100 the spaces toolbar will be customizable. Here's what it looks like for me as I changed the background and accent color. https://imgur.com/a/RqpDp22

Maybe investigate/test such settings or similar as default? It looks good on screenshot... maybe a less dark blue to keep it more subtitle, more discrete?
Maybe with a little shadow on the Spaces Toolbar side of the separating vertical line to integrate more "smootly", not too sharp separation?

I think you could simplify its content which is way to long by replacing "Switch to the mail tab" by just "Mail",
Ryan, Wayne, how do you feel about this?
Ryan, you said you use the Pinned Menu a lot, do you think those menu items are too verbose?

Considering how frequently the Spaces entries would be used (very often), the simpler it is in looks and feel, the better, and more intuitive it would be: Icon + SpaceTitle
You could always consider adding an alt text when mouse over for a while on entry (in both shown/hidden state) that says more for those that may wonder what it does... as an explication or suggestion what it would do to click on it.

Keep it simple as much as you can, to reduce clutter (here you can easily do so without much impact!).

Outlook for example only just show icons and I have never had any end-user complaining they could not find a calendar or contact or else... very self intuitive... at worth come to worth the discovery/training period would remain very short in comparison of the successive use of the button at high frequency/repetition.

Your honour, I rest my case :-)

Also I notice the "Settings" entry (and its wheel icon) is missing in the Spaces Menu, maybe add it before the arrow "show the spaces toolbar" that could be simplified into "-> Show Spaces Toolbar" - with a line separator between the two...
I thought about it but I decided to not add the Settings tab in there because it's already in the main app menu. Maybe too many entry points?
I can add it if you think it would be a more intuitive entry point. It definitely would keep things more consistent.

Yes please add it... to keep consistency!

What ever is in the Spaces Toolbar when showing, shall be present in the Spaces menu when hiding... otherwise you create/cause confusion (looks like a bug) and you create extra steps for those that would get use to find Settings in the Spaces Toolbar, forcing them to show toolbar to access Settings!

The fact that Settings remain accessible in the Main Menu (multiple entry points) is not a bad thing. Yes multi-point shall be minimised but not necessarily being totally avoided for intuitiveness and accentuated accessibility to features.

One entry is "accessing the Settings Spaces", the other one in Main Menu is "accessing the Preferences" which is not the same paradigm of thoughts to get to it, yet the same result, accessing the Settings tab. Also those end-users use to access it via Main Menu would like to keep it there (by legacy knowledge and habits), while the others may prefer accessing it via the Spaces Toolbar (faster, one less click).

For example (I confer it is a separate issue but it is to highlight how multiple entry points are not necessarily a bad thing), I would love to be able to access address book, view contact in address book or edit contact in address book, by simply right clicking on a contact pills choose entry in context menu.

The context and set of mind to execute the task more naturally make it easier to achieve it... if you see what I mean.

(In reply to Richard Leger from comment #107)

See attached. Just realised it may affect only the Home screen.

Ah I see, that's the splitter of the collapsed folder pane.
I will ignore this for now since we're rebuilding that whole content area. It won't be ready for 102 but it's a very minor visual issue that we can temporarily ignore it.

Also the whole email/home thing will change in the next cycle.

Maybe investigate/test such settings or similar as default? It looks good on screenshot... maybe a less dark blue to keep it more subtitle, more discrete?

I prefer to avoid that since colors and visual styles taste is very unique from person to person, and in situations like Ubuntu, where the accent color is orange, that colored background wouldn't work well.
I prefer to ship a default, bland, and unobtrusive visual style, allowing the user to customize the way they want.

Wow, Linux and macOS tests are all green: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=6c045541c0d1e92a64e48eb6bb0ef29399d4ce60

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/cbff1c6b0638
Add spacesToolbar API. r=aleca,darktrojan
https://hg.mozilla.org/comm-central/rev/a7826463e5c2
[Spaces Toolbar] Improve styling, strings, and show current indicator on pinned menu items. r=Paenglab

(In reply to Alessandro Castellani [:aleca] from comment #103)

I think you could simplify its content which is way to long by replacing "Switch to the mail tab" by just "Mail", replacing "Switch to the address book" but just "Address Book" and so on... it is really self explanatory... eventually replace the "Spaces Menu" alt text by "Switch to Spaces" when mouse over the Spaces Menu icon...

Mh, so showing those menu items more as "buttons" with a simpler text.
I'd be okay with it, but I'm not sure I'm the best person to decide that since English is not my first language.
Ryan, Wayne, how do you feel about this?
Ryan, you said you use the Pinned Menu a lot, do you think those menu items are too verbose?

In all things UI, I generally lean toward terseness - less words. That said, (edit) a) I have no strong opinion here, b) if there is greater value in conveying an action rather than a noun, or if it will be easier to document by keeping it, then keep it.

But to complicate matters further (and I apologize because I have not tested nor do I know whether this has been discussed), I wonder if the word tab should be dropped. Because, and I don't know if your implementation will allow for this (or wrecks the paridigm you are trying to achieve), I can foresee some (power?) users wanting multiple windows (rather than tabs) for some spaces to leverage multiple monitors (or perhaps other reasons) - Calendar or Chat for example, which likely should only ever have one "instance" open, regardless of how many TB windows exist - i.e. a user might want to aways have Calendar or Chat visible (and nothing else open in that window). (I could potentially be one of those users) I'm just free thinking here.

(In reply to Wayne Mery (:wsmwk) from comment #113)

In all things UI, I generally lean toward terseness - less words. That said, (edit) a) I have no strong opinion here, b) if there is greater value in conveying an action rather than a noun, or if it will be easier to document by keeping it, then keep it.

I ended up following Richard's suggestion and indeed it looks and feels way more consistent.
Shorter menu items and to the point.

But to complicate matters further (and I apologize because I have not tested nor do I know whether this has been discussed), I wonder if the word tab should be dropped. Because, and I don't know if your implementation will allow for this (or wrecks the paridigm you are trying to achieve), I can foresee some (power?) users wanting multiple windows (rather than tabs) for some spaces to leverage multiple monitors (or perhaps other reasons) - Calendar or Chat for example, which likely should only ever have one "instance" open, regardless of how many TB windows exist - i.e. a user might want to aways have Calendar or Chat visible (and nothing else open in that window). (I could potentially be one of those users) I'm just free thinking here.

That's indeed the direction we're aiming for.
Independent spaces with detachable windows that won't need to have the 3pane duplicated (mail tab). But that's way further in the future and it will need a whole round of discussions and prototypes on its own.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/35fabd21453a
Add unread indicator to pinned spaces menu. r=aleca
https://hg.mozilla.org/comm-central/rev/3b7ae3e8d08f
[Spaces Toolbar] Clear add-on buttons created during tests. r=john.bieling

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/edf1ef65a00a
Separate spaces toolbar draw in titlebar tests. r=aleca

• Add the spaces toolbar into the F6 focus ring.
• Add the spaces toolbar into the TAB focus ring.
• Add arrow keys on spaces toolbar to move focus to first/last button.
• Add arrow keys navigation to spaces toolbar buttons.
• Add shift + arrow keys to jump to first/last button.

Implement window keyboard shortcuts for the primary spaces.
Implement window keyboard shortcut to toggle the spaces toolbar.
Show the customize menuitem in the context menu of the settings button.

Depends on D141882

Small bug: if you collapse the spaces toolbar whilst the customize popup is open, then subsequent customize popups appear in the bottom inline-end of the window, rather than inline-start.

(In reply to Henry Wilkes [:henry] from comment #119)

Small bug: if you collapse the spaces toolbar whilst the customize popup is open, then subsequent customize popups appear in the bottom inline-end of the window, rather than inline-start.

Thanks for reporting this. I'm taking care of it in https://phabricator.services.mozilla.com/D142014.

This is needed to ensure that the measurement of #spacesToolbarAddonsContainer height in updateAddonButtonsUI is an accurate measurement of the available height. Otherwise, the height of the spaces toolbar is still influenced by the natural height of the addon buttons that are already shown. In particular, this is most noticeable when the spaces toolbar contains lots of addon buttons and the window is shrunk to a small height in one step (e.g. un-maximise).

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/f2a3386c65ab
[Spaces Toolbar] Improve a11y and add keyboard navigation. r=henry
https://hg.mozilla.org/comm-central/rev/4bd4df8d9c70
Allow spaces toolbar addons container to shrink arbitrarily small. r=aleca

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/ca08db408336
Make the Spaces Toolbar border visible with high contrast themes. r=aleca

Previously, when the spaces toolbar was revealed via the pinned tab button, or the status bar button, the focus was not moved into the spaces toolbar. This was because the code attempted to focus the spaces toolbar whilst it was still hidden, causing "focusButton.focus()" to fail.

We also ensure that focusButton follows a mouse click.

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/5e3b75463dc7
Fix focus handling in the spaces toolbar. r=aleca

This last changeset is most likely causing a test failure on macOS: https://treeherder.mozilla.org/logviewer?job_id=374148035&repo=comm-central&lineNumber=2621
I'll take care of it.

Backout revision: https://hg.mozilla.org/comm-central/rev/740e54653e6ab2f9dce92b41349d9d90d7c5d0d3

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/87a09a6b2f14
Fix focus handling in the spaces toolbar. r=aleca

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/63db1e90615e
[Spaces Toolbar] Implement new design system icons. r=aleca,Paenglab

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/90dde23697eb
[Spaces Toolbar] Remove opacity alteration for icons. r=Paenglab

I think the current one-word title attributes for the spaces buttons ("Mail", "Calendar", etc) are not very useful because they are not descriptive of their actions. I think we should keep the old title "Switch to the mail tab" (or rather "Switch to the Mail space") before revision a7826463e5c2.

The benefit of this is more obvious once the shortcut patch lands. Currently it would be

<button title="Mail (Ctrl+1)" aria-label="Mail" aria-keyshortcuts="Control+1">
  <img alt="" />
</button>

The accessible name for the button would be "Mail" and the accessible description would be "Mail (Ctrl+1)". I also think since "Mail" is a just meant to be a noun, rather than a verb, it is not the clearest that "Ctrl+1" is a shortcut for an action (switching to the mail space).

In contrast consider

<button title="Switch to the Mail space (Ctrl+1)" aria-keyshortcuts="Control+1">
  <img alt="Mail" />
</button>

In the second form, the accessible name of the button remains the same brief "Mail", and the accessible description is "Switch to the Mail space (Ctrl+1)". This is appropriate and very clear to all users.

Note, I personally don't think there is a practical disadvantage to having a longer title that is still only one clause. Whilst it might become unnecessary once a user is familiar with the application, the same applies to lots of buttons with titles, and I don't think it would be bothersome.

What are other people's thoughts?

It's not necessarily about switching though, as state is involved. You may already be on the "target" space. I think I would prefer just short titles. You could compare this to a web page with links: one would not write "Click to open link to example.com" as title of a link - the actions are implied.

(In reply to Magnus Melin [:mkmelin] from comment #136)

It's not necessarily about switching though, as state is involved. You may already be on the "target" space. I think I would prefer just short titles. You could compare this to a web page with links: one would not write "Click to open link to example.com" as title of a link - the actions are implied.

I see what you mean regarding links, but buttons do not have the same implied context. Also, following the link analogy, the current situation would be similar to <a title="Mail (Ctrl+1)">Mail</a> from a screen reader perspective. This is why I think a more distinct "title" to "aria-label" would be clearer and more helpful.

For comparison, the previous "calendar", "tasks" and "chat" toolbar buttons that this spaces toolbar replaced had the titles "Switch to the calendar tab", "Switch to the task tab" and "Show the Chat tab", respectively. Although, I suppose those were in a more generic context.

(think there are still some comments on phab)

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/e39217046a0d
Implement a global Shortcuts Manager as a first step for customizable shortucts, and add shortcuts for the spaces toolbar. r=mkmelin,thomas8,henry