Mobile User Interface Design Patterns
The author begins by describing the notion of a pattern library - a collection of techniques that can be used in a given medium that provide for a consistent user experience. A pattern will indicate the way in which an application collects or displays information to the user, such that there is internal consistency - an error message always looks a certain way, the user is always expected to enter an address in a certain way, etc.
USER INTERFACE PATTERNS
Ideally, a user interface pattern documents an sound method for doing something - one that is based on sound design principles and has been tested in practice and found to be effective, in that it guides the user to perform an action in an accurate manner that is easy for them to do.
The author asserts that patterns are generally identified and documented by design experts, for use by less experienced designers - in essence, they are pre-fabricated building blocks for a user interface. (EN: I wouldn't entirely disagree, but sense that this might lead to the notion that patterns are like training wheels - for beginners only, not needed by experts. I prefer to compare UI patterns to the "style book" that is used even by expert designers when they are working on a large project, to make sure they document their choices so they can be consistent with them later, and so that multiple designers can refer to a common set of decisions.)
The author defines three different kinds of patterns: patterns of practice (based on experience and testing), design patterns (based on design principles and ideas but not necessarily tested out), and corporate patterns (coordinate the design pattern with back-end code libraries).
It is of particular importance that design patterns are device-specific. While design consistency between different channels (web application versus mobile application) and platforms (the application for iPhone versus the on for Android) is of some importance, that importance is largely overstated: it is more important to accommodate the user behaviors in rather than to ensure that they are in rigorous lock-step in spite of the differences in the ways that the user interacts with them.
There are often similarities among channels and devices. An error message ahs a slightly different visual appearance on a windows PC, versus a Macintosh, versus an iPhone, versus an Android phone. But in all instances, there is generally the use of the color red, an icon, a brief instructive message, and a way to dismiss the message. And they are generally arranged about the same way on the screen.
But there are also distinct difference: Amazon-style "tabs" are popular on the Web but largely useless on mobile. Horizontal scrolling is verboten on the desktop, but is a common and useful practice on the iPhone. Few users avail themselves of the scroll-wheel on their mouse, but will rely heavily upon it for a device that provides one.
The author considers the hierarchy of navigation - the method by which a user navigates from a "home" page to a section, to a subsection, to a sub-subsection, to an individual page, and asserts that "there is no one correct hierarchy" for all purposes. However, when designing for mobile, the hierarchy does not begin with the top page of an application, but with the default screen of the device - and a designer would do well to consider what the user must do to launch their application in the context of a given device.
A complete "pattern library" contains a compilation of the various patterns n use across a given application (such as a Web site) to ensure consistency. It can take considerable effort to assemble and maintain a library of patterns, but the costs of doing so are offset by the labor saved when it is used by designers. Largely, however, a pattern library provides quality control, ensuring that the user experience is consistent, familiar, and based on tested principles: when a problem arises and a solution is found, the update to the library enables all future projects to inherit that knowledge.
Aside of the designers, the development team generally benefits from a pattern library in the ability to pick up ready-to-use GUI code, and associate this code to their own libraries of functional code. This accelerates development time and generally reduces the number of errors that will be identified in testing.
The author's suggestion for a pattern includes four components:
- Design - a visual representation of the design, along with a link to the ode that renders the design
- Applicability - A list of the devices and platforms to which the pattern should be applied.
- When Used - A clear statement of the use of the design (as the design alone will not be self-evident)
- Rationale - Documentation of the supporting logic behind the design decision. This may be a discussion of design principles or less subjective evidence such as the results of usability testing or problem reports.
SCREEN DESIGN
The author provides a number of suggestions for screen design: elements that work well in general in the mobile medium. My sense is that these are examples of patterns rather than a comprehensive list of all screen design choices, as it seems very light and the order is quite random.
List-based layout is useful as it is a familiar navigation paradigm to users from other media, such as Web sites and even books. They are generally easy to navigate (scroll and select) and are well-suited to the small size of the mobile screen, even when a list is too long to be displayed on a single non-scrolling screen.
Table-based layout is fairly common, and goes back to the earliest PDA devices. It enables the designer to place items on a predictable grid, and a relationship can be connoted between the items that are placed in the same vertical column or horizontal row. Because the size of the screen is small, a table can be two or three columns wide at most, which is small enough in number that the user can generally remember the column identifiers even when they are scrolled off the screen.
When requesting the user to provide locations, leverage the address book on the device or information the user has provided before to enable them, when possible, simply to select a radio button rather than having to enter the entire address. Make use of GPS when possible. Where an address must be entered, allow the user to save it by a nickname for ease of future reference, but do not make this mandatory.
When returning a list of results, as from a search, pagination is often preferable to scrolling due to the amount of time it takes to download data and render a table on a mobile device. The author suggests that a list can scroll for two or three screens, but beyond that, pagination becomes necessary.
When providing menus of options, it is more important for the user to be able to see all options before making a selection, so limit the menu to a single screen, or a few screens with scrolling. The author (arbitrarily) suggests that "about fifteen" should be the maximum - btu a "more" or "other" can be provided. Also, consider applying "hot keys" so that the user can click a number rather than having to scroll through the menu to reach a desired option. When predictable, put the options that the user is most likely to choose at the top of the list to reduce the need to scroll.
Tabs are not effective for most mobile devices, due to the lack of width and the problem of having to scroll back to the top of the page to select a different tab. That said, if the amount of information and number of options are fairly small, tabs may be effective, particularly on a touch-screen device.
Breadcrumb links, a popular mechanism for getting back to a previous page or the menus "above" a given page, can also be awkward on mobile because the user must scroll through the breadcrumb trail when he arrives at each page. They should be used only in instances when they are meaningful to the user - i.e., when it is likely the user will want to navigate back up the "tree" - which is less often than one might assume. They are likewise less awkward on a touch-screen device..
APPLICATION NAVIGATION
The author provides another brain-dump of suggestions for designing the navigation systems in the context of an application. She notes that this is "the first place where developers from the desktop world get into trouble."
To facilitate navigation through items in a list or steps in a task, the user should be given affordances to return to the list, but also to navigate to the next or previous items without returning to the list. The method for doing so will differ by the type of device: the user may be presented buttons to click, a menu to select with a scroll-wheel, hotspots to touch, back and next keyboard shortcuts or soft keys, or the ability to "sweep" on a touch screen. (EN: I think this makes it obvious that a single convention is not applicable to all devices for navigation.
When it comes to building games for the mobile interface, the structure of a game can vary greatly, but the navigation structures within it should not. In most instances, there is a main menu with the ability to start a new game, see options, view scores, read instructions, or quit. Within the game, there is a method to pause. When the game is paused, a menu is provided to continue, see options, start a new game, view instructions, or exit. These are fairly standard across a wide variety of games.
When items are listed alphabetically, users with a keypad should be able to enter a letter to jump to the appropriate place in the list. If the user has a keypad only, they may need to do this in a modal window (as getting to "H" requires hitting the 4 key twice). If the user has a stylus or touch-screen, you may need to give them a list of the letters of the alphabet to click. Scrolling or up/down arrows may also be used to jump to a specific letter if a function key is pressed. If he list is long, it may be necessary to use pagination.
(EN: I'm cutting this section short, as it's becoming repetitive. They main message is that the standards for interaction depends on the input devices - a numeric keypad, a chicklet keyboard, a click-wheel, a stylus, or a touch-screen all have different methods of navigation that will need different design affordances.)
APPLICATION MANAGEMENT
An often-overlooked aspect of development for mobile includes various tasks related to obtaining, installing, and managing the application itself. Another quick romp through various topics follows:
The method by which an application is acquired (downloaded) for the devices is a critical touch point that is seldom considered. A bad experience in this process may discourage the user from installing your application at all. An application developer may have little input into the matter, especially if the application is obtained from the device provider or a third-party store, and some device manufactures may lock out certain delivery channels (e.g., to force the user to download only from an authorized source).
Application state management is also significant, particularly in a channel where the user may be disturbed or disconnected at any time, preserving data until a task is completed, even if there is a disconnection or application crash (the user resumes the task where they left off).
"The simple act of launching an application is often mishandled" and is critical because in the mobile channel, an immediate delay could result in abandonment. The suthor suggests a number of practices for software developers (check license status when needed, make the code modular, etc.), but the net effect is to make sure the user has immediate visual feedback to indicate the application has been launched, and as short a path as possible to the point where he can begin performing the desired task.
The use of cookies is more common on mobile, and is an excellent method for storing data locally where it can be accessed quickly. Unfortunately, support for cookies varies across devices and carriers. That aside, it is recommended to leverage cookies heavily to be able to perform actions on the device rather than a constant stream of network communications for small amounts of data.
ADVERTISING
Advertising is difficult to manage when dealing with a medium where there is a limited amount of visual space and the user is seeking a quick way to do a simple task, and is generally hostile to the notion of unsolicited commercial messages. However, some studios are experimenting with the advertising model, including a "sponsored" application or site, and many companies can't resist the urge to "sell" at every opportunity, so it will need to be accommodated.
One common method is interstitial advertising - the user is shown a full-screen advertisement while "waiting" for something to happen (EN: It's worth mentioning that this immediately draws suspicion as to whether the wait is necessary, or intentional). They have been found to be good for broadcasting a message, but not very effective for soliciting immediate action, as the user is in the middle of a task an is highly unlikely to click anything that will interrupt their work - which is even more true of a medium where the task must be aborted because a second window cannot be opened.
If the expectation is set that content is sponsored by advertisers, users have better tolerance for interstitial advertising, though it must be used sparingly. An advertisement that interrupts the user once is mildly annoying, but if advertisements display repeatedly (read a paragraph, see an ad, another paragraph, another ad) are inadvisable" the user may abandon and uninstall the application, and form a strong negative opinion of the advertiser.
The author lists several of the places where interstitial ads could be placed, but it's fairly obvious: any instance in which the user leaves one screen to go to another (including before the initial screen) is an "opportunity" for advertising.
In-context advertising is also possible on devices with larger screens. These advertisements are termed "fisheye" adverts because of their appearance (rounded corners, the information appearing in the middle and surrounded by white space). Such ads are generally separated from content by a box with rounded corners and a different background color, and contain very little text (a few lines of text, maybe 50 characters at the very most). Graphics are rare due to very limited bandwidth and the short amount of time the user spends on the screen (the image would not load before the user has clicked away).
The author also describes a "mobile banner ad" as being something different from an in-context ad - but my sense is that it differs only in terms of its placement: if it's above or below all other content, it's a banner. If it's in the middle of content, it's an in-context. The primary concern is that users who are regularly subjected to advertisements in predictable locations become trained to ignore any content in those locations that is the rough size and shape of an ad - i.e., they have "banner blindness."