Recent Blog Posts

Last week, Gomez published "Why the Mobile Web is Disappointing End-Users,” which you can read online at Scribd. In summary, huge numbers of users are reporting problems with the mobile web, with download time the number one problem.

While this seems simple, it really isn't. Consider my ongoing experience on my Nokia E71, on the AT&T network, in a non-impacted 3G area, using the highly optimized Google Reader (and I'm using the "mobile" version not the "iPhone" version, though the device supports both). I also use the same site in Opera Mini.

Typically it takes two tries before the native browser can find the page, and if I reload the page that is there Google errors out. Opera Mini is faster, but I have to tell it which network to use two or more times before I can load the page.

I just outlined problems with the browser, the network, the site, and the operating system/device. Each contributes to my slow experience. And most sophisticated users won't be able to distinguish these, let alone typical users.

Perception vs. reality

Before we get too focused on speed, consider some fascinating research by User Interface Engineering titled The Truth About Download Time. Don't get wound up in the age of the research; the conclusions are still true.

There are two paragraphs you really need to read:

... we found that there was no correlation between ... [actual download speeds] and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds).

There was still another surprising finding from our study: a strong correlation between perceived download time and whether users successfully completed their tasks on a site. There was, however, no correlation between actual download time and task success, causing us to discard our original hypothesis. It seems that, when people accomplish what they set out to do on a site, they perceive that site to be fast.

So. Perceived speed is not the same as actual speed.

This is undoubtedly the case for the Gomez study. How many users actually count seconds? Very few. So don't be overly concerned about times in the study. But do be concerned about how fast that people think the web is, as well as failure to accomplish goals.

What to do?

Let's avoid the finger pointing here. Everybody, at every step of the mobile web value chain, can increase the speed of the mobile web. Over the next four parts in this series, we'll look at what each of the different types of organizations can do. We'll make these links as each of these is published.

• Content providers
• Operators/carriers
• Manufacturers and operating system makers
• Browser makers

In the meantime, contribute your thoughts to the (currently very brief) Design for Mobile page on Mobile Web Speed.

In August 2009, the Admob Metrics report for the U.S. Admob ad impressions showed a little feature phone moving to third place after months at fourth place. Yes yes, the iPhone and iPod Touch are numbers 1 and 2. But that's not important here.

The Samsung R450. To be more precise, the Samsung SCH-R450 for Metro PCS. Not an Android device, not a Pre, not a Blackberry. A messaging-focused feature phone with a poor camera, released in 2008. And not AT&T, not Sprint, not Verizon. Instead, Metro PCS, who says "everything we do is unlimited." Smartphone users are getting unlimited voice, text, and data for $50/month. Feature phone users max out at $45. With no contract.

This price is within the range of "normobs," or normal mobile users, especially when considered as a replacement for a wireline home phone.

And guess what? They are using the mobile web. In great numbers.

Some folks are holding onto their Motorla RAZR. Yes, in 2009, the RAZR is still in the top 20 handsets hitting Admob-measured sites. Actually, it's number 6. Our UK readers may be aghast, but go look at your numbers. Three Nokia devices in the top 20? And none of an E-Series? And Apple taking over 50% of Admob traffic? (I keep mentioning Admob because they are measuring a non-random subset of mobile web data.)

And while you're at it, check out the increasing share of... Sony PlayStation Portable.

Design for more than smart phones

Okay, smart phones are great. iPhones are great. We like them. We use them. But they are not the only devices out there. Design for all the devices important to you. And by "important to you" I mean important to your customers.

"Wagging the dog"

Industry pundits have talked about how the iPhone is the tail wagging the mobile industry dog. That may be true, but let's look at user behavior instead.

I've spent time in the past few months helping my parents and a similarly-aged friend decide what device to get next. They are all very interested in smart phones, especially once I showed them applications. After all, applications let them do what they want to do, not what the mobile phone manufacturer thinks 80% of people want to do. And their needs aren't outrageous, either.

So we have increased interest in mobile web and mobile applications from folks who do not want the latest gadget. And they don't necessarily know that they need a specific brand or operating system to do it. If a device delivers a good web experience, and perhaps some downloaded apps, that may be all they need. Yup, I'm talking web and Java here, folks.

Feature phones can do it

Why won't they get smart phones?

