Recent Blog Posts

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.

Interstitial advertisements appear between screens within a mobile application. They are, in essence, a dialog box painted on top of the content of one screen before the replacement screen is displayed. They are excellent for branding. Click-through rates will tend to be low, since the user is being interrupted while attempting to achieve a goal, but studies show that retention is high.

Design

Implementation of an interstitial ad varies with platform capabilities. An ad usually has some sort of call to action, usually in the form of a link to a web site. Ensure that the advertising site is as well-designed as your application, or all advertising will fail.

Interstitials should be used sparingly. Display an ad only the first time the user accesses a piece of content, not every time. Display an ad between every four or five messages, photos, or news stories, not between every pair.

Platform	Implementation	Rationale
Web - no scripting	Avoid interstitials.	An interstitial ad must be displayed on a separate page, with separate HTTP/WAP requests and significant rendering. This can introduce a delay of half a minute or more. Use a banner instead.
Web - with scripting	Create page with ad image embedded, using approximately 60% of the screen. Focus is on the image. When the user clicks the image, the associated link is followed. When the user scrolls off the image, set the CSS style for the ad to hidden using scripting.	At the bottom of all the advertising site web pages should be a link to return to the original, sponsored, site. Mobile browsers have only one window available, so a pop-up window doesn't work. Using CSS allows in line display of the ad with the ability to dismiss it quickly, without any additional requests to the network. The image should provide enough of the surrounding page to ensure that users know it is a "pop-up" ad and not visiting the wrong page.
Applications - Nokia style softkeys or stylus	When the user clicks on something that triggers an ad, display the next screen with the ad in a floating window. Include a dismiss button and a Link button in the ad, as well as commands within the Options menu. Display the ad as a dialog box, with contrasting color from the balance of the screen. Include two buttons in the dialog box: "Skip" (takes the user to the originally intended content) and calltoaction (varies based on content; "Skip" is a good default). If the user takes no action within five seconds, dismiss the ad and proceed to the application content. Save the application's state so the user can return to the same point with no loss of information or navigation. Dismiss the ad in 5 seconds if the user has not interacted with the application during that time.	Buttons on the screen can be easier to access than commands in the options menu if the device has a Select button. Replicating the commands in the Options menu supports both mental models and both device implementations. The main goal is to interfere with the user's task as little as possible while ensuring advertising content is viewed. Prominent "Skip" controls enable this. The cost of visiting the ad should be as low as possible without interfering with the main goal. Buttons provide rapid ad link availability, with some customization to engage in more of a dialog. Saving the application state helps ensure the user is not punished for allowing the ad to take over the only window on the device.
Applications - standard softkeys	The same as the Nokia implementation, but with no commands in the Options menu and no buttons. Instead, the left softkey should be labeled "Skip" and the right "Link" or something similar.	Softkeys are very quickly accessed and require no scrolling or cursor manipulation.
MMS	Require user to respond with single letter or word, or simply send content message five to ten seconds later.

The ad content itself should follow standard best practices. It should engage the user and be relevant to the market. The amount of information should be limited to roughly what a highway billboard would support.

When Used

Interstitials are good for branding purposes, such as "Sponsored by Coke", as well as advertising with minor interactivity.

Avoid using interstitials when the user is paying high per-megabyte data charges. This can be inferred based on type of application: if the application already uses relatively high bandwidth, a few extra images will not be relevant. On the other hand, an application that synchronizes a few data fields but largely works offline may be used by people with costly data plans.

Rationale

Well-designed interstitials give a good view of the advertising content, and get out of the user's way quickly. This is a compromise between both.

By restricting the frequency of advertisement, the user can not simply take the habit of a second keypress to get to content quickly, as that keypress will do something different depending on whether an ad or actual content is displayed.

This post starts a series on mobile user interface design patterns. Future posts will contain a "pattern of the week", excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007.

A design pattern documents known good solutions to frequently occurring design problems. In some cases, the solutions themselves become encoded as user expectations: an application that violates the common design could jar user expectations. A user interface design pattern is a user interface that works well for frequently occurring human-machine interaction situations.

User interface design patterns, or universal patterns, are solutions that likely work across a wide range of applications and on different platforms, although some patterns are platform-specific. In addition, organizations with a complex set of offerings may also create a set of highly specific, fully stylized, corporate patterns in a pattern library frequently with code associated with the pattern.

User interface design patterns are generally identified and articulated by design experts. They can then be used by less experienced designers or by designers wishing to create a consistency in user experience.

