Mobile/UI/Designs/TouchScreen/Fennec 1.1+/Extended site menu
The site menu should be extended to contain commands the desktop Firefox provides in the menus or elsewhere in the chrome. In addition to Larry, it should contain options related to content the browser is displaying and they could be provided both by the content (such as subscription to feeds made available with link tag in the head of HTML file) and browser UI (such as Save as). Also, the site menu could contain options for activating browser features such as "Find in page" and it could be place also for commands the user has added to Fennec by installing Add-ons.
The site menu should show items in the following order:
- Larry i.e. security information of the site etc
- Dynamically appearing commands the desktop Firefox can display in its chrome (awesome bar) such as feeds a content-provider has made available in the head part of HTML page and therefore are not displayed in the content area.
- Browser-provided commands such as Find in page, Save as etc.
The reason to place dynamic page-provided menu items directly after Larry is to make them easy to perceive/find by the user whenever they are available (because they are not available on every web site/page).
Browser UI provided options (such as Find on page, Save as etc) should be displayed in the order of their importance. Potentially, it would improve usability, if the most frequently used commands appeared first in the list and less used last. However, if the site menu should contain editing commands (cut, copy, paste) on one day, they should be placed after the Larry but before Feeds to make them available for use as instantly as possible.
The menu should provide functional options only and not contain any dimmed commands. This would help in keeping the menu as short as possible and thereby improve usability with mobile devices that typically have fairly limited size of screens. If a command could not be available in some circumstances, it should be simply removed from the menu.
For usability reasons, a menu item should stand for a single action only and it should be functional as a whole. It should not contain any nested button or buttons. If the menu would contain some option with a checkbox, the whole item should be interactive, not just the part of item that indicates the state of it.
Also for usability reasons, the user should be able to cancel a selection from the menu safely i.e. close it without executing any extra action. The menu should be closed when the user taps anywhere outside of it and this should not trigger any other action such as reloading the page or closing the browser etc. This is how desktop Firefox works (at least with Mac) and it works fine.
In general, the site menu should display the options in one column for narrow screen or portrait orientation and in two columns for wide screen or landscape orientation. Larry should make an exception and take always full width of the display because it will display quite a lot of content (and long text strings).
The reason to use two column layout for landscape orientation is to use screen area effectively for commands/content:
- Menu can show more commands in two columns than in one column at once.
- Usability is not sensitive to device orientation: you can see approximately the same number of commands both in landscape and portrait orientation at a time.
Regarding the layout of indivudual menu commands, they should consist of a single text string without an icon. Icons can make the menu to look busy without adding any extra value (such as better intelligibility or readability). However, Larry will and commands for feed subscription should make exceptions.
The command for a feed subscription could have two lines of text in addition to Feed icon. The first text line should label the name of feed (that is given by the title attribute of link tag in the HTML) and the second line of text would be purely informative and let the user to know the functionality of the item. If the HTML file does not define the title attribute in the link tag, the menu could show the address detailed by the href attribute.