Recent Blog Posts

I think the 800 pound gorilla just wandered into the room. Finally.

Users have plenty of trouble finding content on their computer. We just saw two major operating systems build in live content search. So why couldn't we do that on mobile devices when we have so much more control over the actual content? It's starting to happen, and could change how we use mobile devices.

When I last wrote about the problem, I was unaware of Qix from Zi Corporation. They've improved their product over the last year, with availability on a few phones (Windows Mobile, Series 60) and the ability to search operator portal content. It's exciting, but it will take a while to get traction (especially with their limited device support).

So, in comes Tegic. They've made major usability improvements in their new XT9: error correction and easier/automatic input mode switching (finally!). They've also announced T9 Discovery Tool [pdf, sorry] which replicated the Zi functionality (on-device plus portal keypad access). I find it particularly interesting that this has been picked up by Wireless Watch Japan but nobody else, despite Tegic's promotion of it at 3GSM.

Tegic has three things Zi is missing: AOL is behind them, they have a huge install base, and they are working on mass-market phones. This makes them the 800 pound gorilla. I look forward to seeing what Zi will do to best their long-time larger rival. Maybe partner with Google?

These events are important in several ways.

• Mixed local/online search. Right now it's just the operator portal, but further developments could search the entire web. Hypothetically, the user would start typing just as they would with the current product, but have a button that would send the text to a generic web search. The web search would need to have the same intelligence as the on-device product: if "tomorroq" was sent, it would check both that and "tomorrow".
• Promotion of operator portal. Carriers who want to avoid becoming "just a pipe" can provide live searching of their content ahead of the rest of the web, in a fashion that enhances user experience (with the right data plan).
• Promotion of mobile-safe sites
• Promotion of the development of the semantic web. Content, particularly non-text content, will need text tags to be readily searchable.
• Hypothetical addition of favorite sites to on-device search. I'd add del.icio.us and LinkedIn, you might add Flickr.
• Promotion of ... the web. The information really is there, it really is useful, and now it can really be easy to access.

Tags: Business,  Carriers,  Design,  Devices,  Mobile applications,  Mobile web, Permalink | Comments (0) February 28, 2007

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 last set of patterns will address application management design for mobile applications.

Cookies are a popular method of identifying users and storing key data locally. Unfortunately cookie support varies across devices and carriers.

Design

Determine whether each cookie's function can be fully or partially accomplished through the techniques below, or other techniques. If a large portion of the site has an unacceptable user experience after reducing cookie use to its minimum, then perform a cookie test on all possible site entry pages. If the cookie can not be read on the next page, advise the user of the problem. Most users can download a browser to their phone; Opera Mini runs on all Java ME devices and supports cookies well.

One simple technique is to add user identification data to the URL string and then having the user bookmark the URL string with ID. If worried about users sharing the identity-specific URL, add function to the site for the user to share the site easily; this will prevent users from being interested in the extra steps necessary to copy and paste URLs into other applications.

Password information obviously should not be encoded in a URL, but many applications only need password verification for a small subset of their application. Delaying the demand for the password, then allowing that user access to password-protected information for a short time as determined by your server, can bypass much of the password problem.

Applicable Devices and Platforms

Browsers.

When Used

Use for web applications when the universe of browsers is not controlled or otherwise unknown.

Rationale

Some users may have cookies disabled. Other users may have cookies enabled, but their carrier or device may expunge cookies. Users who have to enter a user name and password two to three times per session of using email will quickly stop using the service.

From an OpenOffice.org dialog box:

This document may contain formatting or content that cannot be saved in the OpenOffice.org 1.0 Text Document file format. Do you want to save the document in this format anyway? - Click 'Yes' to save in OpenOffice.org 1.0 Text Document file format.
- Click 'No' to use the latest OpenDocument file format and be sure all formatting and content is saved correctly. Yes No

I want to save in the same format I've saved it in the last 45 times I've saved the file. Do I click 'Yes' or 'No'? This user's answer: "no idea; I make an error on this one on a regular basis."

There are several problems with a dialog box like this one (similar dialog boxes appear in mobile app, mobile web, fixed web, fixed app, and many many other platforms all the time).

First, the question shouldn't be there in the first place. I've answered the question for this file before. Why bother me with it again? I don't want to always answer this way, just always for this file.