Because they have to pay more per month, every month. $20 extra each month for Verizon, as of two minutes ago. That's $480 extra plus tax over the course of the contract, and the phone most likely costs more, too.

So my father would have to pay more for the smart phone, then pay more for the data for the smart phone. He's a smart man and is budget conscious. Why would he do this? He'll avoid it if he can. He doesn't need or want to download music or videos. Why pay extra for this?

And feature phones will serve most of his needs, especially once he discovers GetJar.

I believe that feature phones are going to be far more important in mobile data in the next few years, driven by these varying price points the operators are maintaining combined with the capabilities perceived to be part of smart phones only.

And guess what? If customers make this choice now, many feature phones have better browsers than Blackberry and Windows Mobile. So which is the better choice? As better BB and IE browsers deploy, this will be less true. But stay tuned.

I don't know how I missed this post by Joe Leech from mid-September, but I did until Barbara tweeted it the other week. I also can't believe that I'd never talked about it anywhere like here before; fighting the myth of the page fold, and working on currently-relevant design-for-scrolling is something I actually spend a fair bit of time doing on pretty much every project.

The "page fold" comes from newspapers. "Above the fold" is what is visible on the newsstand, and what grabs you to make you buy it. The same concept carried through to early web design, and worked okay I guess when everyone's screen was the same size.

Those days are gone, and with different browsers, zooming, scaling, and all the variations multiplied again for new platforms like mobile it's an interesting field to look at. The link above talks a lot about how users perceive pages to understand scrolling. That /is/ interesting design to work on and stuff everyone has to keep in mind.

I think I know this topic pretty well, but just talking around the office, others brought up topics I knew perfectly well, but had forgotten to include. So far, we have these topics to help design for successful scrolling:

• Vertical Scroll
• Scrollbars
• Meet Platform Expectations
• Avoid False Bottoms
• False Tops, and Other Scrolling Up Issues
• Chrome Variations
• Encourage Scrolling With Content
• Force Scrolling

And maybe you know more about some particular trouble. If so, especially for mobile, don't comment here in the blog. We set up a longer version of all this up on the Design for Mobile wiki. Please go to the Myth of the Page Fold page, set up an account, and add your content. Or expand on my notes.

Even if you just have an opinion, thought, question or concern, this wiki is a great place to bring it up. Add it to the topic or (if not final yet) talk page.

Over on the very nice UX Exchange, user mattti asked the question, Touch gesture usability in mobile devices – which ones work?.

As we’ve been doing a bit of work in gestures this year, I tossed off this response.

Touch gestures are only one type of gestures for mobile. Technologies such as accelerometers, light sensors, other cameras, pressure sensors, RFID, NFC, Bluetooth, and various location technologies are all possible.

Then there are the “display” mechanisms: vibration, rumble, electrical fields, force feedback, sound, and so forth.

In general, this space is in its infancy.

Phones should always be designed with one-hand use and two-hand use in mind, but it is up to the product team to decide the relative emphasis. Clearly making and receiving calls should be one-handed. Should web? I don’t think that’s as necessary. But usability can be achieved either way.

When designing gestures, you must keep in mind that they lack any innate visual affordance. You must rely on other methods to enable discoverability. There are a few approaches to this. The iPhone’s “flick” (scroll fast) gesture is a very simple extension to an existing behavior; it uses something people already do and just responds more naturally to it.

A second approach is training. The Palm Pre requires users to go through a training video to get the “back” gesture, as you really can’t use the device without it. There is no corresponding button.

Apple has used advertising to teach people about pinch to zoom. It’s less effective: many users complain that they just can’t read the browser text. They’ve not discovered how to zoom in.

Like I said, this space is very much in its infancy. But principles we’ve observed include:

1. Carefully train any gestures critical to the use of the device. Swipe left for back, pinch/spread to zoom out/in, double-tap to zoom to fit.


2. Avoid making many gestures critical to the use of the device. Provide menu or icon alternatives for most gestures. Gestures (and voice control) provide shortcuts, not navigation through menus.


3. Use natural finger or thumb paths rather than requiring strict rectilinear paths. In other words, use good biomechanics and be forgiving of error. Example: The iPhone unlock screen requires too much precision in start and end points to unlock. It is too easy to stop at the wrong place.


