Legacy Maemo 5 Documentation/Human Interface Guidelines/View Menu

Contents

View Menu

The view menu follows a very different approach from the traditional application menus. There is no menu bar, the view menu is activated when the user presses the application's title area.

The view menu can hold until ten menus at most divided in two columns - or one column in portrait orientation. It can also include filters. The menu items are in fact buttons and there are no sub menus.

Figure 8: A view menu


Menus that perform similar actions, for example "Previous" and "Next" (like in figure 8), should be placed side by side. The most important menus should be placed on the top of the view.


Actions that are available from another place in the application (either in the interface or from a hardware key) shouldn't be repeated by a menu.

The view menu should be different according to the current view. For example, is a user is the the "Inbox" sub view of an email application, he should access the view menu of the "Inbox" and not the view menu of the root view.


What if more menus are needed?

Following the principles stated in section 1.8, "Hildonizing an Interface", it is possible to keep the interface simple yet functional.

If some actions that could perfectly fit in a sub menu in a desktop application do not fit in a view menu, consider creating a new sub view that will contain the commands that don't fit in the view menu.

For example, consider a text application that should have a "Format" menu with several sub menus: "Comment Lines", "Remove Lines", "Duplicate Lines", etc. Such is not supported by a Hildon menu, however, a new sub view can be created that will hold buttons to perform the actions intended to be sub menus of "Format". That sub view appears when the user presses the "Format" menu.

Remember, keep the number of menu items low, add only useful ones. The less menu items, the better. This is important not only due to the limited number of items that a Hildon menu supports but also because of not forcing the user to navigate through a large number of views in order to get the wanted functionality. If a menu item's action can be already performed by some other widget in the interface, do not include a menu for it.

Filters

Apart from the menu buttons, filters can also be used. Filters are toggle buttons that can used for presentation/sorting purposes. For example, sorting alphabetically a list of contacts or changing the size of icons in a list.

As a general rule, these actions shouldn't change the amount of data displayed, just how that data is presented.

Filters should be presented in groups. For example, if the menu should allow the user to sort a list of messages alphabetically, the filters present should be at least a "sort alphabetically" filter and a "sort by date".

Menu Keyboard Shortcuts

Sometimes it makes sense to add keyboard shortcuts to some actions that can be performed from the menu.

If the shortcut will perform a common action like creating something new, format the text as bold or undo, key combinations from generally known applications should be used, independent from the user's language. For example, the previous mentioned actions would be Ctrl+n, Ctrl+b and Ctrl+z, respectively.


Menu Items Sensitiveness

Even though it is a common and useful practice to make menus items insensitive on a desktop application when their actions are not available, on Hildon they should instead be made invisible.

Figure 9: An incorrect view menu


Although dimmed menus items suggest the user that an action is not available, will clutter the menu and make it more confusing for users to choose what they want. Figure [localhost#fig:view_menu_wrong 6.9] shows an example of a wrong view menu since the last menu item is dimmed and not invisible.