Recent Blog Posts

It's not that I don't like pretty colors, but they certainly aren't my first consideration. This isn't unique to the mobile industry ... many car salesmen ask a potential woman purchaser first what her favorite color is. And I'm sure that there are women for whom this is a key decision making criterion. But let's face it: some men are just as enamored with image, but in a different direction. Motorola has been in tune with the male "fashion" sensibilities for its entire existence.

While pretty leaves or purple lights or other surface features may be attractive, anybody who knows me knows just how much I worry about my clothes.

So what do I want in a mobile?

1. The basics: good radio, good network, good battery life.

2. A reasonably sized device that will not call Australia when swimming around in a purse or pocket (candy bar phones are not great).

3. Good tactile response: I should not have to look at the thing to make a voice call. It should be readily orientable without looking at it (RAZR fails). It should feel sturdy.

4. A feature set that allows me access to my business stuff (email, documents, bookmarks) while allowing access to my personal life (camera and picture messaging, audiobooks and sometimes music). A good web browser and good application environment.

5. Actual sturdiness: it should survive a drop when I get out of the car after too much distraction from children. My baby should be able to chew it and have it survive unscathed (the baby, too).

6. Interaction with my life. The shared browser bookmarks, shared contacts, and so forth. Oh - and I use a Mac, so I want it all to work there as well.

7. If I can get all of the above, I'd like a little bit of physical personalization. Maybe cases that match different outfits, maybe some appliqué, maybe interchangable cases. But not pink - I wear that maybe once a month?

This isn't impossible; I'm investigating a few Nokias. But don't tell me that disco lights and flower stencils make it a "women's phone". Maybe a girl's phone? It's got the whole Hello Kitty mentality.

This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. This second set of patterns will address screen design for mobile applications.

Many devices and applications have a launch screen, with two or three columns of icons, from which major components can be started. Stylus devices in particular have these screens as application launchers; Palm has used such a screen for over a decade.

Design

A table-based layout screen is simple, with little need for softkeys or buttons. It should have a title, two or three columns of cleanly designed icons, and a label for each icon underneath it. This design is often repeated across devices and platforms; it is likely that the device currently in your possession has a launch screen with this design as one launch screen option.

On scroll and select devices, place the focus in the center of the layout, not the top. This reduces keypresses necessary to reach any given icon. Do not use this technique if the items do not fit on a single screen. If at all possible, restrict the number of items to those that will fit on a single screen. If necessary and the application users can continue to see icon details, reduce icon size to make this possible. If this is not possible, consider a different design - especially for scroll and select devices.

Avoid using tables as layout on web sites; if a column layout is desired, use CSS.

Applicable Devices and Platforms

The table layout is particularly effective for stylus-driven devices but can be used in very limited amounts in local applications on scroll-and-select devices. Do not use a table to lay out a web page on a scroll and select device.

When Used

Use on launch screens, either for a device or for a frequently used application. Do not use it on a screen with frequently changing options. Consider other designs for a launch screen with more options than can be displayed simultaneously without scrolling, especially for scroll-and-select devices.

Rationale

Caution with using a table layout is based on all the rationale of using a list-based layout, combined with the need for graceful degradation on web pages in browsers that do not work well with tables.

Tables, with icons, are good for presenting more options on the screen and promoting location memory. Users know that the browser option is in the top right corner, so they can quickly tap there. Even scroll-and-select users get some benefit from position memory, but at the expense of complex scrolling control. If the list of options frequently changes, this position memory benefit disappears.

For a set of items that can not fit on a single screen, a table layout introduces extra complexity for a scroll and select device. The user has to manage decision making for each item, left and right cursor movement, up and down cursor movement, and page scrolling. This extra complexity can make the task of activating an item too complex.

This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. This second set of patterns will address screen design for mobile applications.

Mobile devices vary in their screen dimension ratios as well as size. Some have a longer horizontal dimension; others are vertical or close to square. Unless a device is QVGA or larger, the screen orientation is an important organizing principle.

Design

A web page or application screen should be designed vertically, using lists or similar mechanisms. Paragraphs wrap, spilling down the screen. Each link should be on its own line. Form controls should be on their own line. Occasionally a pair of closely related controls can go on the same line; consider this a variant on the list theme as opposed to a horizontal layout.

Almost all the example screens in this chapter use a list-based layout.

Applicable Devices and Platforms

Any scroll and select device with a small screen taller than wide and is smaller than QVGA (240 × 320 pixels). Most stylus devices are large enough to support two columns.

When Used

Most non-game screens that do not serve as the main screen of an application; almost all web pages.

Rationale

Most mobile phones are oriented vertically, with screens taller than they are wide. Horizontal layout mechanisms, like side bars, tables, and horizontally-oriented control strips at best will look squished on a mobile phone. Additionally, navigating through these mechanisms on a scroll and select device can be confusing and unpredictable and only variably supported by devices.

Now that mobile television has become a major topic, I'd like to re-introduce recommendations for the creation of mobile content.

Producing MultiMedia Content for Mobile Distribution provides most of the technical information for how to produce good mobile content, including capture rates, storyboarding, and other issues. If you're looking to produce for mobile devices, it is definitely worth a read.

Interestingly, end users who generate mobile video on their phone will have a much easier time than will professionals in getting the content right. The phone itself has the same limitations in display as do the target devices - which are also phones. So if it looks right during capture, it will look right during viewing.

I've been keeping an eye out for mashups that go beyond maps. All widgets are okay to include, since moving from desktop to mobile widgets is pretty trivial.

An Apple desktop widget called OnTour provides listings for musical artists who are on tour in or near the city the user specifies. They've got the obvious "featured artists" section, but to me the interesting part is the "My Artists" section. This takes artists from the user's iTunes collection and puts them up top, with the idea that people might want to see in person musicians they listen to.

So there are three data sources: the concerts database on a server, user entry to specify a city, and the iTunes database on the computer. A map-less, RSS-less mashup.

This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. The first set of patterns will address advertising on the mobile.

Mobile banner ads have come, and gone, come again, left again, and now come again. At some point they will stay in the mobile space, but only if done well.

Design

The Mobile Marketing Association has industry standard best practices for banner ads. Be sure to follow those requirements carefully, and expect the practices to evolve over time. Use the "less is more" philosophy to avoid banner blindness in which the user's eye simply does not register banner-appearing content.

In addition to following the MMA guidelines, a banner ad system should, where possible,

• Make the ad content highly contextual, based both on content and other information discernible about the user.
• Ensure that the advertising site is as well designed as the native application.
• Set default focus below the banner ad, so the user does not have to scroll past it.
• Provide a return pointer on the advertising site, so the user can easily return to your application. Note that frames are not readily available in the mobile environment.

Applicable Devices and Platforms

All, especially web sites.