Legacy Maemo 5 Documentation/Human Interface Guidelines

(Sliders)
(User Input)
Line 409: Line 409:
''Figure 21: Sliders figure''
''Figure 21: Sliders figure''
-
==User Input==
 
-
There can be several ways to use a Hildon powered device. The user might be able to use the device in a specific orientation - landscape or portrait - using his or her fingers or a stylus.
 
-
These various types of input and usage will influence the way a user interacts with a graphical interface and hence, influence the way to develop that interface.
+
==User Input==
-
This chapter covers those different types of usage advising the interface designer or developer about what can result from choices about widgets placement and introduces concepts to avoid such problems.
+
There are several methods of using and manipulating applications on a Hildon-powered device. First, there are two viewable orientations: landscape and portrait. Second, users can control what is happening on the device with either a finger (or fingers) or by using a stylus. Because of this, developers must carefully weigh the various use-cases and input methods when planning an application.
 +
This section covers these various types of usage in an attempt to advise developers and interface designers how to utilize best practices in order to provide a smooth, intuitive experience for end-users.
===Input Hardware===
===Input Hardware===
-
The input hardware is the hardware that a Hildon device provides the user so he or she can interact with it. Once the user interacts with a component of the input hardware, feedback should be provided by the device.
+
Input Hardware is the hardware that allows users to interact with a Hildon device. When users interact with any component of the Input Hardware, the device should respond with some sort of feedback.
====Hard Keys====
====Hard Keys====
-
The hard keys are the keys in the device that constitute hardware - the ones you can physically touch.
+
Hard Keys are the keys on the device that can be physically touched. The set of Hard Keys available on various devices will vary according to the make and model of the device. These differences must be taken into account when developing a Hildon application. Nonetheless, there are sets of keys that are fairly standard on most hand-held devices.
-
 
+
-
The set of hard keys available in a device surely varies according to the device and that difference must be taken into account when developing a Hildon application. Nonetheless, there are sets of keys that can be found in pretty much any device out there.
+
'''Common Hard Keys'''
'''Common Hard Keys'''
-
* Power: This key is the most common given its basic but vital function.
+
* ''Power Key:'' This key common to most devices, as it is a basic, but vital function.
-
* Lock/Unlock: This is also a common key that will set the device either sensitive or not to the touch. Note that although common there are devices who substitute is by soft keys.
+
* ''Lock/Unlock Key:'' This key can also be found on many devices. It is the key that "locks" and "unlocks" a device for use. Note that although this key is common, some devices handle this function via "soft keys."
-
* Increase/Decrease: Normally these keys are used to adjust the volume of the device sound or the zoom value in an application.
+
* ''Increase/Decrease Key:'' Normally these keys are used to adjust the sound volume of a device, or to zoom in and out of a device's viewable area.
'''Optional Hard Keys'''
'''Optional Hard Keys'''
-
* Capture: Devices that feature such a key use it normally to active a camera and capture an image.
+
* ''Capture Key:'' The "Capture Key," if available is primarily used to take a photo with the device's built-in camera.
-
* Keyboard: Many devices feature a keyboard either always present or a slide-out one. Hildon supports two types of text input - the hardware keyboard and a touch screen text input method. The latter shouldn't be activated when the keyboard is available or slid out.
+
* ''Keyboard:'' Many devices feature a hardware keyboard that is either always present or can be slid or flipped out. Hildon supports two types of text input: hardware keyboard and touch screen text input methods. Touch screen input methods should never be activated if a hardware keyboard is available (i.e., open for use).
===Finger Interaction===
===Finger Interaction===
-
Devices using Hildon can be used with the fingers without the need of a stylus pointer. Also, those devices should be used in either a landscape or portrait orientation. Some devices might also be able to detect the orientation and adapt themselves to that mode.
+
Hildon can be manipulated by users' fingertips, without the need of a stylus pointer. But, as described in the Principles section, keep in mind that using the finger input method may result in obscuring parts of the application. Placing important information in a position that can be hidden by finger/hand interaction is never desirable. Because of this, it is extremely important to choose proper placement of all onscreen widgets. Likewise, try to offer a way to let users choose their preferred widget placement.
-
 
+
-
Like described in the principles section, you must keep in mind that using the fingers to interact with the device will result in covering parts of the application. If the area that is being covered by the user's fingers/hand displays an important message, the user will not be able to see it. Hence, it is of extreme importance to choose a good placement of the widgets as well as to offer ways of letting the user to do it himself or herself.
+
====Two Hand Usage====
====Two Hand Usage====
-
The two hand usage of a device happens when the user is holding the device with both hands and using the fingers to interact with it. In this case, the device will be in landscape mode.
+
Two Hand usage occurs when users hold the device with both hands, using their fingers to interact with the device and/or application. In this case, the application should be designed to work in landscape mode. For example, if both thumbs are required to interact with the device, the obscured area will be greater than if it was a function controlled with just one finger. Because of this, deciding on the placement of onscreen elements becomes bigger challenge for interface designers. Great care must be taken when designing a usable interface where important items are always visible when they need to be.
-
 
+
-
If the user is using for example both thumbs to interact with the device, the area covered by them will be greater than if it was just one finger and hence, constitute a bigger challenge for the interface designer.
+
====Two Hand Usage with Keyboard====
====Two Hand Usage with Keyboard====
-
Special attention is needed to the fact that some devices will also include an external keyboard that may slide-out from them.
+
Some devices will also have hardware keyboards that either slide or flip out. Again, special attention must be paid to how users will interact with onscreen elements, as well as the physical keyboard.
-
In this case, the user keeps in the two hand mode but it might be difficult to reach for areas in the device screen as easily as if the keyboard wasn't out. So, take special attention to widgets that request interaction and placed on the top of the screen if the keyboard is out as they will require extra effort from the user.
+
In some cases, certain onscreen elements items may be hard to reach if a physical keyboard is present. Specifically, any widget placed at the top-most area of the screen can be difficult to reach while users are holding a device when the keyboard is slid out.
====One Hand Usage====
====One Hand Usage====
-
When the user is using only one hand to hold and interact with the device, the device must be in portrait mode as it will not be easy to use in the landscape orientation.
+
If you are planning an application that can be used with only one hand, consider making it run in portrait mode. This is because devices are typically easier to hold with one hand when positioned vertically (i.e., holding a device that is positioned in landscape mode with one hand can be very difficult). Remember that creating static designs (e.g., elements that fit only in one orientation) is not a best practice. Take care to design interfaces that can adapt easily to both horizontal and vertical orientations, as one cannot anticipate various users' preferences.
-
 