Mobilization

While the world of desktop design patterns assume a consistent set of capabilities of the computer, patterns targeted at the mobile space must take into account the varying capabilities and user interface styles of the native operating system.

Some mobile UI design patterns are identical to the same solution from desktop design. Other patterns vary due to size of screen, cost of connectivity, input mechanism, technologies available, et cetera. In general, be suspicious of any desktop navigation or screen layout pattern - it may not mobilize well.

Mobile design patterns do not follow a strict categorization by application development platform. There are some portions of the wml namespace that, if present, enable interaction like AJAX or even Java ME. Thus a solution for one platform might be useful for a wildly different platform.

Desktop UI design patterns are reasonably stable regardless of platform. Tab navigation may look different in a Windows dialog box than it does on the Apple web site, but the basic concepts are the same. Only when multiple rows of tabs are needed does the underlying platform have much influence over design.

In contrast, mobile patterns rely on both device user interface style and platform. Whereas tabs are a useful mechanism on a stylus-driven device (web or local application), they are less useful on a scroll-and-select device application, and should be implemented as horizontal navigation instead. The same navigation in a web browser on a scroll and select device should either avoid the problem altogether, or use a drop-down list.

The browsers are a major problem with the mobile web.

In the previous installment, I talked about the problems associated with sharing information between screens. But the problem runs deeper. Issues include:

• launch times for content are too long. The user starts the browser, goes to the home page, and navigates to the desired site. This isn't too bad when time-filling, but it is bad when the user wants to see her agenda for today or download that song she just heard. Of course the network is a major contributor, but the browsers themselves slow things down.
• cookies are broken. I've posted on this before, but it bears repeating: cookies are the primary mechanism web sites have for saving user input, managing sessions, and in general making the web page act more like an application. Without cookies or work-arounds, web sites do not have any personalization.
• password management is awful, especially with broken cookies. Add a password manager, automatically filling user names and passwords into all sites. This can be protected by a simple 4-digit passcode, or any other mobile-friendly password, to be entered to allow the password manager to fill in the form.
• repeated text input in general is too difficult. At a minimum, the user should be able to enter commonly typed information, such as a physical or email address, and have the information automatically filled while typing. Perhaps some more advanced predictive text input schemes can do this, but browsers should be able to do it too.
• context is lost whenever the user exits the browser or goes to another page. If the user has to go check the phone's address book to get a bit of information to enter into a web form, many (all, in my experience) mass-market phones require the user to exit the browser. The browser then starts at the home page (and since cookies aren't working ....). The user might navigate to the page again, or might quit entirely.
• standards support is inconsistent. When I wrote a detailed user interface design guidelines document, I devoted ten percent of the document to listing what each browser did and did not implement in CSS. This was a few years ago, but many of the smaller bugs remain. This issue just exacerbates the alphabet soup of WML, XHTML MP, XHTML Basic, CSS, WCSS, SVG, and so forth.

Opera Mini is great, but still suffers many of the above problems. It also suffers from being a Java ME application, without ready use of the native text input mechanisms. Controls for changing input mode on my phone, for example, are typically found on the right softkey. I almost failed at discovering that the * key would control it instead.

Opera Mobile has a good user experience, and I suspect that Nokia's high end browser does as well. They suffer the problems from the previous posts, but are pretty good. I can't comment on their issues in detail since I focus on mass-market phones.

Not to leave anybody out, my next post in this series will address carriers.

While I'm no longer sanguine about Neomedia/Paperclick as a company, the core idea of using the camera phone to read bar codes and get information from the Internet is compelling. Kaywa, for example, is gaining some traction with QR codes in Europe.

Within this context, Wireless Watch Japan's tidbit about McDonalds printing QR codes on sandwich wrappers with links to nutrition information is interesting. What else could be printed on soon-to-be trash?

Oh - and as far as Neomedia is concerned, I'm largely concerned about their current business practices. Startups should not go on consolidation sprees, and they especially should not purchase companies with no relation to their own business (auto painting?!?!?). They don't seem to be making any news on their "core" business beyond announcing something that seems a rehash of announcements from two years ago. I'm worried that they are moving to become a patent holding company, with no real operations, planning on suing those who become successful in the space.

Some readers have noted that their device running Opera Mobile (not Opera Mini) has multiple windows, so my previous post did not apply to them.

Well, sort of. You have multiple "layers", with different content in each. There is only one window.