4. Test your gestures with real users. Redesign, test again.


5. Consider a device mode in which everything is done through the menu. This is the “share with somebody else” mode. Verbally communicating gestures while driving is frustrating for everybody.


6. Be smart about automatically doing things. Sometimes, for example, a person might want to lay down while reading a web page. Indeed, “in bed” is a common context for use. The iPhone makes this challenging, as it automatically rotates sideways. Some applications have a “lock” mode in which they won’t rotate.


7. Where possible, re-use gestures. Pinch to zoom should be preserved. Flick to scroll should be preserved.


8. Think outside the box. Or off the screen. I want a function that intelligently locks and unlocks my screen based on device position and light input (i.e., it’s upside down in a pocket or purse then the keys are locked; I pull it out and they are unlocked). This is far more important than an extra on-screen gesture.

Also, be sure to read some of Kevin Arthur’s work. I keep coming back to Evaluating Gesture Usability – it includes a method to actually develop and test good gestures.

For over a decade, we've been promoting "mobilize, don't miniaturize." Unfortunately, the typical implementation of mobile web (or apps!) has meant "strip out functionality to the core essence of the service." Here's a sampling of what folks are saying around the web:

Mobile websites should be designed to be small, simple and distilled down to their most crucial aspects.
—Mobile Web Pages Need to Be Simple, Web Design SEO

When it comes to mobile websites, simplicity is key.
— Mobile Web Design Trends, Smashing Magazine

Less will always be better- that is the primary rule of converting your website to mobile.
— What Should My Mobile Site Do, MoFuse Premium

While we advocate simplicity in design, we're not really sure this is especially true for mobile. First, there may be functionality in the mobile possibly not in the desktop version of the site. But let's ignore that. Is simple always the best answer? Should we always reduce functionality to the "core"?

What is Simplicity, Anyhow?

And are we even talking about the same thing? The quotes above essentially suggest simplicity and complexity are opposite ends of a continuum, with everything true and good in the world to the left, like so:

This over-simplifies the simplicity discussion. Or, simplicity is more complex then this.

What does "simple" or "complex" mean? In one of our Friday design discussions, we realized the argument is mistaken in one of the commonly encountered senses, where "complex" frequently means cluttered. We've all heard this from reviewers and clients. We drew this on the whiteboard to frame our discussion:

The two axes are mostly independent of each other. A highly complex functional product can have a "clean" interface (consider www.google.com), or it can look cluttered (think Facebook and Myspace). A product with few features can look cluttered, the way Craigslist does, or can be clean like many online stopwatches.

The simple/complex axis largely relates to functionality or amount of content. The clean/cluttered axis is more a measure of the visual, information, interaction, and content design.

Another benefit of the chart above is that it's a 2 x 2 grid! All MBAs like 2 x 2 grids. Not only do many of our clients have MBAs, but so do I. So this is a good thing. Here we map some services into our grid:

Visually Clean

Most interesting digital systems are indeed functionally or organizationally complex. But they needn't look cluttered.

The essence of being "visually clean" is that the possibly complex system doesn't look complex. One great way to accomplish this is to display only the information relevant right now.

Is Simplicity Universally Desired?

The aversion to "cluttered" likely has a cultural component. Consider this set of Japanese mobile portals selected for their good design; they have a lot going on. Many modern cityscapes are similarly cluttered.

Not only does the aversion to cluttered have a cultural component, it also have a contextual component. Sticking with the Japanese, check out Presentation Zen's 7 Japanese aesthetic principles to change your thinking. So this culture desires both cluttered and clean, in different contexts.

Complex Cluttered Arrangements of Simple Clean Objects

Or, portals, dashboards, and cockpits.

We humans have a repeated behavior of collecting simple things and arranging them for aesthetic or functional purposes. iGoogle, NetVibes, and Pageflakes are all examples. Web portals tend to do the same. If you want a bit of fun, get Steven talking about portal theory.

These systems, as a whole, are complex and cluttered. But each element is simple.

See the whole interactive panorama at Gilles Vidal's photography site

Is Functionally Complex and Visually Cluttered Bad?

For consumer systems, probably yes. Choices are overwhelming, users don't understand the complexity model, features get lost. The ability to handle functionally complex is typically through visually simple interactions in which content is well organized in time and space.

