Documentation/Maemo 5 Developer Guide/Porting Software/Redesigning From Maemo 4 to Maemo 5
Contents |
Redesigning From Maemo 4 to Maemo 5
This chapter instructs how to re-design a Maemo 4 application to Maemo 5, i.e. the Hildon 2.2 UI Style. The Modest email client is used as the example application.
Overall Guidelines
Compared to Maemo 4, the Hildon 2.2 UI Style in Maemo 5 is much more optimized for finger usage in small mobile device displays.
When the focus in design moves from stylus oriented user interface (UI) to finger optimized user interface, the reduction of the amount of visible elements in the UI becomes first priority. This means that unlike typical desktop applications, most of the functionality is not provided in a single view, but instead there are more views and each view is optimized for a single use case only. This is similar to the UNIX philosophy – “do one thing and do it well".
The major changes in the Hildon 2.2 UI Style include larger size for UI elements, removal of focus (particularly in lists), no dimming of buttons, limit of 10 items in view menus, removal of tabs in dialogs and lesser importance of toolbars and context sensitive menus.
Larger size of UI elements
By default, the UI elements in Maemo 5 should be designed as “Finger size”. This means that on average, a view can contain fewer visible UI elements. To compensate this, views and dialogs can be designed to support panning, allowing for larger amount of UI elements in total. However, panning is not an ideal design solution for all use cases.
Removal of focus
While in Maemo 4, the application menu and the toolbars often relied on focused/selected item or items as the target of a command, in Maemo 5 there is no focus. This also means that keyboard navigation is not supported in the UI in general.
In Maemo 5, the design should follow one of two possible UI flows:
- User navigates multiple views from a list or a grid of items to a view with single item. Commands that operate on that single item can be provided in that last view (typically via View menu or Toolbar)
- After user has activated a command, a separate item selection view is used (typically Edit Mode view)
No dimming
Instead of dimming (buttons, menu items ...), the UI elements should be simply hidden away, when they are not active. There are some corner cases where hiding would break the UI flow. For example Edit mode view toolbar simply shows the action button as always active, even though nothing happens, when nothing is selected, if the button is pressed.
Limit of 10 items in the view menus
The Maemo 4 application menu typically contains most or the full set of functionality of the application, organized in hierarchical menus. In Maemo 5, there is a strict limit of maximum 10 items in a view menu, and there is no menu hierarchy.
The Maemo 5 View menus are not application menus, in the sense that a view menu only contains commands relevant to that particular view. The only exception to this is the Root view menu, which additionally contains menu item(s) for application settings.
Removal of tabs in dialogs
When designing dialogs in Maemo 5, the tabs of a Maemo 4 dialog are merged to a single tab-less dialog with the whole content area of the dialog being pannable. In practice this results in user panning the dialog instead of switching between tabs.
If additional semantic grouping is needed for UI elements within the dialog, then group titles can be used by utilizing GtkFrame.
Fewer toolbars and context sensitive menus
With the removal of focus from default lists and grids, the UI designs for Maemo 5 typically do not include toolbars for views that contain multiple items. Toolbars are still used in views where only a single item is being shown.
The main use cases for context sensitive menus in Maemo 5 are only:
- To show commands that operate on a single list/grid item
- To show commands related to an item inside content, for example a web link.
Note that the context sensitive menus should only include commands that are not available elsewhere in the user interface.