Why does this matter? Consider the following real world tasks, which will have to be done on a mobile device if you are not using a desktop device.

• Balance your checkbook using an online statement. This necessary task is annoying enough on a computer; I end up working on getting two windows side by side. The task is possible, though particularly annoying, on a multiple-layer interface. It is impossible on a single-window single-layer interface.
• Following a tutorial for one page or application, with the tutorial written in another page. While possible on a multiple-layer single-window interface, it requires frequent switching between screens.
• Intense email processing, including looking up information referenced in an email, checking and updating calendars, looking up a person on a social networking site, and so forth.

All of the above tasks are possible on a single-window multiple-layer interface, such as Series 60 or Windows Mobile (assuming you have a browser with multiple windows). That doesn't mean that they are fun. The email task is perhaps the easiest, as the demands on the user are the lightest.

These tasks have something in common: the user needs information from one screen to be able to process or act upon the information in another screen. Some such tasks are readily handled using copy/paste, but most others are handled by requiring the user to store the information in her head while switching between screens and processing the information on the second screen. This is a high cognitive load task, and out of the realm of what most users are willing to do for everyday tasks.

Many of the above tasks are impossible on a single-window single-layer device. The job of switching to another screen requires exiting the current page, and the cost to find the exact context may require the user to re-launch the browser, navigate to the site, log in, then navigate to the page in question. Far easier to send the page to a networked printer or fax machine. Or even write down the information.

So back to my previous post: even on high-end devices with high-end browsers, split windows and mashups will improve the user experience.

What's wrong with the mobile web? Quite a lot. Over the next few posts, I'll discuss issues from a variety of industry player perspectives - including the W3C. First, of course, we address users and user needs.

There are two main camps in the mobile web:

1. One Web. The Internet is the Internet, and sites should run well on all devices. Optimization should be based on CSS and device detection, but should not change site function or content beyond the necessary.
2. Mobile Web. The mobile is a different platform with different capabilities and different user needs. Sites should be optimized for mobile in many (but not all) cases.

One Web advocates talk about use of standard technologies and the growing number of people who use, or will use, their mobile phone as their sole web access. We should listen to these core concerns.

Mobile Web advocates talk about differing user needs, connectivity costs, and device capabilities. We should listen to these core concerns.

One Web advocates riposte with the assertion that the Mobile Web concerns are temporary: connectivity and device capabilities will improve, and if the mobile is the primary access to the web, than the users need everything that a desktop site needs.

It's not that simple. Imagine, if you will, a world in which users of personal communications devices are attempting to do all the work with web sites that desktop users do now. Further imagine that the devices have twice the battery life, high speed downloads, and plenty of processor power and memory. In short, imagine the world that the One Web advocates believe to be the future.

A personal communications device (a category that includes mobile phones, Sidekicks, BlackBerries, and future devices) is strongly controlled by The Carry Principle. In particular, a small device strongly implies a single window interface.

Okay, so what about the users? Users need a way to manage several information sources simultaneously, both within sites and between sites.

Desktop applications and web sites have since the 1980's been designed assuming multiple windows. If you want to get information from another application, just open it. Browsers can have multiple windows open. This is particularly important in our current world of online applications: I can have my email window open, my business networking site open to research somebody in my email, and my calendar open - all in separate windows. Mobile phones do not support this cross-site fertilization. Instead, only one "window" can be viewed at a time.

For "one web" can become a reality, browsers must become adept at handling multiple tasks. This, by itself, is inadequate. High-end phones (variously called "smart phones" and "PDA phones", usually with an operating system like Symbian, Windows, or Palm) have rudimentary multi-tasking - but on an application level. Multiple browser tasks must become easy; switching between pages must become easy; split-window viewing must become possible.

Browsers must become adept at handling multiple simultaneous tasks in the same way that messaging applications are adept at handling multiple conversation threads, except that users will want the information either simultaneously or with rapid switching. The browser will have to be re-engineered, from the ground up, to truly embrace the mobile environment rather than being a miniature desktop browser.

I am not confident that all of this will become possible. I am firmly in the "Mobile Web" camp, in which mobile browsing of the future will be based on "mashups", RSS feeds, and mobile web sites with full access behind it. Mobile Gmail, for example, allows an optimized experience while giving me the control to view all my content with a few extra steps.

Even in this future, the browser has to be re-engineered. Mashups should be buildable on the fly. Voice and camera input should be built in. And a whole mishmash of usability improvements need to be made.

Next topic: what browsers need to do - today - to support mobile users