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.

Overall UI Model

Lock Screen
Presented when user first wakes up the device.
Home
Access to open applications through the switcher. Favorite applications are presented, as well as access to launcher.
Launcher
Access to all applications available in the device

Overview of Gestures and Touch Interactions

Symbol	Name	Action	Result
	Tap	(Press, Release)	Open items/Select buttons/links Insert cursor (in text field) Reveal hidden controls Stop kinetic scrolling
	Long press	(Press, Wait)	Reveal Object Menu Repeat (qwerty) key press
	Drag	(Press, Drag, Stop, Release)	Pan/Scroll content Paint to select text in text field (interaction needs to be first started horizontally, otherwise panning is triggered)
	Flick	(Press, Drag, Release)	Kinetic Pan/Scroll content (in some cases, bringing in new content, such as Gallery, switching to next picture)
	Double Tap	(2*Press&Release within time limit)	Switch between zoom levels (touch screen) Silence alert (accelerometer)
	Pinch	(Press, Release)	Zoom in/out (points touched on screen follow fingers)
	Two-finger long Press	(Press, Wait, Release)	Select text (non-editable text fields)

Lock Screen

The lock screen is presented when the user presses the power key to wake the device from idle state.

The screen presents the wallpaper (which the user can personalize), date and time, and the lock action button. The device is unlocked by dragging the lock button into the wallpaper area.

Notifications are also supported in the lock screen. They stack up in a similar way to the Notification Drawer.

Launcher

The launcher is a view that contains links to all applications installed in the device. In the launcher, the user can browse through the applications and add up to 4 links to the quick launch bar at the bottom of the screen. In editing mode, the user can also change the order of application links.

Applications are presented in a 4 x 4 grid. In the case where there are more than 16 applications, more pages of the same grid are added to the right. Paging through the different grids is done by swiping the current grid off screen, hence bringing the new one into view. When the user installs a new application, it goes to the end of the application grid.

The user opens the launcher by selecting an icon at the bottom of the Homescreen (placed together with Favorite Application links). To close, the same icon is used.

All applications require a name and icon for the launcher.

Switcher

Users will often want to (or have to) use more than one application at a time, such as listening to music while writing a message. This is known as multitasking, and the switcher is an area where multiple tasks are managed. The basic behavior of the switcher is as follows:

When an application is first launched, a new task starts. This task is represented in the switcher by a live thumbnail of the current content within the application, that is a blog web page would always display the latest blog entry. The switcher is always accessible via the home button in the top left corner.

Whenever a second application is opened, the new task is included within the switcher. With that, MeeGo allows users to quickly switch between applications by pressing the home button. Applications can be opened from the launcher and from other applications, such as opening a map from an email.

When the user clicks on an application in the launcher, that is already open in the switcher, the system opens the window that was already open. It does not restart the application.

Order of Applications, Browsing, and Changing Modes

Tasks are shown in the order they were opened, from left to right. Every time a new task is opened, it pushes the previous task panels to the left and adds its thumbnail view to the far right.

The default view of the switcher presents the latest accessed task in focus, with the other, different tasks running to the right. Thumbnails are presented in chronological order, as they are opened.

It is possible to browse through the thumbnails, one by one, by slowly dragging them, or to use a quick swipe to rapidly pan from one side of the list to the other. During this quick swipe, a tap stops the transition at tapped point, but does not open the application. To open the application, the user needs to tap the desired thumbnail.

Users can use a pinch multi-touch motion to change the switcher into an overview mode. By pinching in, thumbnails move into a grid display. The grid can scale up to a 3×3 version, thereafter the switcher then starts to create new pages. Pinching out, while in the grid mode, changes the view back to larger stacked mode.

Core Interactions

UI Feedback

Direct feedback refers to the response the user receives when using the touch UI. When there is a change, the user must get feedback. Indirect feedback refers to the response the user receives while, either not using the device, or using it so that the attention is not directed to the UI.

Direct feedback can be haptic, auditory, or visual feedback from interaction with the touch screen or hardware buttons. Indirect feedback is typically in the form of notifications. Notifications may contain both sound and haptics, but they can also be visual only, or contain only visuals and sounds (or in principle also visuals and haptics alone).

