Closed Bug 1668612 Opened 4 months ago Closed 2 months ago

Remove the Customize entry in the App Menu and reorganize items under View

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement

Tracking

(thunderbird_esr78 wontfix, thunderbird84 wontfix)

RESOLVED FIXED
85 Branch
Tracking Status
thunderbird_esr78 --- wontfix
thunderbird84 --- wontfix

People

(Reporter: aleca, Assigned: aleca)

References

Details

(Keywords: ux-discovery, ux-efficiency)

Attachments

(1 file, 1 obsolete file)

This is a proposal to optimize a bit the items in the our App Menu.

I think we should get rid off of the Customize menu item, even if I was the one implementing it in bug 1619731 with the underlying intention of emulating the FF App menu.

This menu item doesn't really work as we don't offer a full tab view of customizing the interface like in Firefox, and in the current state we have an inconsistent organization of menu items between the App Menu and the Menu Bar.

The Layout customization and the toggling of layout elements should all be inside the View menu, and be better organized in specific sections.
Another implementation is the ability to not autoclose the app menu if the click happens on a toggable item, so the user can see the changes and quickly toggle on and off other items without the necessity of reopening the menu every time.

Thoughts?

Attached patch 1668612-customize-menu.diff (obsolete) — Splinter Review

A quick patch to update a very annoying part of our App menu, which I've been interacting often during the folders view bug, and I wanted to quickly improve it.

With this, the organization of the toolbars, layout, and folders submenu matches the Main Menu Bar.
It didn't make much sense having some layout customization items in the Customize... submenu, and others in the View submenu.
I think it makes more sense to keep all those options under the View submenu.

I also did a little test in which the menu items in the Toolbars submenu can be toggled on and off without the App Menu automatically closing.
I think we should consider something like this as it helps a lot going through the various UI options without forcing the user to reopen the menu every time.

If you agree with this implementation, I'd like to create a follow up bug to enable to "no close" attribute to all the other checkboxes and radio items we have, when it makes sense.
I think this will bring a great usability improvement.

Attachment #9189548 - Flags: ui-review?(richard.marti)
Attachment #9189548 - Flags: review?(mkmelin+mozilla)
Status: NEW → ASSIGNED

Comment on attachment 9189548 [details] [diff] [review]
1668612-customize-menu.diff

Maybe we need some indication that the panel doesn't close after clicking. Without we could get bug reports that the panel doesn't work correctly.

Or maybe the old behaviour when left clicking and when right clicking (or SHIFT + left clicking) let the panel stay open. This wouldn't be obvious but it's no change of the old UI behaviour ( ;-) ).

PS: we should fix the menu by moving the menu bar entry on top of the list.

Attachment #9189548 - Flags: ui-review?(richard.marti) → ui-review+

Maybe we need some indication that the panel doesn't close after clicking. Without we could get bug reports that the panel doesn't work correctly.

Do we currently have any mechanism inside TB to highlight tot he user a behavioural change?
I wonder if we should consider implementing those handy floating focus circles when a user access a new or updated section for the first time. Maybe worth discussing it in a dedicated bug?

Or maybe the old behaviour when left clicking and when right clicking (or SHIFT + left clicking) let the panel stay open. This wouldn't be obvious but it's no change of the old UI behaviour ( ;-) ).

It seems cumbersome, especially since this behaviour is achieved with a simple attribute on the menu item, so doing it based on the click interaction might add some unnecessary complexity.
I think we should identify what is the most efficient default behaviour, and find a way to let users know.

I could also remove that implementation from this bug and create a dedicated bug for it, and maybe share it with the mailing list to gather some feedback.

Thoughts?

Comment on attachment 9189548 [details] [diff] [review]
1668612-customize-menu.diff

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

LGTM, r=mkmelin

::: mail/base/content/mailCore.js
@@ +432,1 @@
>        if (toolbarName) {

Do an early continue, instead of indenting everthing?
Attachment #9189548 - Flags: review?(mkmelin+mozilla) → review+
Attachment #9189548 - Attachment is obsolete: true
Attachment #9190021 - Flags: review+
Target Milestone: --- → 85 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/d370e6e4e418
Remove the Customize entry in the App Menu and reorganize items under View. r=mkmelin, ui-r=Paenglab

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.