Design Tips

Keep it simple and easy to use

• Pick one problem to solve with your application and solve it well

• Make it obvious what your application does and how it works

• Be brief, succinct, and sparing with layouts, functions, and copy

• Design your application from the top down, with the most important information at the top

• Consider ergonomics and the size of people’s fingers when laying out your application and designing controls

Use scrolling carefully

Part of helping people understand your application and what it does lies in making scrolling predictable. Only scroll repeating content or UI elements like lists, don’t hide distinct functions below the fold line because people may not realize that they need to scroll to find that feature.

Keep it consistent with core components

Where possible, use MeeGo common components in your application. This helps the user apply what they learn from other MeeGo applications to yours, and gives them a smooth, consistent experience as they navigate around their device. It is mandatory to have ‘Home’, and ‘Back’ in all views, the only exception is in full screen mode, available in application-like media players.

Think outside your app

When designing your application, consider what might prompt people to leave your application and go into another, or vice versa. Optimize your design for the reality of multitasking.

Strive for iconic character

Each view in your application should be uniquely recognizable and understandable, even when it is scaled smaller in the switcher, to help people find it and reopen it when they are multitasking. An application should celebrate its unique content and functionality in a way that emphasizes the iconic quality of the application, without compromising usability gained through the use of consistent components.

Application Types

Before moving on with your application design, it is important to identify the nature of the task your application is dealing with. This should be the main drive behind the proposed user experience. Think about the focus of the application and the motivations for someone to use it. Understanding the nature of your application also helps you organize and choose how to display information and interactions.

Even though it is impossible to classify each, as it would be impossible to identify every possible application that could be created, the two types at each end of the spectrum are productivity and immersion.

Productivity

If an application deals with more pragmatic actions, such as sending a text message, it is described as a productivity application. These are usually tasks where efficiency is key, not only in terms of performing the task, but also precision on getting to it. A well organized drill downs structure and simple toolbars with key actions, are good examples of how to present a responsive and quick task.

Therefore, these applications usually rely more on common components to build their UI, as simplicity is preferred. This is not to say that such couldn’t achieve an engaging experience.

Immersion

There are applications offering more entertainment-based or visually rich experiences, like playing a video or browsing a map. Full views are quite often used in such cases. Although connecting to core behaviors of MeeGo’s UI helps users feel in control when stepping into a new environment, custom-made layout or component might provide a more appropriate experience to what is being offered.

Games are the perfect example of immersive applications. Users expect to be entering a ‘new world’ as a new game is launched. Whether they have a simple structure or complex, it is up to the designer to decide how to represent content, navigation, or interaction.

Application Basic View

An application may appear in many formatting options (such as full screen mode, grids, etc), but most views follow a basic structure.

Status Bar

The main use of the status bar is to show signal strength, time, and battery life (operator optional). In addition, it supports notifications. This bar may be removed in specific cases.

Title Bar

The title bar contains the homescreen button, title, or tabs, View Menu (opened from the title), and the close or back button. Each view has a title specific to the view. In other words, most of the time the title gets updated as the user navigates through an application. This bar may be removed in specific cases.

Content Area

This is where most of the action happens and the layout gets dynamic. Content area can present navigation options, text, media, etc. Actions are not limited to View Menu and toolbar, they may be presented together with the content, as well. Other types of actions, such as media control buttons, can be presented together with the content. Refer to the Common Components for all button variants.

Tool Bar/Tab Bar

This is an optional fixed bar available to an application at all times, whenever core commands are needed. It is also possible to use it for navigation options. The bar is limited to 4 actions. In landscape, this bar moves to the top, together with the title bar. Even though either icons or labels can be used (but not both at the same time). Icons recommended due to localization issues.

Recommendation on Layouts

As seen on the Application Types section, not only how you organize, but also how you present your layout will have a major impact on the user experience. While a list presenting content may be suitable for a pragmatic task, other formats might be more engaging for other applications.