But consider an airplane cockpit. Lots of information is immediately visible, even in glass cockpits with their modal display of information. These are complex systems, both functionally and visually. They require a lot of training to learn to use. There is still a lot of design here.

The key to making these systems easy to use is to work on matching displays to mental models, and training users on the proper mental models.

Back on the consumer side, or even enterprise employee mobile phone user side, you can add complexity over time. If a new Facebook user were to see a heavy Facebook user's page, she would be lost. Actually, I'm lost; I only use Facebook sporadically. The site is manageable because users learn small parts of the service before being bombarded with memes, applications, and friends.

The Challenge of Functionally Simple

It was difficult to pick out good "simple" and "clean" examples within the web domain. We discussed a currency calculator and an online stopwatch.

This comes as no surprise. Most apps and sites are built by an organization. Organizations have as their very nature a key unstated goal: to continue existing. To do this, they have to keep growing. To do this, they have to add value. Most apps and sites run by organizations will grow, and become less simple.

As your site grows, that original clean interface may simply stop working. It's not any one person's fault, but it often happens when organizations grow, and as individual needs are met without stopping to reconsider the whole product. Beware.

Several good design and product management practices can help avoid creeping featuritus. The use of personas, themes for each product release, and more can all help. The selection of which tool depends on your organization. (we can help)

How Much Simplicity?

Everything should be made as simple as possible, but not simpler.
—Albert Einstein

Einstein is right: don't overdo the simplicity. And let's make things complex enough to meet users' needs.

The features required for any particular context, be it device, user, time of day, location, situation, etc. vary a lot. There's no way to tell, and one context's simple is another's too complex. Worse yet, is being too simple.

There is a good cutoff, at the arbitrary (and unscaled) point shown above, where any design should probably have a certain degree of "clean-ness" -- avoiding the clutter of your typical overdone web portal.

The functional complexity might not need to move, especially with an increasing number of people using the mobile as their primary access to the web. Do you want to reduce functionality for a class of user? If so, be sure that they would agree.

How Simple is Too Simple?

If your target users can not accomplish key goals, your service is too simple.

What Does This Have to Do with Mobile?

Nothing and everything.

Nothing: These ideas behind simplicity apply to most design exercises; they certainly aren't limited to mobile. Indeed, there is a growing sentiment around the web to design for mobile first, then design for other platforms in a progressive enhancement approach. Even David Wood's recent Symbian blog entry on simplicity is more about software development in general than anything mobile specific.

Simplicity (cleanness) is a design ethic of our times, not just for mobile.

Everything: Mobiles are pretty complex already, especially including the wide variety of contexts they will be used in. And many operating systems expose much of that complexity to the end user.

Considering solely the use on the phone and making that as simple as possible, particularly functionally simple, can increase complexity for the user. In an effort to achieve mobile simplicity, Gmail mid-to-low capability mobile sites and Java applications do not provide labeling functionality. If you use labels to organize your many gigabytes of email, you'll have to do it on the desktop.

In contrast consider the Twitter application for the S60 platform, Gravity. If you've not seen it, please do go read the All About Symbian Gravity review and also see this set of Gravity screen shots. The user interface is visually clean, with a functionally complex set of controls appearing as needed. It keeps the complexity in context, making it not seem complex.

When trying to find a simple/clean example, I went with Minutes because I actually use it, all the time. For most other simple/clean designs ... it's a hassle to keep the tab open. But there are mobile applications I use in similar ways. One is Screenshot. All it does it lets you take a... screen shot. I leave it running all the time.

Impact of Multitasking

This brings up a good point. Are simple applications or web sites really great for general computing devices that do not have good multitasking? That (of course) depends. If you need to use the simple app in some continuous, largely uninterrupted, and finite manner, such as a stopwatch, weak or no multitasking is fine. But if you need to dip into the application several times over the course of the day, such as a task timer used for billing, then the repeated time costs of loading the application will become unacceptable.

Clean on the Small Screen?

Yes, you can get functionally rich services with simple design on the small screen. You can keep the white space, though you should design with the frame of the device in mind.

What you shouldn't do is take out too much. Most of the time, you should only remove what is truly irrelevant when mobile. Just like you should remove desktop-irrelevant stuff from the desktop interface.