Recent Blog Posts

The growing number of lifestyle devices (and MVNOs) have had at best unpredictable success. Why?

Let's define a lifestyle device as a personal communications device that caters to a specific market segment with specific interests. A personal communications device (PCD) is a wireless handheld device with a primary focus on communications, with text, voice, or both. Examples include the BlackBerry, OGO, Treo, and all variety of mobile phones.

What does the ideal lifestyle device look like? First and foremost, it must bow to the requirements dictated by The Carry Principle:

• While some people may want a separate device for a specialized experience for something, like video or music or a camera, many others will want the functionality but not enough to carry a separate device. So they'll want it in the device that they do carry: the personal communications device. As a result, personal communications devices will inherently be multi-purpose.
• Anything that is always carried will be part of your look, your style. Devices will be selected with style in mind. This explains the RAZR and a plethora of devices within the Japanese and Korean markets.
• Because it is a personal device, users will want to have it personalized, as seen with the array of ringtones, wallpapers, and themes available.

So a lifestyle device should be targeted at a lifestyle that is unlikely to purchase a separate device just for the "lifestyle". The NGage was targeted at just the audience who would normally want a separate device for the fully immersed, optimized (gaming) experience. Well, those people use GameBoys or PSPs. It wasn't a great phone and didn't serve the other needs well.

ESPN's sports device is too expensive and TOO focused on sports: most people have interests outside of sports. The device has to remain a general purpose device, or users are forced to use other devices for general purpose things.

"Sports" is too broad a concept. Participant? Live fan? Television fan? The three have wildly different needs, with the live action fan being the most expensive to support. Carriers definitely need to be involved for them, and once that happens you wouldn't want to restrict premium services to just folks with the special phone. Television fans
can be supported with content distribution, alerts, text messaging, and so forth.

So what would work?

How about blogging-focused PCD? You are unlikely to purchase a separate handheld device just to blog. But a PCD with a good keyboard (either QWERTY or Fastap), a good post-writing user interface, built-in connections with common blogging sites and mechanisms, and a superb RSS reader with content on the standby screen? That makes a voice call when you start dialing numbers? And has a camera that can also post to Flickr, personal servers, and blogging sites/applications? That can perhaps record well enough to podcast from the phone? Ah ha.

A diabetic-focused PCD will help the diabetic monitor blood sugar, record relevant food and activity, and coach the user; it can also perform the more common actions of taking pictures, downloading content, etc. Just because a person is diabetic does not mean the person doesn't like sports or music or chatting.

A lifestyle device needs to be a full PCD optimized for specific market segment needs, but retaining the ability to do general purpose PCD functions (however that evolves over the years). It will not replace a separate device for devotees of the experience, as the N-Gage illustrated, camera phones have illustrated, and music phones are likely to illustrate.

Why are mobile applications so hard to use? Because mobile phones are designed by committee, with no focus on the integrated user experience.

Consider my phone, the Sanyo MM-7500 from Sprint. It is a very nice phone, with a good user experience, but only if you understand the application structure. Who designed it?

• Base operating system, including menu structure and softkey paradigm: Sanyo, with significant requirements from Sprint.
• Browser: Access, with some requirements from Sprint.
• Media player: third party vendor, with influence from Sprint.
• OnDemand: Handmark
• PictureMail: Sprint, with significant restrictions from LightSurf
• Themes (uiOne): Sprint and QUALCOMM
• Java runtime (KVM): third party vendor and Sanyo
• Applications and web sites: property owners

It's no wonder they don't all work together!

This mix of responsibilities is actually better than most. Only carriers like Virgin Mobile, Sprint, and NTT DoCoMo invest in controlling the entire user experience; other carriers simply add services without any integration effort. And Sprint does not do particularly well, as written by many bloggers recently, in no small part because Sprint's decisions are frequently dominated by which potential provider makes the best promises. The user experience team is brought in after the supplier relationship and requirements have been finalized.

Device manufacturers are not much better. Decisions are made on cost and speed of implementation, and not full user experience. Some device manufacturers are unaware of softkey mapping. Most device manufacturers provide devices, not user experience. Even the Motorola RAZR is about its industrial design; trying to find the browser requires use of an unlabeled shortcut key - it is not in Verizon's RAZR menu structure at all.

Nokia, along with Palm (in its past) and Apple, control the entire user experience. They control the hardware, the operating system, and the software. In Nokia's case, they ensure that the KVM is the same across devices within a Series, ensuring that a Java application that runs on one will run on the others and commands are mapped consistent with the Nokia Ui. They build their own browser, ensuring that the user experience complements the native user experience.

This dogged management of the entire user experience is frequently recognized only as "good software". It is not. Both Palm and Apple experimented with licensing their operating system to other manufacturers. Apple stopped its experiment almost immediately, but many companies licensed the Palm OS. The user experience on other hardware was different and typically worse: usually it was less integrated and less smooth, even if it did have better features.

Nokia's version of licensing the operating system is slightly different, through the Symbian alliance (dominated by Nokia). A non-Nokia Symbian device does not have the same attention to detail that a Nokia device does. Nokia's decisions are not always the best and most usable, but they do focus on the entire experience not just a component.

Fitt's Law applied to mobile devices has different implications for mobile UI design than it does for desktop design. Let's focus in on the dominant user interface type, the scroll-and-select device. Let's further assume a one-handed device - no QWERTY keyboards.

Hardware Design: What is close and what is far?

The device rests in the user's hand. The thumb can readily reach the number buttons on the phone, although some clamshell designs have a heavy top half, shifting the neutral resting point of the thumb. If we assume the user is using some type of application, one or both thumbs are in ready reach of the navigation buttons.

