The chrome structure has seven parts:
The Toolbar, Address Bar, Bookmarks Bar, and Preferences Bar should exist in a toolbox
at the top of the window (immediately under the menu bar, on those platforms which do not have a global menu bar). Within this toolbox they can be rearranged by advanced users. By default, each of these bars should be placed on a separate row, both to make their distinctiveness obvious for novice users and to provide an address field of decent length for advanced users. The Status Bar should appear at the bottom of the window, and the Sidebar on the left side of the window between the toolbox and the Status Bar.
Each of those bars containing controls which may not fit in the bar completely — the Toolbar, the Bookmarks Bar, and the Preferences Bar — should, when and only when it is overflowing, have a menu at its right end providing access to the overflowed items. This menu should have chevrons (>>) as its title, and look and feel exactly the same as any other pulldown menu in that theme.
The Toolbar should the following buttons by default, in this order:
Overall, the default button order forms three sections:
In addition, the button order maximizes consistency between Mozilla installations — so that people can use Navigator on someone else’s computer, or at a kiosk, with the least possible mental disruption. In order:
Many installations will not have mail/news and/or Composer installed, so those buttons will not be present without affecting the position of the others. Conversely, distributors may include buttons for their own apps at this end of the toolbar (for example, Netscape may include an AIM
button) without disrupting the other buttons.
Many cafes or kiosks will not only omit those other Mozilla apps, but will also hide or remove access to the History feature, and maybe Bookmarks as well; again, this will not affect the position of the remaining buttons.
Kiosks dedicated to browsing a fixed collection of documents which do not need an external Search function will hide that button, again without affecting the positions of the more critical buttons.
Those people (such as current Mozilla contributors) who have grown used to not having a prominent Home button can remove it without affecting the position of the four basic navigation buttons.
Placing Back and Forward at the left end of the Toolbar is canonical behavior followed by every version of every major Web browser (except for Opera). And placing Stop between Forward and Reload (rather than to the right of Reload) minimizes the average distance to the Stop button from any of the other three buttons, to maximize the probability that you will get to the Stop button in time when you need it.
Editbuttons? Don’t we have the Component Bar for that?
Netscape usability tests show that one of the biggest problems users have with Mozilla is working out how to get to their e-mail. The Component Bar is not working as an access point for Mozilla components — firstly because it is placed in an area of chrome (the Status Bar) where people expect to find status, not applications, and secondly because the icons are inevitably too small to be easily recognized as applications.
Removing the Component Bar, and replacing it with Mail
and Edit
buttons in the Toolbar, makes access to a user’s e-mail much more obvious and provides symmetry with the Browse
button in Composer’s Toolbar, as well as reducing clutter in the Status Bar.
The Address Bar consists of the following:
Address:
For the convenience of Unix users, clicking on the Address:
label should clear the address field and give it focus for entry of a new address.
For maximum elegance, the width taken by the Address:
label and the width taken by the Go
button should be exactly the same.
Address Bar? But that's what Internet Explorer calls it! Ewwww, cooties!
It doesn’t matter what Internet Explorer (and Opera) call it; what matters is using the same terminology as the rest of the world, so as not to be gratuitously obscure. The W3C calls URIs addresses
, and even Netscape 6’s own online help consistently uses address
to explain what it means by URL
. As for the general population, people who call URIs addresses
outnumber those who refer to them as locations
by a ratio of sixty to one.
The Bookmarks Bar should contain as many of the user’s bookmarks or bookmark folders as fit on the bar, beginning from the start of the bookmarks list. Those items which do not fit on the Bookmarks Bar can be accessed from its chevron menu, or (more quickly) from the Bookmarks menu itself.
The Preferences Bar (off by default) provides quick access to those preferences commonly toggled by advanced users, so they can improve their reading experience on difficult or annoying pages. (It does not contain settings such as Text Zoom or Encoding which are commonly needed by some sets of novice and intermediate users; those should be optional buttons for the Toolbar itself.) Ideally settings set in the Preferences Bar should apply only to the current window (with settings from the last open window being saved on exit), but an initial implementation may apply settings to the whole of Mozilla.
The Preferences Bar should contain the following checkboxes:
Fonts(equivalent to
Allow documents to use other fonts)
Colors(equivalent to
Allow documents to use other colors)
Images
Plug-ins
Scripts(equivalent to
Enable Javascript)
Unrequested windows(equivalent to
Allow scripts to … Open unrequested windows).
The Status Bar contains the following:
Done);
The contents of the Sidebar is covered in the Sidebar spec.
For maximum predictability from the user’s point of view, chrome state should obey the following rules.
For existing browser windows, when chrome is turned on or off, the new setting should apply only to the window where the change is made.
If a new browser window is opened from an existing window by choosing File
> New Window
, from a link, or from a script where the Web author did not set size or chrome state in the new window, then:
If the Web author did not set size or chrome state in the current window either, the new window should have the same size and chrome state as the current window.
If the Web author did specify size or chrome state in the current window, the new window should have the same size and chrome state as the most recent window where the Web author did not set size or chrome state but the user did.
In all other cases (such as double-clicking on the Navigator
icon, or opening an Internet shortcut from another program):
If there is only one browser window open where the Web author did not set size or chrome state, or if there are multiple such browser windows which all have the same state, the new window should have the same size and chrome state as the existing window/windows.
If there are no browser windows open where the Web author did not set size or chrome state (for example, if there are no windows open at all), or if there are multiple browser windows open with different user-set size or chrome state, the new window should have the same size and chrome state as the most recent window where the Web author did not set size or chrome state but the user did.
Don’t panic, you don’t need to understand any of that before you read the rest of the spec.
Show/Hidesubmenu
As with every other Mozilla application (except Chatzilla), the first item in Navigator’s View
menu is a Show/Hide
submenu containing toggles to turn chrome on and off. The submenu should appear as follows:
For quick toggling by advanced users, each of the chrome areas should have a shortcut menu with the same structure as the Show/Hide
submenu. This shortcut menu can be opened anywhere in the chrome, except those actions which have their own shortcut menu (dual menubuttons, the address field, items in the Bookmarks Bar, and tabs in the Sidebar). At the end of the menu for each area of chrome is a context-sensitive item for controlling the contents or state of that area, as follows.
Toolbar | Address Bar | Bookmarks Bar | Preferences Bar | Status Bar | Sidebar |
---|---|---|---|---|---|
|
|
|
|
|
|
Firstly, a shortcut menu is a very awkward interface for a detailed operation such as customization, which is likely to require several actions in succession. Unless the menu was extremely long, it would constantly need to defer to a New Item
or similar dialog anyway for addition of items, vastly increasing the number of mouse clicks required.
Secondly, customizing the Toolbar of any program is an extremely uncommon operation, in comparison with temporarily turning chrome on and off to make more screen real estate available for a given window or document. So to spend the shortcut menu on Toolbar customization, while making the user go into the Show/Hide
submenu to show or hide the Toolbar, would succeed primarily in wasting the user’s time.
And thirdly, a button-specific shortcut menu would be incompatible with the power user technique of using the secondary mouse button to increase the target area for the Back and Forward menus.
All customization of the Toolbar is carried out in a Customize Toolbar
utility window. As changes are made in this window, they should be applied immediately to all open browser windows.
Unless the window needs to be wider for all its elements to be visible, it should be as wide as the most recently focused Navigator window.
Users are able to customize two aspects of toolbar style from the Customize Toolbar
window: the use of icons and/or text (default being both), and whether toolbar icons are small (the default) or large. It should not be necessary to download or switch to a whole new theme to personalize the Toolbar in this way.
Following Windows interface standards, the small size for toolbar icons should be 16×16 pixels, and the large size should be 24×24. The icon size controls in the Customize Toolbar
window should be made inactive if the button style is set to text
.
Items can be added to the Toolbar by dragging them into the Toolbar layout
frame from the Available buttons
list, a Web page, the user’s file manager, or any other window which contains a draggable file or link. If the current layout is wider than the Toolbar layout
frame, the frame should auto-scroll when appropriate (that is, when the cursor has moved since the drag action began, and when the cursor is within 0.5em of the vertical edge of the frame). Dropability is shown by an I-beam drawn at the item boundary which is nearest to the cursor, and (for items dragged into the frame from outside) a drop ring for the whole Toolbar layout
frame.
Items can be moved within the Toolbar, or removed from the Toolbar, by dragging them from the Toolbar layout
frame. Dragability is indicated by an open hand cursor when over an item, and a grasping hand cursor when dragging an item.
Nice thought, but this is toolbar customization. If you can’t use a pointing device, you’re not going to be using the Toolbar in the first place.
That would add far too much complexity for too little gain. Not only would there need to be UI for creating and deleting toolbars, that UI would need to be kept unconfused with the UI for showing or hiding toolbars, and there would also need to be UI for naming toolbars, and UI for giving each toolbar an access key for the Show/Hide
menu, code for making sure the access keys did not clash with other items in the menu, UI to determine text/icons/both mode for each bar, UI to distinguish between (for example) bookmarks and bookmark folders if they were text only, UI for specifying how short to squeeze the address field in a narrow window before making buttons in the same toolbar overflow as well … You get the idea.
Within the toolbox at the top of the window, it should be possible for a user to horizontally and vertically rearrange the Toolbar, Address Bar, Bookmarks Bar, and Preferences Bar however she desires. Rearrangement is performed by dragging any part of the relevant bar (except the address field or Bookmarks Bar items) with the middle mouse button, or with the primary mouse button when the Alt/Option key is held down. (When the Alt/Option key is down and the cursor is over any of these bars, the cursor should become an open hand, and toolbox controls should not respond to mouseover or focus events.) This makes rearrangement sufficiently difficult to avoid accidents, without requiring rearrangers to go through a fiddly unlocking/locking or similar process with tiny grippies.
This plan is designed so that Mozilla’s chrome becomes incrementally more usable, with the biggest improvements first, and so that Mozilla is distributable at any stage without the need for branches or humungous checkins.
The Toolbar and Address Bar should be split, and the Personal Toolbar
renamed to the Bookmarks Bar
. This step can and should be done before other changes to toolbar structure or customization, as it provides a significant usability improvement in itself. More text is visible in the address field and the auto-complete menu, the Home button is available in its expected place without the user having to have the Bookmarks Bar turned on, and the function of the Search button is much less ambiguous.
Checklist:
The Show/Hide
submenu appears as follows:
The Toolbar contains the following, in order:
The Address Bar contains the following, in order:
Address:(with a colon)
Gobutton (on by default for new profiles).
The Bookmarks Bar contains the following, in order:
The Navigator
preferences panel no longer contains checkboxes for the Home
or Search
buttons, as hiding them currently does not make room for anything else (and when it does, they will be in the standalone Customize Toolbar window instead).
The Component Bar should be retired in favor of a complete set of default buttons for the Toolbar, using updated icons for Classic (to match the visual style of Windows XP and Mac OS X) and Modern (to allow aesthetically sensible use of separators, and future implementation of the text/icons/both option). Again, this can and should be done without waiting for customization to be implemented, as it would help to bring Mozilla’s chrome nearly to the level of usability of the similarly uncustomizable 4.x.
Checklist:
The Show/Hide
submenu appears as follows:
The Toolbar contains the following, in order:
The ability to set Toolbar buttons to text, icons, or both should be implemented so that it works in all non-broken themes (such as Classic and Modern).
Checklist:
The Show/Hide
submenu appears as follows:
The Icon Buttons
, Text Buttons
, and Icons and Text
options should work in both Classic and Modern.
The toolbar grippies should be retired, in favor of shortcut menus to show/hide chrome elements. This would make it easier to quickly adjust the amount of chrome in a given window. It would also resolve a number of otherwise unfixable bugs about confusion between hidden and collapsed state, the ugly appearance of toolbars whether expanded or collapsed, and the problem that grippies look like grippies but aren’t grippable.
Checklist:
The shortcut menus for each bar appear as described above (modulo the Preferences Bar
item), and function as expected.
The shortcut menus are overridden as expected by control-specific shortcut menus for the Back and Forward buttons, the address field, and bookmark items.
Chevron menus, as used in native toolbars in Windows and Mac OS X, should be implemented for the menu bar, Toolbar, and Bookmarks Bar (replacing the Bookmarks menu in the Bookmarks Bar), and Preferences Bar (if checked in).
Checklist:
View>
Character Codingsubsubsubsubmenus under these conditions, lest they suffer vertigo.)
Those bookmarks which do not fit in the Bookmarks Bar are available from its chevron menu.
Navigatorcategory of Preferences no longer has a checkbox for the Bookmarks menu, since it has been replaced by the chevron menu.
The ability to customize the buttons in the Toolbar should be implemented, and the text/icons/both UI moved to the new Customize Toolbar
window.
Checklist:
The Show/Hide
submenu, and shortcut menu for the Toolbar, appears as follows:
The Customize Toolbar
window works as expected, immediately updating all open Navigator windows whenever a change is made.
Any remaining toolbar options in the Navigator
preferences panel are removed.