Whereas navigation models help organize how to structure an application, they do not imply any format or layout of how to present it. Drill downs are the perfect example. They serve as a model for several applications, such as a phonebook and Image Viewer. These present different types of content and, therefore, an array of distinct experiences.

Here we present two options of how to format a gallery, both using drill down as navigation structure. The application does not present a long list of navigation options, and has images as its core experience. Presenting items in the top level of the navigation helps make it more engaging, as well as providing quick access to the latest content from the first screen.

Consider the type of content and how complex the structure is, and explore the maximum amount of screen real estate.

Portrait vs. Landscape

Device orientation will suit multiple applications in different ways. While watching a video is best in landscape, with the media taking up all the screen, scrolling long lists is more comfortable in portrait.

MeeGo common components are always provided for both orientations. In other words, by using them, there is no need for extra work. It is advisable, however, that anyone building an application acknowledges such a change, as it might impact the desired experience.

Applications can overwrite default changes. However, it is recommended that all application provide both portrait and landscape mode. The main reason is the form factor of some available MeeGo devices. In devices with a slide hardware Qwerty, the landscape experience becomes key, and somehow extended. Therefore, the user shouldn’t be forced to change orientation to complete a task. Playing a game is one of the few exceptions to this rule, as its experience flow does not require (in most cases) the use of any other application.

Assets can be subtly resized and/or reshuffled to make better use of the screen real estate after changing the orientation.

1 vs. 2 Columns

Lists are probably the most common UI layout, and have a particular behavior depending on the orientation.

Whereas portrait allows for more items to be presented, landscape presents the possibility to extend the content area of a particular item. This is especially useful for text strings, which, in landscape, get more character area. The title of a message, for example, has less chance of being truncated.

Some applications may consider splitting lists into two columns, when in landscape, to optimize space usage. This may be used when there is no hierarchical order, usually in first level drill down pages. However, this should never be done when the list follows a specific order criteria (such as chronological, alphabetical, etc).

Buttons should always be centralized (especially important due to two column split) and, full width in both orientations.

Settings

Always consider designing the application settings. The user accesses settings from the View Menu in your application. The Settings view presents Home, Title, and Back (View Menu is not necessary).

In some cases, it might be desirable to provide quick access to specific settings of an application’s sub-views. These will be a corresponding sub-view of the application’s global settings. For example, in a subview of a Messaging Application showing a specific account, settings could take the user to the sub-settings of that account. However, there is a navigational difference in such cases. If the sub-view of settings is accessible from the correspondent sub-page, “Back” would take the user back to the page where it was opened from, and not back to the settings top level.

In the Settings view, group similar settings (by using visual dividers) together to help the user find related options. Each group can contain multiple items, such as texts, images, and buttons.

If the user can change settings directly on the UI, do not include those settings in the Settings view. For example, if the user can set a clock alarm directly in the Clock Application main view, do not include the alarm setting in the Clock settings view.

Note that when the user changes the settings, the change takes place immediately, with no need to save changes. You can use the Undo button in the view menu to discard any changes, and reset all changed settings back to the previous states. The Undo button is shown only after the user has made changes.

Navigation within your applications

Applications may vary in navigational patterns. Three main templates have
been created to help support the application’s main functional goals.

Drill Down

This is the most scalable template, used when access to all application navigation structure is needed on the top level. Layouts are not restricted to lists. The Close button gets replaced by a Back button, as the user drills down the structure.

Navigation in View Menu

This template is for flat experiences, prioritizing content over navigation structure. View Menu is used for hopping between navigational options. This allows for many navigational options, as opposed to the Tab Bar template (below). As all these navigation points work as the top level of the application, the close button remains even after a navigational change. Note that filters behave differently, even though they too are placed in the View Menu. Filtering works like a drill down, hence the Close button gets replaced by a Back button, for example, switching between Messaging accounts.

Tab Bar

This template is for quick access between distinct areas or modes. Be careful about mixing actions (like “Create New Message”) with navigational links in the Tab Bar. Use buttons within the content area for actions, if necessary, in this layout. This model is limited to maximum 4 navigation options. Navigational options in an application should not change over time.