Second, it doesn't check to see whether the current file would lose anything; it tells me this even if the file is pure text. A bit of logic to alert me only if formatting will be lost would be a good plan. (Especially since the file in question is in the older format!)

Third, and easiest to fix, are the yes/no buttons. The button labels should give cues to the action to be performed. In this case, "use .sxw" and "new .odt" would work fine. The user should be not have to read the dialog text, especially the second, third, or 45th time around. And no, OK/Cancel buttons are no better unless you are truly canceling an action.

From a developer perspective, yes/no buttons, like OK/Cancel buttons, are favorites because the tools have preset dialog boxes in which the developer just has to add the relevant error string, and bam! there's a dialog box. Fortunately, it really only takes 2 extra minutes to call a slightly different object and put useful labels on the buttons.

In the mobile space, I frequently see the button label problem with error messages and query messages. In many of these cases, "Retry" and "Cancel" make good labels (almost always better than either yes/no or ok/cancel). What's most important is giving the user a clue about the action in the button label itself.

I've made this into a draft UI design pattern; I'll refine it in a couple of weeks --- or you can!

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 last set of patterns will address application management design for mobile applications.

The simple act of launching an application is often mishandled, causing the user extra delay and sometimes launch failures.

Design

This is not one pattern but instead a set of best practices.

• Check license status only when necessary. If the application is licensed for a month, check license status a few days before the old license expires.
• If frequent license checking is necessary, consider allowing a certain number of runs when no network connection is available. This allows application use in the basement and other low signal areas.
• Avoid setup questions except the first time the application is run. For example, if your application supports a "game lobby" and the user has declined joining it, avoid asking the same question each time the application launches.
• When possible, break the application into modules. Load only the base module upon launch; load other modules in the background while the user interacts with the basic module.
• Maintain password information as long as reasonable given the security needs of the application.
• Certify the application, so the user does not have to handle queries about potentially unsafe content on a phone.
• Intelligently save context, so the user does not have to find her place again. Some applications need to start at a home screen; most applications are better off starting where the user left off.
• Provide frequent task actions on the main page. For applications with very frequent main tasks or views, the primary task or view should be the main screen. So-called "main menu" items can go in a softkey menu or similar.

Applicable Devices and Platforms

Downloaded applications.

When Used

All downloaded applications need to be optimized for fast launch.

Rationale

Users tend to want to get their content, including download and purchase if relevant, within 20 seconds; some data suggests that the impatience limit is actually below 10 seconds.

On many devices, if the user has launched an application, she can do nothing else with the device until the application has exited. Only one application can be running. Thus the 30 seconds that many applications take just to launch leaves less than no time available for fetching information before the user's patience has been tested.

The promise of mobile data and applications is information and entertainment on the fly. This realization will never happen with long launch processes.

If you are lucky enough to live in Europe, I'm pleased to announce that Designing the Mobile User Experience is now available!

In it, you will find:

• a comprehensive guide to the mobile user experience, offering guidance to help make appropriate product development and design decisions.
• the tools necessary for product development professionals to understand development in the mobile environment.
• an overview of the components affecting the user experience and principles uniquely applicable to the mobile application field.
• the industry structure and power dynamics, providing insight into how mobile technologies and platforms become available on current and future phones.
• user research and design methodologies accounting for device proliferation
• user interface design patterns, design resources, and user research methods for mobile user interface design.

Designing the Mobile User Experience is an invaluable resource for information architects, user experience planners and designers, interaction designers, human factors specialists, ergonomists, product marketing specialists, and brand managers. Managers and directors within organizations entering the mobile space, advanced students, partnership managers, software architects, solution architects, development managers, graphic designers, visual designers, and interface designers will also find this to be an excellent guide to the topic.

Most of the rest of us will have to wait until April to get our hands on the book.

Yahoo has just created Yahoo Pipes, which allows non-programmers to create mashups from various sources (currently looks like mostly RSS). A better writeup can be found at Lifehacker. I think this could be huge for the mobile space.

Reading on a small screen is hard enough without having to process the 90% of the stories that I don't want to read. This tool could presumably be used to get me a filtered set of posts delivered to my mobile, letting me ignore announcements of funding deals while focusing on other topics. Nice.