Thunderbird:Old Menus

From MozillaWiki
Jump to: navigation, search

The menus are crufty. They take up about six full screens of text for me as they are below, and that's far too many. One of the big strengths of Firefox is that its UI is minimal. There's less to get in the way when you want to do something, and finding what you want to do is easier because there's only one simpler method to do so.

The basic way to fix this is by consolidation and removal. I haven't looked very much yet because I haven't had time and barely use most of the UI of Thunderbird (as I'm sure most people do). Consequently, in the initial step below I'm just going to start consolidating. Because the menus are so large, I'm going to do this in multiple pages, as described below:

  1. Current menus (crufty)
  2. After some consolidation (after item consolidation)
  3. After some item removal (with removal explanations)

There are no bugs in Bugzilla for this yet (that I've seen and remember), because this whole project is rather unclear at the moment. With more time, this can hopefully become clearer.

Finally, why not overhaul the interface altogether, in favor of absolute simplicity?

E.G., Is there any good reason why we should not introduce a "minimalist," possibly menuless, version of Thunderbird (incorporating suggestions made on Thunderbird:UI Reduction) alongside an "Expert" (feature-filled) UI, accessible by menu-activation?

If you have suggestions to make, just make the changes on the appropriate page (and associated previous pages) and explain your reasons!

So far, you've neglected context menus, which I think are very important for balancing the various menu options; there currently are some actions available only in a context menu. How much duplication between the two sorts of menus is appropriate? (Also, no consideration yet to Compose Window and Address Book menus.) One possible way to deal with this would be to have a  File | <item>  menu (where  <item>  is "Account" "Folder" or "Message" depending on what's selected) and put some or all of the context-menu items as a submenu to that top-level item. However, this does prevent (some) operations on one type of item when the focus is on another.
Keyboard shortcuts are displayed in the top-level menus; while you could eliminate menu items in favor of shortcuts, I don't think that would prove to be popular.
How do toolbar(s) enter into the equation? Is it acceptable to have a toolbar button that is the only place to perform a particular function? I don't think so, myself—I think every item on the main toolbar should be duplicated in the top-level menus—even those actions that clearly belong in a context menu.
What about adding additional toolbars, such as a message-display toolbar (controlling things like Inline Attachments, Message Body As, etc.). Making a change on this toolbar ideally would be used only for the current message, resetting to the default when the next message is selected; but the defaults could be moved into the Options dialog, with the associated View menu items stripped out.