+
-
The horizontal size of the screen will be less than the vertical size and the applications should adapt themselves to it. The usage of fixed sizes or static placements will difficult that adaption.
+
====Soft Keys and Touch Types====
====Soft Keys and Touch Types====
-
The interaction in a Hildon device is made mainly by touching the screen so, there are different types of taps that are supported.
+
Hildon, like other touch-screen frameworks, can accommodate a variety of different types of taps.
'''Single Tap'''
'''Single Tap'''
-
All interactive elements like controls, buttons, links, etc. can be activated by tapping and releasing on top of the element's control area.
+
Any interactive elements like controls, buttons, links, et cetera, can be activated by tapping and releasing on top of the element's control area. The process of performing a Single-Tap is divided into three separate states. The following list describes those states and what users can accomplish with Single-Taps.
-
The process of doing a single tap is divided in states. The following list describes those states for a better understanding of what a user can do with a single tap.
+
* ''Tap down:'' Once users touch the screen, a visual effect might be produced in the tapped element. For example, it can highlight a button or make a scroll indicator visible.
 +
* ''Tap release:'' This state occurs when users lift up their finger after a tap down. This will activate the element that was tapped, such as a button or task launcher.
 +
* ''Tap and cancel:'' If a fixed position element (such as a button) is tapped, but loses its focus (e.g., a user slides their finger out of the element's area), it will not activate that element.
-
* Tap down: Once the user touches the screen, a visual effect might be produced in the element he or she is touching. For example, it highlights a button or makes the scroll indicator visible.
 
-
* Tap release: This state happens when the user lifts up his or her finger after a tap down. This will activate the element that was tapped such as a button or task launcher.
 
-
* Tap and cancel: If the user taps down on a fixed position element (such as button) and then moves his or her finger out of the element's area, it will not activate that element.
 
-
'''Long tap'''
+
'''Two-Touch'''
-
Whenever a user taps and keeps the finger down for a longer time than what's usual, it will produce a long tap.
+
Two-Touch occurs when users tap an onscreen element and, without lifting their initial tapping finger, touch the screen with another finger. The Two-Touch can be used to activate element-specific context sensitive menus (similar to right-clicking an application icon in a traditional desktop scenario).
-
Long taps should be used only as a shortcut to a function that could be accessed in another way. Typically, a long tap will be used to bring out a context-sensitive menu in a list of items. For example, the user can long tap a contact in the contacts list to bring out a menu with options.
+
 
 +
'''Long-Tap'''
 +
 
 +
Whenever a user taps and element, but keeps their finger pressed down, it produces a "Long-Tap." Long-Taps should only be used as a shortcut method of accessing a function that can otherwise be accessed another way. For instance, users can Long-Tap a contact in the Contact List to trigger a menu with additional options.
===Stylus Interaction===
===Stylus Interaction===
-
Although Hildon widgets aim at being used by fingers, the stylus can obviously still be used when it is part of the hardware. However, its usage is only advisable for tasks that require a bigger precision such as browsing the web (most websites are designed to be used by a mouse), imaging applications like a drawing application and applications that need too many widgets to be shown at the same time (leaving no space for fingers).
+
Even though Hildon widgets are designed for finger use, certain devices may still include a stylus. However, designing stylus usage into an application is inadvisable unless a specific task requires extremely high precision: clicking links within a website (typically, websites are designed to be navigated via a small mouse cursor), imaging applications that features drawing or painting operations, and applications that require more widgets than can be viewed at one time (leaving no space for fingers).  
===Dimensions===
===Dimensions===
-
A button that is meant to be clicked by a mouse or a stylus is not usually easily pressed with a finger because of the small size. Apart from the size, the placement of a widget right next to another will require more precision and hence make them difficult to be pressed by fingers.
+
Buttons that are designed to be clicked by a mouse or a stylus are not always very easy to be pressed by a finger or thumb because of their smaller sizes. The placement of widgets can also impact usability when considering finger usage (e.g., buttons that are placed right next each other require higher precision and may make them difficult to be pressed by fingers).
-
 
+
-
The horizontal size of the screen will be less than the vertical size and the applications should adapt themselves to it. The usage of fixed sizes or static placements will difficult that adaption.
+
-
The Hildon API provides defined values to make it easy to set the size of controls in a relative way
+
As discussed earlier, applications should be designed so that they adapt to the orientation of the screen. Using fixed sizes or static placement will make such adaptation very difficult.
-
Hildon control size types are:
+
The Hildon API provides several defined values in order to make creating variable control sizes easier:
-
HILDON_SIZE_AUTO_WIDTH              /*Automatic width*/ <br>
+
'''Hildon control size types'''
-
HILDON_SIZE_HALFSCREEN_WIDTH  /*Half of the screen width*/<br>
+
-
HILDON_SIZE_FINGER_HEIGHT  /*A finger height*/<br>
+
-
HILDON_SIZE_THUMB_HEIGHT  /*A thumb height*/<br>
+
-
HILDON_SIZE_AUTO    /*Automatic height and width*/<br>
+
 +
*''HILDON_SIZE_AUTO_WIDTH''  Automatic width
 +
*''HILDON_SIZE_HALFSCREEN_WIDTH'' Half of the screen width
 +
*''HILDON_SIZE_FINGER_HEIGHT'' A finger height
 +
*''HILDON_SIZE_THUMB_HEIGHT'' A thumb height
 +
*''HILDON_SIZE_AUTO'' Automatic height and width
-
You should use the size variables above when you need to choose a size for a widget that will require the user's control according to the way you want the user to use it. For example, if you place a button on a bottom corner of the screen, it is likely that that the user will use his thumbs to press the button, hence you should choose the HILDON_SIZE_THUMB_HEIGHT for it.
+
Use the variable sizes above when choosing the size of widgets based on certain use-cases. For example, if you place a button on a bottom corner of the screen, it is likely that that users will use their thumbs to press it. In this case, choose ''HILDON_SIZE_THUMB_HEIGHT'' for this button.
===Interaction Actions===
===Interaction Actions===
-
A Hildon powered device provides different types of actions that can be done. Some of those actions are equal to what would be done in a computer while others are rather different or innovative.
+
While many of the actions that can be performed with a Hildon-based device are similar to those found within a traditional desktop environment, several additional methods of interacting within Hildon are rather unique. The following sections describe these actions or interactions.
The following sections describe these actions or interactions.
The following sections describe these actions or interactions.
====Copy, paste, cut====
====Copy, paste, cut====
-
The text input fields support the common actions of copying, pasting or cutting. For that, the user can use the hardware keyboard (if available) shortcuts Ctrl+c, Ctrl+v, Ctrl+x, respectively.
+
The text input fields support the common actions of copying, pasting, and cutting. To perform these actions, users can use the standard hardware keyboard (if available) shortcuts Ctrl+c, Ctrl+v, and Ctrl+x, respectively.
====Panning====
====Panning====
-
Hildon discourages the use of scrollbars on interfaces intended to be used with fingers. The concept of panning refers to navigate through content on screen by dragging on top of the contents. When the user enters elements that hold content that cannot be fully viewed within the screen area, a scroll indicator should appear on the right and bottom sides of the screen and the user can drag on top of that area to navigate through the contents.
+
The use of scrollbars within Hildon is discouraged, as the interface is intended to be manipulated with fingers. The concept of Panning refers to navigation of onscreen content by tapping and ''dragging'' a finger over the content. When users enter a view that contains content that cannot be fully viewed within the physical screen area, scroll indicators will appear on the right and bottom sides of the screen. These indicators tell users that the content can be Panned in order to navigate through the content.
==Icons==
==Icons==

Revision as of 19:32, 13 July 2009

Contents

Hildon Human Interface Guidelines

Introduction

This topic presents a series of guidelines to help you create Hildon applications that provide a good user experience. The principles and advices covered here are intended to help interface designers, software developers and graphic artists to create well-designed and intuitive tools fully adapted to mobile devices, considering their capabilities and limitations.

Following these guidelines, your work will result in an application which is attractive and simple to use. Also, you can expect that:

  • Users will learn to use your application faster, because interface elements will look and behave the way they are used to.
  • Novice and advanced users will be able accomplish tasks quickly and easily, because the interface won't be confusing or make things difficult.
  • Your application will continue to look good when users change color themes, fonts and languages.
  • Your application will be designed with usability in mind, specially adapted to mobile devices with a limited screen and input methods.

To help you achieve these goals, these guidelines will cover the basic interface elements, how to use them together effectively, and how to integrate well with the specificities of mobile devices.

Since the GNOME plaform forms the basis of Hildon, this document is based on the GNOME Human Interface Guidelines. They have been adapted for developing software for a mobile platform. Some sections of the GNOME HIG will be referenced and linked directly, since they are particularly relevant. We also recommend readong the GNOME HIG entirely, as it contains a lot of generally useful interface design advice.

Usability Principles

This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. Although the Principles Section of GNOME HIG is not directly related to mobile applications, it is a very useful reference, and the reader should be familiar with it as well.


Diversity

Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, etc. Other devices might not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, don't use a mouse icon with a button highlighted to suggest a user "click". Also, avoid messages that mention specific hardware features, such as "Use the menu button to..." (unless referring to a graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.


Size Matters

Screen size

A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Interacting with an application on the small screen of a mobile device is a very different experience than working with a standard computer screen.

Remember that mobile device screens are not only small, but they vary widely in size and dimensions. Do not assume that your user's device will have the same size screen as the one you are using. Some devices may have a landscape display while others will have a portrait display. Some may even be able to change the display orientation. Mobile applications must be able to adapt to all these displays. Fixed-sized application widgets should be avoided. For example, instead of defining a fixed size for a button, let Hildon adapt that button to the label and screen layout.

Widget size

Hildon is designed for touch interfaces. If you wish your application to be finger-friendly, be aware of the size of the widgets with which the user will interact. Small touch areas, such as small buttons, are difficult and frustrating to use.


Using Fingers

Since Hildon was designed to be a finger-centric interface, consideration of the end-user must be used when deciding on the placement of widgets within applications. For example, imagine an application that is divided into two columns: the left column for displaying information and the right column for various control widgets. In this case, a left-handed user may be forced to obscure part of the display area with their fingers when touching the control widgets with their left hand. Because of this, it is good practice to allow the user choose their preferred column positions.


Device Orientation

Hildon is optimized for full functionality in the landscape screen orientation. Although both orientations are supported, framework level functionalities such as the status bar, back/close, are not available on the portrait mode.

The switch between orientation modes can be done by the Hildon framework transparently for the application developer. The only relevant decisions for application developers are whether to request the portrait orientation mode and which interface elements to use on it.

The portrait mode is intended for simplified, one-handed use and functionality may, and should, be limited in this orientation. For example, a Now Playing message for a media application, a read view for a PDF reading application, or simplified call handle controls.

System notifications, error messages and progress indicators are only displayed in the landscape orientation. In portrait orientation mode, only incoming calls notifications are displayed on the screen; other notifications are indicated by sound, vibration, or LED.


Windows

The construction, organization, and behaviour of windows within Hildon are quite different than those found in traditional desktop applications. For example, users cannot drag or move windows in Hildon.

This section covers some of these differences by describing the properties and organization of certain types of windows (e.g., wizard dialogs).

Window Views

In Hildon, the concept of window organization is very important to developing a highly usable application. In a traditional desktop application, it is normal that a function in one window might bring up another window -- which can then bring up a third one, etc. In Hildon, a new concept called "window views" is introduced. Windows views just means that there is a stack of windows, users only seeing the top-most window. Application can have several window views describing various tasks. Window views can be broken down into "root view" (the application's main window, figure1), on top of which "sub views" (figure 2) are created (e.g., writing or forwarding an email, choosing from a list of contacts, searching emails, etc.).


Figure 1: A root window Image rootview


Many activities in an application should be presented and performed in subviews. After interacting with sub views, users can press the back button to return to the root view.

Figure 2: A sub view Image subview


Because of this new methodology, "split" or "tree" views should never be used. Instead, each area that might have been split, should be moved to a new sub view in the window stack. As an example, consider an email application. The root view would present the user with a list of options he can choose like "Inbox," "Outbox," "Drafts," etc. If the user chooses "Inbox," a new sub view window is displayed with a list of messages in the user's Inbox. Clicking on a message from the list would then bring in a new sub view window containing the message content.

Always provide the user with the proper navigation in order to move between the open window views within the stack.

Note that it is important to choose when an action on an element in a window of a stack will either initialize a new sub view or a full independent window. Normally, new tasks that interrupt the typical flow of actions are likely to require a new independent window and not a new sub view. For example, when browsing a to do list, the action of creating a new to do item should be an individual window and not a sub view.

Properties of Windows

Titles

Every window should have a title. Although, given the small screen dimensions, a window title should neither be long nor contain unnecessary information. For example, do not include the program's version number in the title text.

Since only one window is shown at a time, it is quite easy for users to identify which application a visible window belongs to. Because of this, repeating an application's name in every window title is not required. In fact, doing so could even make the user's experience more complicated than it needs to be.

Sizes

When applications are in normal mode (not in full-screen mode), its main window should always occupy the maximum allowable size (i.e., the same size as the desktop, minus the top of the screen, where framework-specific information is displayed).

Window Modes

An application's window can either be displayed in normal or full-screen mode depending on application type and availability of modes.


Notes and Banners

Notes or Banners should be used when it is necessary to present users with application-specific information or to ask for some kind of confirmation.

Because these widgets interrupt the natural flow of most application interactions, they should be used sparingly and only when crucial to a specific function of the application.

While banners do not require any user interaction in order to be dismissed, notes always need one.

Information Notes

Information notes are modal dialogs that display information, but have no buttons -- simply pressing anywhere on the screen will make the note disappear.

Figure 3: An information note


This kind of a note should only be used when immediate attention is required (information that users must read). For example, if an application is performing an important task that requires user input in order to complete the task.

Information Notes should only be used when necessary, as there are other, less obtrusive ways to interact with users.

Confirmation Notes

Confirmation Notes are modal dialogs with two or more options available to the user. Confirmation Notes can be viewed as the Hildon equivalent to GTK's alert dialogs.

Figure 4: An confirmation note


These notes should be used when the application is about to perform a task that might lead to an unintended action like destroying data, compromising security, or requiring inordinate processing time. Unlike Information Notes, Confirmation Notes only disappear after a user's response, that is, they won't go away until the user presses one of the note's buttons.

Use Confirmation Notes in moderation and consider making their frequency user-configurable in the application's Preferences dialog (i.e., allow users to turn off features like confirming to quit the application, etc).

Note Buttons

In most cases, Confirmation Notes should only ask "Yes" or "No" questions where the text on the buttons is "Yes" and "No." Also, assure that button ordering is consistent across your application. Don't set the "Yes" button as the first button in one Confirmation Note but as the second button in other notes.

Banner

Banners are used to display information for a specified duration. This type of notification should be used to display non-critical information (that a certain task is complete, or that an application state has changed, etc.).

The period of time that a banner will stay onscreen can be adjusted. However, the duration should not be excessive, as it is an intrusive method for displaying information.

Figure 5: An banner Image banner

Banners should be distinguished from the system's own banners, that is, they should suggest to the user which application they belong to. This can be done by displaying the application's name or by making it clear in the message's text.

Dialogs

Although derived from GtkDialog, Hildon dialogs behave differently than in a traditional desktop environment. To make them more usable, dialogs are placed at the bottom of the screen, with their buttons on the right side. Dialogs can be closed by pressing on the dimmed desktop background outside of the dialog itself.

The number of dialog buttons should be kept to a minimum. Dialogs should not have a "close" or "cancel" button, since that task is accomplished by pressing the dimmed area outside of the dialog.

Dialogs should be used for quick tasks. For example, a dialog is appropriate for asking for a category name when creating a new category in an email application. In this example, there should be a Text Entry Field for users to enter the category name and a single button, "Create."

Figure 6: A dialog


For other tasks such as browsing through email messages, deleting or editing them, or managing an email account folder, a sub view should be used instead of a dialog.


Wizard Dialogs

A Wizard is a dialog that divides a task into sequential steps. With this special-case dialog, a complex operation can be presented more simply to users. Therefore, do not use a Wizard unless you are sure it will simplify an action for the user. For example, in a situation where users must set a simple preference, a normal dialog should be enough. But, if users must complete a number of settings which are dependent on sequential input before the application will function properly, then the use of a Wizard is appropriate.

The first page of a Wizard is a "welcome page." Its title should be the Wizard's name followed by, "Welcome." Similarly, the title of the Wizard's last page is a the Wizard's name combined with, "Finished." The titles of intermediate pages should be a combination of the Wizard's name and the action to be completed on the page. The page's action is set in the Wizard's assigned Notebook.

File:Wizard.png

Figure 7: An wizard dialog


Wizard dialogs contain three buttons: Finish, Previous, and Next. These buttons are automatically dimmed or undimmed according to the current page of the Wizard.

Since the first page is the welcome page, it should not require any user input, other than navigation buttons. Instead the page should tell the user what the Wizard is for. This information should describe what to expect from the Wizard, the steps that will follow, as well as what will happen once the Wizard is complete. The last page should summarise important choices made by the user as well as describe what will happen when the "Finish" button is pressed. Avoid asking for important choices on the last page of a Wizard (although simple choices, such as showing a README file, may be included). All important choices to be made, including data that users are required to enter, should be requested on the intermediate pages of the Wizard. Likewise, always explain (via labels and captions) the reason for the requested information or choices.


View Menu

The View Menu does not have a traditional menu bar like desktop application menus have. The View Menu is activated when the user presses the application's title area.

The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and there are no sub menus.

Figure 8: A view menu


Menu items that perform similar actions (e.g., "Previous" and "Next") should be placed side by side within a View Menu. Also, the most important menu items should be placed on the top of the view.

Actions that are available from other locations within the application (either in the onscreen interface or via a hardware key) should not be repeated in a menu view.

The View Menu should will differ depending on the current view in the application. For example, if a user is viewing 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 there are actions that belong in the sub menu of a desktop application, consider creating a new sub view that will contain the commands that won't fit in the View Menu. Think of a text application that should have a "Format" menu with several sub menus: "Comment Lines," "Remove Lines," "Duplicate Lines," etc. While these sub menus are not supported by a Hildon View Menu, a new sub view can be created that will hold buttons to perform the actions intended to be sub menus of the "Format" menu item. The Format sub view will appears when the "Format" menu item is pressed.

Remember, try to keep the number of menu items low -- add only the most useful items. The less menu items, the better. This is important not only because there are a limited number of items allowed within Hildon, but also because it is good practice to limit the amount of menu items a user is forced to navigate through in order to achieve a particular action. Again, if an action can be already performed by some other widget within the application's interface, do not include a menu item for it.

Filters

Along with typical menu items, filters can also be used within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, 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 displayed.

Filters should always be presented in groups. Because of this, there should always be at least two menu filters (e.g., a menu filter that will sort a list of email messages alphabetically and one that will sort them by date -- not just one filter for alphabetical sorting).


Menu Keyboard Shortcuts

Sometimes it makes sense to add keyboard shortcuts to some actions that can also be performed via the View Menu.

If the shortcut will perform a common action like creating something new, formatting the text as bold, or undoing a previous action, take care in utilizing common shortcuts that are generally used in other applications. For example, the previous mentioned actions would be Ctrl+n, Ctrl+b, and Ctrl+z, respectively.


Unavailable Menu Items

Even though it is a common and useful practice to make certain menu items unavailable (i.e., "dimmed") in desktop applications when their actions are not available, Hildon takes a different approach: the menu items should not be visible at all. Although dimmed menu items suggest actions that are unavailable, they can cramp menu space on the small screen and make interaction with available menu items more confusing.

Figure 9: An incorrect view menu


Hildonizing an Interface

Developers often mistakenly design mobile device interfaces like the interfaces for desktop applications. This can compromise the usability of an application. Mobile devices' screens typically have a limited working area and cannot support all the types of widgets used by desktop computer applications.

An application for a mobile device should not be a direct port from one platform to another; the interface needs to be adapted. This document has many examples of this kind of adaptation, but this topic is explored in depth in this section.

The principles covered in this section aid development of applications that are simpler to use and a easier to learn by the user.


Divide and Conquer

In a Hildon application, dividing the content simplifies the interface while keeping full functionality. The limited screen size makes it difficult to place many controls on the screen at the same time. The solution to this problem is to split them up.

For example, an email client application usually has a split view containing, on one side, a tree view with a list of accounts and folders, and on the other side, a list of messages within the currently selected folder. This is too much for a small screen; the solution is to divide the contents. A first view should display the available accounts and allow the user to choose one. After an account is chosen, a new view should display the different folders ("Inbox", "Outbox", "Drafts", etc.). Choosing a folder displays a new view with the list of messages in it.

It is important to be reasonable in this division; things shouldn't be divided to the point that the user needs to navigate through a number of views to do simple or common tasks. For example, in the "Inbox" message list view, the user will probably wish to open a message, delete a message, or create a new one. Hence, a "Create Message" button could be added to the message list view.

Do Not Repeat Yourself

A common use-case within traditional desktop applications is that various tasks are performed via different methods. As an example, email messages in an Inbox may be edited by selecting the message and using the Edit menu from the menu bar, or by using the contextual menu triggered by right-clicking the mouse button, or by using the application's toolbar. Within Hildon, in order to save space, as well as simplify general application usability, these sorts of tasks should never be repeated. If a new email message can be created by pressing a button in an application's root view, it is unnecessary to include a "Create New Message" menu item.


Controls

Using Controls Effectively

Although many GTK widgets are used similarly to how widgets are used within Hildon, some of them widgets require special attention. Likewise, there are several Hildon-specific widgets that are specially designed for mobile devices with touch screens.

Refraining from altering a widget's default behavior is important. Developers should attempt to provide users with a standardized set of tools so that applications are as efficient and intuitive as possible. Controls that behave in atypical ways can destroy a user's mental model of how an application works. Introducing new concepts dilute the meaning of a standardized visual language.

Text Entry Fields

Text Entry Fields are used for entering one or more lines of plain text. "HildonEntry" can be used for a single-line text input and "HildonTextView" can be used for multi-line text input.

Figure 10: Text input widgets Image text_widgets


Guidelines

  • When the user changes focus to a Text Entry Field via the device's keyboard, the existing text must be highlighted, with the cursor placed at the end of the text. This action should not overwrite or delete the existing "primary" clipboard selection. Doing this will make it easier to immediately over-type or append new text to the selection, the two most common operations performed in Text Entry Fields.
  • Try to size Text Entry Fields according to the most likely size of the input. This gives a useful visual cue to the amount of input expected and breaks up the dialog, making it easier to scan. Be diligent in designing the fields according to the expected input -- all of the fields in a dialog don't need to be the same width just because it looks nice.
  • Lastly, validate the contents of each Text Entry Field either when it loses focus or when the window is closed, not after each keypress.

Behavior of Tab key

The behavior of the Tab key in Hildon differs from what one might expect in a traditional desktop application. Since no widgets -- apart from Text Entry Fields and Text Views -- can have focus, the Tab key will only set and/or change focus when those text widgets are present in the interface. Otherwise, by default, the Tab key shouldn't do anything.

Touch Selectors

Touch Selectors are a set of widgets within Hildon that allow users to select one or several items from a list. Consider an application that requires users to select their favorite fruits from a list. A Touch Selector should be used for this task. While there are similar widgets for use with GTK, it is advised that Touch Selectors be used.

Touch Selector Entry

A Touch Selector Entry is a special kind of selector that, apart from the normal Touch Selector functionality, also has a Text Entry Field at the top of the Touch Selector list. This widget can be used in applications where users are asked to provide information that is saved to the Touch Selector Entry list in real-time for future use.

Figure 11: Touch selector entry


A good example of this functionality is an application that asks users to provide a number that occurs within a certain range. The application can list the most common choices, but still allow users to enter additional numbers in the Touch Selector Entry field (which, of course, would need validation afterward).

Picker Button

Picker Buttons are the method in which a Touch Selector is used. When users press a Picker button, the assigned Touch Selector is shown so that various options may be chosen. When an option is chosen, the Picker Button will hold the text returned from the Touch Select Print function as its value.

Generally, any group of options from which users must choose will be presented using a Picker Button.

Figure 12: Picker button Image

Date Selector

Date Selectors are Touch Selectors that provide an easy way for users to pick a date.

Figure 13: Date selector


Guidelines

  • Assign the initial date of the Date Selector appropriately. In other words, if a date is supposed to represent a future event then the initial date should be set to either the current day or the day after. On the other hand, if a birth date is required then the initial date should be set to January 1st of the year previous to the current year.


Date Button

Date Buttons work similarly to Picker Buttons, but should be used instead of the general Touch Selectors.

Figure 14: Date button

Time Selector

As with Date Selectors, Time Selectors are Touch Selectors but they target the selection of time (hour, minute, and second, as well as AM/PM format depending on the 12/24 hour settings).

Figure 15: Time selector


Guidelines

  • As mentioned with Date Selectors, the Time Selector's initial time should be set taking its purpose and context into account. For example, if an application asks for a date and time of a future event, and the date was already entered -- in this case, today's date -- then the Time Selector's initial value should be set to a time later than the current time.

Time Button

Time Buttons launch a Time Selector when pressed, and are the most common method for accessing a Time Selector.

Figure 16: Time button

Toolbars

Whenever possible, the use of regular (i.e., traditional desktop application) Toolbars in a Hildon application should be avoided. Fixed widgets such as these waste too much precious space.

Often times, Toolbars contain controls that will perform the same actions as menu items or buttons. Because of this, developers must consider where else these particular actions can be performed within the application. For example, text editors often use the buttons "New," "Open," and "Save" in their Toolbars. But, these actions already exist within the application's menu.

If certain actions are present within a Toolbar, but are not available anywhere else within an application, consider creating new menu items that are accessible via a sub view. But, if some Toolbar actions are integral to using an application (e.g., email applications rely on the "New Message" action), they should be placed in the application's main contents. In the case of an email application, the "New Message" button should be placed at the top of the application's list of messages.

Unorthodox Use of Toolbars

Although Toolbars should be avoided, there are special cases where they can come handy without compromising an application's usability. For example, in an image editing application where images fill the entire screen, a Toolbar could be used to provide quick access to a number of useful editing tools.

Special Toolbars

Hildon provides special Toolbars that target specific needs: the Find Toolbar and the Edit Toolbar.

Find Toolbar

The Find Toolbar presents user with a familiar way to search for content: a text entry field with a dropdown list that contains any previously entered search terms. Applications should use this Toolbar instead of implementing a custom search interface.

Applications should use this toolbar for search instead of having their own individual search interface.

Edit Toolbar

The Edit Toolbar allows users to perform actions on previously edited items. For example, the Edit Toolbar allows users to delete a selected group of items by choosing Delete from the Edit Toolbar. The Toolbar's buttons should display labels describing exactly what each button will do (e.g., "Delete").

Figure 17: Edit toolbar

Buttons

Hildon allows the use of either classic GTK buttons or Hildon buttons. Hildon buttons have a title and value instead of just a label. The title appears on the top of the button, with the value at the bottom. If using GTK buttons, developers should implement finger-optimized sizes. Hildon buttons, on the other hand, are usually set to "finger" or "thumb" heights.

Figure 18: Buttons


Guidelines

  • Label all buttons with imperative verbs, using "Title Capitalization" (e.g., Save, Sort, Update Now, etc.).
  • After pressing a button, results of the action should occur within 1 second (e.g., closing a window or opening another).
  • Invalid buttons should be disabled. Error messages should not be applicable for buttons that cannot be clicked.

Check Buttons

Check Buttons are very similar to the GTK's Check Boxes, although they appear in the form of buttons rather than boxes. Check Buttons are used to represent two states of a given property (e.g., "on" and "off"). Below are some guidelines taken and adapted from the GNOME HIG's Check Boxes Section.

Figure 19: Check buttons


Guidelines

  • Do not initiate an action when a Check Button is pressed.
  • Pressing a Check Button should not affect the values of any other controls. However, they may enable, disable, hide, or show other controls.
  • If toggling a Check Button affects the functionality of other controls, place the Check Button immediately above, or to the left, of the control(s) that it affects. This helps to indicate that the controls are dependent on the state of the Check Button.
  • Use sentence capitalization for Check Button labels (e.g., Use custom font).
  • Label Check Buttons so that they clearly indicate the effects of both their checked and unchecked states (e.g., Show icons in menus). If the effects of a Check Button are difficult to discern, consider using two Radio Buttons instead so that labels can be given to each state.
  • Label each group of Check Buttons with a descriptive heading above or to the left of the group.
  • Do not place more than four Check Buttons (if each button is finger-height) or three Check Buttons (if each button is thumb-height) under the same group heading. If more Check Buttons are required, consider using a Touch Selector with multiple selection enabled.

Toggle Buttons

Toggle Buttons look similar to regular #Buttons, but are used to show or change a state rather than initiate an action. Toggle Buttons have two states: set and unset. These states are shown by the button appearing "pushed in" or "popped out" respectively.

Toggle Buttons should only be used as filters in a View Menu. Outside the View Menu, Picker Buttons should be used (if not contained in a View Menu, Toggle Buttons can be confusing since they look like regular buttons).

When using multiple Toggle Buttons within a View Menu, they should be grouped. This makes it easier for users to understand that each button represents one out of several available options. Also note that Toggle Buttons are, in fact, GTK buttons. Because of this, they do not support certain Hildon attributes, luke like title and value.

Guidelines

  • Only use Toggle Buttons as filters within a View Menu.
  • Display multiple Toggle Buttons in groups, so they are not mistaken for regular buttons. These groups should either behave like a group of Check Buttons or a group of GTK radio buttons, depending on the need.
  • Use the same text or graphical label for a Toggle Button whether it is set or unset.

Notebooks

The typical use of a tabbed Notebook is not advised in Hildon. Sub views should be used instead. Notebooks should only be used within a Hildon application when assigned to a Wizard.

Progress Indicator

Sometimes, it is necessary to show users that an application is performing a task that requires some wait-time. This is done by assigning a Progress Indicator to the dialog. A Progress Indicator is a non-intrusive spinning icon that is placed in a dialog's title to give an immediate feeling that an operation is being processed.

Figure 20: Progress indicator


Guidelines

  • Avoid the use of traditional progress bars. Instead use the Progress Indicator.
  • When the Progress Indicator is in action on a dialog, the dialog should not display any additional usable content (i.e., all that should be displayed is static informative or no content at all).
  • For operations that could take some time, also consider displaying a banner once the operation begins. Doing this will remind users that the task has started (e.g., "Downloading messages"). This kind of banner should have a standard timeout and should not remain onscreen for the entire duration of the operation.
  • Process updates (i.e., various steps during an operation) should be displayed within banners. Use simple and short descriptions for the steps (e.g., "Authenticating," "Downloading," "Closing connection," rather than, "Authenticating user in the server," "Downloading all messages from server," or, "Shutting down the connection with the server").
  • If some widgets that are present in the dialog are related to each step of a running operation, do not show them after the step. Show all of them after the application is complete.

Sliders

In Hildon, a GtkVScale or GtkHScale will return a vertical or horizontal finger-usable slider, respectively. This widget should follow the same guidelines that are advised in the GNOME HIG, in the Sliders section.

Figure 21: Sliders figure


User Input

There are several methods of using and manipulating applications on a Hildon-powered device. First, there are two viewable orientations: landscape and portrait. Second, users can control what is happening on the device with either a finger (or fingers) or by using a stylus. Because of this, developers must carefully weigh the various use-cases and input methods when planning an application.

This section covers these various types of usage in an attempt to advise developers and interface designers how to utilize best practices in order to provide a smooth, intuitive experience for end-users.

Input Hardware

Input Hardware is the hardware that allows users to interact with a Hildon device. When users interact with any component of the Input Hardware, the device should respond with some sort of feedback.

Hard Keys

Hard Keys are the keys on the device that can be physically touched. The set of Hard Keys available on various devices will vary according to the make and model of the device. These differences must be taken into account when developing a Hildon application. Nonetheless, there are sets of keys that are fairly standard on most hand-held devices.

Common Hard Keys

  • Power Key: This key common to most devices, as it is a basic, but vital function.
  • Lock/Unlock Key: This key can also be found on many devices. It is the key that "locks" and "unlocks" a device for use. Note that although this key is common, some devices handle this function via "soft keys."
  • Increase/Decrease Key: Normally these keys are used to adjust the sound volume of a device, or to zoom in and out of a device's viewable area.

Optional Hard Keys

  • Capture Key: The "Capture Key," if available is primarily used to take a photo with the device's built-in camera.
  • Keyboard: Many devices feature a hardware keyboard that is either always present or can be slid or flipped out. Hildon supports two types of text input: hardware keyboard and touch screen text input methods. Touch screen input methods should never be activated if a hardware keyboard is available (i.e., open for use).


Finger Interaction

Hildon can be manipulated by users' fingertips, without the need of a stylus pointer. But, as described in the Principles section, keep in mind that using the finger input method may result in obscuring parts of the application. Placing important information in a position that can be hidden by finger/hand interaction is never desirable. Because of this, it is extremely important to choose proper placement of all onscreen widgets. Likewise, try to offer a way to let users choose their preferred widget placement.

Two Hand Usage

Two Hand usage occurs when users hold the device with both hands, using their fingers to interact with the device and/or application. In this case, the application should be designed to work in landscape mode. For example, if both thumbs are required to interact with the device, the obscured area will be greater than if it was a function controlled with just one finger. Because of this, deciding on the placement of onscreen elements becomes bigger challenge for interface designers. Great care must be taken when designing a usable interface where important items are always visible when they need to be.

Two Hand Usage with Keyboard

Some devices will also have hardware keyboards that either slide or flip out. Again, special attention must be paid to how users will interact with onscreen elements, as well as the physical keyboard.

In some cases, certain onscreen elements items may be hard to reach if a physical keyboard is present. Specifically, any widget placed at the top-most area of the screen can be difficult to reach while users are holding a device when the keyboard is slid out.

One Hand Usage

If you are planning an application that can be used with only one hand, consider making it run in portrait mode. This is because devices are typically easier to hold with one hand when positioned vertically (i.e., holding a device that is positioned in landscape mode with one hand can be very difficult). Remember that creating static designs (e.g., elements that fit only in one orientation) is not a best practice. Take care to design interfaces that can adapt easily to both horizontal and vertical orientations, as one cannot anticipate various users' preferences.

Soft Keys and Touch Types

Hildon, like other touch-screen frameworks, can accommodate a variety of different types of taps.

Single Tap

Any interactive elements like controls, buttons, links, et cetera, can be activated by tapping and releasing on top of the element's control area. The process of performing a Single-Tap is divided into three separate states. The following list describes those states and what users can accomplish with Single-Taps.

  • Tap down: Once users touch the screen, a visual effect might be produced in the tapped element. For example, it can highlight a button or make a scroll indicator visible.
  • Tap release: This state occurs when users lift up their finger after a tap down. This will activate the element that was tapped, such as a button or task launcher.
  • Tap and cancel: If a fixed position element (such as a button) is tapped, but loses its focus (e.g., a user slides their finger out of the element's area), it will not activate that element.


Two-Touch

Two-Touch occurs when users tap an onscreen element and, without lifting their initial tapping finger, touch the screen with another finger. The Two-Touch can be used to activate element-specific context sensitive menus (similar to right-clicking an application icon in a traditional desktop scenario).


Long-Tap

Whenever a user taps and element, but keeps their finger pressed down, it produces a "Long-Tap." Long-Taps should only be used as a shortcut method of accessing a function that can otherwise be accessed another way. For instance, users can Long-Tap a contact in the Contact List to trigger a menu with additional options.

Stylus Interaction

Even though Hildon widgets are designed for finger use, certain devices may still include a stylus. However, designing stylus usage into an application is inadvisable unless a specific task requires extremely high precision: clicking links within a website (typically, websites are designed to be navigated via a small mouse cursor), imaging applications that features drawing or painting operations, and applications that require more widgets than can be viewed at one time (leaving no space for fingers).


Dimensions

Buttons that are designed to be clicked by a mouse or a stylus are not always very easy to be pressed by a finger or thumb because of their smaller sizes. The placement of widgets can also impact usability when considering finger usage (e.g., buttons that are placed right next each other require higher precision and may make them difficult to be pressed by fingers).

As discussed earlier, applications should be designed so that they adapt to the orientation of the screen. Using fixed sizes or static placement will make such adaptation very difficult.

The Hildon API provides several defined values in order to make creating variable control sizes easier:

Hildon control size types

  • HILDON_SIZE_AUTO_WIDTH Automatic width
  • HILDON_SIZE_HALFSCREEN_WIDTH Half of the screen width
  • HILDON_SIZE_FINGER_HEIGHT A finger height
  • HILDON_SIZE_THUMB_HEIGHT A thumb height
  • HILDON_SIZE_AUTO Automatic height and width


Use the variable sizes above when choosing the size of widgets based on certain use-cases. For example, if you place a button on a bottom corner of the screen, it is likely that that users will use their thumbs to press it. In this case, choose HILDON_SIZE_THUMB_HEIGHT for this button.

Interaction Actions

While many of the actions that can be performed with a Hildon-based device are similar to those found within a traditional desktop environment, several additional methods of interacting within Hildon are rather unique. The following sections describe these actions or interactions.

The following sections describe these actions or interactions.

Copy, paste, cut

The text input fields support the common actions of copying, pasting, and cutting. To perform these actions, users can use the standard hardware keyboard (if available) shortcuts Ctrl+c, Ctrl+v, and Ctrl+x, respectively.

Panning

The use of scrollbars within Hildon is discouraged, as the interface is intended to be manipulated with fingers. The concept of Panning refers to navigation of onscreen content by tapping and dragging a finger over the content. When users enter a view that contains content that cannot be fully viewed within the physical screen area, scroll indicators will appear on the right and bottom sides of the screen. These indicators tell users that the content can be Panned in order to navigate through the content.

Icons

Many applications share similar tasks that can can be represented by a generally known icon. For example, several applications have "Previous", "Next" or "Back", "Forward" actions that can represented by arrow icons. For these kind of actions applications should not ship their own icons, they should use the system icons instead (known as stock icons). An alternative is to ship any desired icons but using the common task ones only when there is no equivalence in the system.

In a device with a touch screen, since there is no mouse, there will be no tooltips, hence choosing an icon when there is no text label in the widget involves an even more important decision than in a desktop computer. If the user doesn't readily understand what's the action assigned to a button with only an icon, he or she will need to read any help document about the application but is likely to press that button in order to check what's its function (which might not result in what the user wants). If an icon doesn't seem clear enough for the task it represents, then don't use it, use a text label instead. Text labels generally give a better explanation to a user. Apart from the mentioned common tasks, the only way where an icon might be preferable to a text label is when there's no space for the text.

For general guidelines on the design of good icons, please read the GNOME HIG Icons section.

Reality Checks

The sections in this chapeter give advices on how to make your application even more usable when it can already be tested. Other very useful checks can be found in the GNOME HIG Checklists Section.

Harware Keys

Check the keys of the mobile device you're testing your application with to see they could be assigned any functions already existing or new functions. This way you might find out that some actions by not need an actual control on screen as they could be assigned to a commonly used hardware key.


Different Devices

Given the plurality of mobile devices out there and their differences, you'll maybe find out that some features of your application do not behave as desired in one device or another. Therefore, it extremely important to be able to either test it in those devices or let those devices users give you feedback about it