Interaction Fragmentation, and Avoiding It

An increasing issue I've been observing, and lamenting, is interface one-upsmanship that leaves interaction clarity behind. This NNG report summarizes the findings nicely; beautiful-looking but ultimately confusing and difficult to use products.

This is not just an iPad problem by any means. And it's something we at Little Springs have been writing about for a while.

Interface fragmentation seems to be a somewhat desirable thing. Okay, let's call it "interface uniqueness." You set the look of the product to reflect (or create) a brand feel that is related to the device it lives on, but is clearly differentiated from other apps or sites available to the same device. This is valid, and we work on projects like that all the time. Right this minute I have a team working on new interfaces for a mobile web browser.

But interaction has to be grounded in the common device interaction language. We're not changing the interaction for that browser in any notable way.

And since I run across someone every week who conflates "interaction" with "interface," here are a brief set of definitions:

Interface Design

What you see, the color, gradients, type, size, spacing, and position of elements.

Interaction Design

How those elements work, how they react to input from the user, which ones are presented in what priority within a single screen or state, and the methods customers can use to interact with the product.

And for anyone wondering why you need to work within the device or OS interaction language, just think about how you interact with your mobile devices. A typical user switches apps constantly. Think about how often you read an SMS. That's a switch from the core GUI or some other app, to the SMS, and often back each time. So dozens to hundreds of switches a day. And you change your phone how often? Every two years?

Okay, devil's advocate to short circuit some of the arguments: You have a phone, an iPod, an iPad and a computer (I actually have more devices than this). When you read that SMS, you might not just switch from one phone mode to another, but between typing on your computer to the mobile. Sure. But the hardware shift (and point of view shift, and interaction shift from keyboard/mouse to handheld) is very effective at resetting your brain to the new interaction expectations.

And, we've seen this. Years... no, decades before the study linked-to above, I've observed unfamiliar interactions within a single interface (a device or browser) break the user's mental model and leave them frozen and failing to complete tasks. This is not something you want.

Luckily, it's easy to work around. And is not magic. There's just a few things to keep in mind. Stick to the native device interface methods:

• Navigation: Softkeys, menu buttons, native methods of going back, even exit methods. Softkey-like navigation on a touch-only device doesn't work as well as allocating functions to on-screen buttons and menus.
• Interaction: Accesskeys, built-in gestures, haptic feedback, and so on. Not just what is available, but what is actually used by the GUI, and in the manner they are used.
• Display: Rounded-corner icons, backgrounds, built-in list and menu displays. What do the built in controls look like?

This is not a web vs. app argument. While apps are generally considered the big problems here (and I am particularly aggravated by a lot of iPad apps), the web is really at least as big an issue. We all forget it, because we're used to the web being a little random — or just having it's own interface paradigms. However, the mobile web is all about task completion, so should often be very much like a native application.

An example I used just the other day in the office is the mobile Weather Channel website (which Little Springs designed). The version sent to high-end touchscreen devices is designed to look and act like a high end touchscreen application. The one for scroll & select phones looks and acts like a typical scroll & select application (adding accesskeys, for example).

It was the right experience in each environment. It was not a degraded experience for so-called lesser devices.

How do you deal with all this? Not by building once per platform: that way lies madness. How many different Blackberry variants will you design for? Consider screen sizes and touch, roller ball, and scroll wheel interaction before you answer that. And of course what about Android? How many variants? Oh and sticking to iPhone won't keep you safe. Like PalmOS, iPhone OS X is focusing on a very small set of screen sizes: right now, iPhone/iPod Touch and iPad. But expect soon, probably this month, to have an iPhone with much smaller pixels. Now what?

Instead, design and build your applications and sites with rule-based design. Rules can be based on number of pixels, pixel density, OS, connectivity, touch vs. scroll-and-select, GPS vs. other location vs. no location, and so forth. Embrace fluid layouts. Select different images based on the UI and the current screen size. Use native widgets so you don't even have to bring in or build your own images. Optimize for a few key devices, but support all of them well.

Don't embrace consistency just for the sake of a consistent experience. People can order food at the McDonald's at the airport just as well as the McDonalds out by the lonely highway. Context matters, to the point that your customers probably will not even notice that there is a difference. Only you will.

At last year's Design For Mobile conference, Barbara Ballard spoke about A Foolish Consistency, presenting a case for embracing context-appropriate design. Come see us later this year in Chicago for D4M 2010 to have more of these discussions, share your own thoughts and learn more strategies for developing the best mobile experience you can.

it was very interesting to read.
I want to quote your post in my blog. It can?
And you et an account on Twitter?