When you need to catch the user’s attention, you can use auditory and haptic feedback, in addition to visual feedback. The user’s attention is usually directed away from the device, when the device’s UI is locked and the screen is blank. However, the user’s attention can be elsewhere also, when the UI is in use. A time-consuming operation may cause the user to look elsewhere, or the user’s attention may be on the hardware keyboard, so the events on the screen are easily missed. When feedback is needed almost immediately after the user’s last action (such as when the user tries to send an email without defining a recipient), a visual notification is usually enough, because the user’s attention is already on the device.

In some cases, you can also use auditory and haptic feedback to emphasize the visual message. For example, a confirmation query may have an additional questioning sound to emphasize that the user needs to pay special attention to the device. However, be careful with this kind of use for sounds and haptics, because users find it annoying if the UI requires a lot of attention all the time. You can use sounds alone for presenting events, or sounds combined with visuals, but do not use sounds alone with haptics.

You can use haptic feedback alone when you do not know whether the user’s attention is on the device. For example, when downloading a web page lasts so long that the user’s attention is not likely to be on the device, even though the device is not locked, a subtle tactile pulse can be a useful indicator.

You can use tactile feedback alone, when it is appropriate to confirm the user’s action, but a visual confirmation message is too much. For example, connecting the charger and the device starting to charge (as opposed to not starting, due to a wrong charger type, for example). In this case, haptic feedback can also be used because the user is in physical contact with the charger connector and the device.

Note that the presentation of alerts and notifications depends both on the settings in the active profile and on the current UI state. For example, during a phone call, the auditory part of many alerts is changed (presented as a beep, or the auditory part can be a simplified version of the original, or the sound may be omitted altogether).

Text Input

MeeGo provides support to both virtual and hardware keyboards.

The virtual keyboard is invoked automatically when an input field is in focus (that is when the user taps an input field). The title bar and status disappear to optimize screen real estate. It has a portrait and landscape layout, opening according to the orientation it is being called from. If the user rotates the device, the layout is smoothly changed according to the new orientation.

The user can close the virtual keyboard by either tapping outside the text field or by dragging down the virtual keyboard. Note that the virtual keyboard does not act as a drawer in the sense that the user cannot pull it up. It will come up again once the text field is actioned again.

Whenever the hardware keyboard is opened, the virtual keyboard does not get loaded.

Clearing

Pressing backspace clears a single character. The long press clears characters with key repeat. Long press duration and key repeat rate are the same as with a hardware keyboard. If the user selects the text and hits backspace, the whole selection is cleared. This is script (written language) dependent.

Language

The language is set automatically, based on the UI language that the user selects in the first device startup. This can be changed in Settings.

Confirming

In most cases, applications present confirm buttons as part of their UI. This is true when sending a message or login in a website. Other applications perform actions as the user types. The perfect example is search, which automatically updates the list result with every letter typed.

However, other methods can be used. In a one liner text field, the enter key works as a natural confirmation key (similar to websites and other operating systems). This works when entering a password, for example.

It is also possible to add a confirmation button to the extra line. It is not recommended for UIs like messaging, where an overall view is desired before confirming (tapping outside the text brings the whole UI back), but useful for quicker inputs. This option could be used in a form, with a next action linking to the next text field.

Full Screen Mode

For applications that need to provide a more immersive experience, Full Screen Mode is available. It is important, however, to always provide a way out of the application (and to application navigation when appropriate). Full Screen can be presented in two different ways:

Controls a tap away

All controls (Title Bar, Status, extra controls, etc) are removed, presenting only the maximized content. Controls are made visible by tapping the screen. This is especially useful for media-related experiences.

Fixed controls

Because MeeGo may run in devices with no other hardware navigation keys, it is important to provide a persistent way out of the application. In some cases, it is not possible to use the tap to show the controls (for example, a Flash Player application displaying interaction content). Whenever that happens, a persistent access to exiting the full screen is still mandatory (back or close).

Embedding Exit in Application Content

In a few specific cases, like games, a more immersive experience might be desired, with no chrome. It is only possible to remove the persistent navigation out of the application if an easy to access exit command is available.