There are, on most phones, two key regions of buttons: numbers, and navigation (some or many of: softkeys, left/right/up/down, select, back, camera, etc.). Applications with intense number button use will find users with both thumbs hovering over the number buttons. Applications with intense navigation button use will find users with thumbs hovering over navigation buttons.

A mixed mode - number and navigation button use - is fine as long as neither is intense. Use slowed if the user has to do significant movement between regions due to shifting intensities.

Software Design: Optimizing for Speed

On a scroll-and-select device, distance is measured by the number of clicks to accomplish the task. Clicks include scrolling through the screen, pushing a Select button, pushing a softkey, scrolling through a softkey menu, and activating an item in a softkey menu.

Distances are increased when the hardware buttons are far from the user's current thumb position.

As an example, consider a Nokia phone, without a select button, on a standard Options/Back screen. Item X in the menu is highlighted. What actions are closest?

At 1 click, we can go Back (or Cancel, or whatever the right softkey is doing right now) --- or activate any control with a number shortcut.
At 2 clicks, we can select the currently highlighted item (Options -> choose).
At 3 clicks, we can select a neighboring screen menu item or a neighboring Options menu item.
And so forth.

On a phone with completely customizable softkeys, a Back button, and a Select button, what actions are closest? Let's assume that there are several commands available, and all but the most frequent are relegated to a Menu on the right softkey.

At 1 click, we can go Back, select the currently highlighted item, or the most frequently used command (on the left softkey) --- or activate any control with a number shortcut.
At 2 clicks, we can select a neighboring screen menu item or perform the second most frequent command.
And so forth.

So on a phone with unassigned softkeys, everything in the user interface is "closer" than it is for that Nokia device. (at the cost of more hardware buttons). The softkeys serve the same function as right-click on a Windows computer.

We now have a decent measure of what is "close", which can be performed on any device with any platform. Be sure to include platform considerations: while traversing 45 links on some browsers is 45 clicks, on the Opera Mini, with its left/right arrow page scrolling, it may be only 6 clicks.

So if you are designing for speed of interaction, this analysis suggests the following:

• When designing for Nokia devices, order the commands in the menu by decreasing frequency
• Provide numbered access for visible frequent items on the screen (as well as anything the user may have learned)
• Use the Select (OK) button, if available, to select and activate screen controls.
• On non-Nokia UI devices, assign the most frequently used command to the primary (usually left) softkey
• On non-Nokia UI devices, assign the other command, or a Menu label, to the secondary softkey.</li<>
• If a third softkey exists, assign a command to it.
• If creating a menu of commands, order them in decreasing frequency order.
• Allow lists, particularly command menus, to wrap so the user can push up from the top item to get to the bottom item.

Note: I have simplified phones into Nokia UI and non-Nokia UI for discussion purposes. More complexities exist.

Of course Fitt's Law is not the only consideration in user interface design - but it is an important one.

I just looked at Brian Fling's Designing for Mobile presentation, which is intended to help folks get started in the mobile space. It's a good read, it organizes many things nicely.

This spoke to me quite a bit, as I am now wrapping up work on my book, Designing the Mobile User Experience, to be published in January. This book is intended to help marketing and product development professionals, particularly user experience folks, enter the mobile space.

With that in mind, I believe there to be some inaccuracies within Brian's presentation. Some are minor and not relevant, such as the assertion that 2G devices were voice + SMS only and ignoring 1xRTT as part of 2.5G. Relevant inaccuracies include:

• Cingular's terms of service, as of March of this year, specifically prohibit visiting sites outside their content. I fail to understand how this is not a "walled garden"
• Sprint's search engine searches all mobile-optimized sites, and allows direct URL entry for any site. I fail to understand how this is a walled garden.
• Similarly, Verizon has blocked URL opening from SMS messages. Walled? Seems so.
• I have seen no semantic difference between carrier and operator. As best I can see, "operator" is a more European term, and "carrier" is a more American term.
• Brian advocates writing for "feature phones" not "smart phones". A good place to start, but we should remember that smart phone users use more data services, so they are potentially higher users of a given application.
• As more and more people use the mobile Internet and other mobile applications, a larger percentage will be using the mobile as their primary use. Thus functionality that is available on the desktop should, if possible, be available on the mobile -- but not at the cost of the primary user experience! Infrequently used information should be in harder-to-access places.
• While XHTML-MP may be "often referred to as WAP 2.0", that is flat out wrong. WAP is equivalent to HTTP, not XHTML. The WAP 2.0 collection of standards includes push messaging, XHTML, XHTML with WML extensions, location services, transfer protocols and more.
• Flash is available on Verizon, KDDI, and NTT DoCoMo devices, which is a bit beyond "available to developers only". And SVG should be mentioned somewhere.
• J2ME (which ought to be called Java ME) content can run on BREW devices via a BREW-authored KVM. Thus J2ME can go to Verizon devices.

Regardless, it's a good start, particularly for a relatively short presentation. If you're new to mobile design, go read it. And order my book.

I just took a look at my Widsets application from home, where I do not have EVDO coverage. I spent a couple minutes looking at five progress bars, each creeping towards 100%. I then put the phone down because I had things to do. When I picked it up again, it did indeed have everything up to date, but I was no longer in a space to read anything, so I exited the application.

This behavior was unnecessary. If the "first" feed had been updated first, I could have been reading that while the remaining feeds were loading.

If your on-device application has a number of different feeds, consider loading the feeds asynchronously.