June 14, 2005

OPINION://Choices, choices

The iPod was a success for many reasons: sleek design, uniquely large capacity, brand, content availability, and so on.

But what fascinates me is the scroll wheel. It enables you to rapidly navigate a large menu space very quickly. But cellphones seem to have got stuck with “microswitch mania”. Just lots of binary on/off switches arranged in standard or crazy layouts. Ever wondered why the Blackberry is so popular when anybody can get e-mail dirt cheap on a normal smartphone? Look at that little analogue-feeling wheel. That’s the secret sauce.

Without the scroll-wheel, the iPod would have failed. And the competition is barely catching up.

Reading through Russell Beattie’s encyclopedia of Symbian Series 60 applications, you can’t but help be struck with the though, “My Grandma! What a lot of applications you’ve got!”. He does explain how he orders them, and bends the default folder structure to his needs. But that’s a lot of clicks for him to fire up an app and do a simple task.

Now the application paradigm is broken for mass-market mobility in many ways I’ll go into another day. But just imagine for a moment how much better a user interface we could make to explore these complex data structures. I don’t know what the answer is — it could be some combination of clicked, haptic, and orientation functions we’ve barely dreamed of. But I’m sure one key to unlocking the value of these devices is improved navigation of data structures — as well as a better information architecture of those data structures in the first place.

Interestingly, we have never seen intelligent user interface components develop even for today’s clickety-click user interfaces. Take an apparently simple thing like entering a US state into a phone. There are several naive approaches. Get someone to triple-tap the state abbreviation (hope you know your AR from your AS). Or have a drop-down list with all 48/50/59/65 of them (what, you didn’t know?) — lots of fun pressing the down key three dozen times. Even doing the simplest UI tasks across multiple devices and their form factors and software profiles is a nightmare.

What the developer needs is a UI component that will adapt itself to the device in question:

  • On a touch-sensitive screen, you might show a map with the general regions (west, central, etc.); and then a second map where you select the individual state.
  • On a device with a scrolly wheel, the drop-down list might be OK. On a device with a keyboard, offering the shortcut abbreviation with an option to to a look-up makes sense.
  • On a simple 5-way joystick, you need something different. In that case it might be a smart algorithm that looks at the number of lines the screen has (say 8), and then divides the states into 8 buckets according to first-letter distribution frequencies: “What is the first letter of the state: A-C, D-H, I-L, M [lots begin with “M”], N, O-S, T-W.” — you can even use the keypad as a shortcut. The maximum subsequent length of the menu to select the state is ten, again fitting the keypad for a short-cut.

This kind of stuff isn’t obvious. We have an opportunity to improve the basic user experience, and it isn’t being seized.

I understand Microsoft have made quite a bit of headway in their development tools for hiding these device complexity issues. But their actual influence in the real world of mobile devices seems slim outside of the enterprise. At least they deserve a pat on the back for trying — even if the motivation is classic embrace and extend of everyone else’s platform by mediating with an abstraction layer.

Once you have such UI components, and they are embedded in the devices, the developer is freed from having to worry about it. Just include a tag in your application “Insert date here”. Even better, the handset maker is freed to explore new user interfaces without having to worry about annoying the developers with custom code to support it.

What I want to see come to life are standard UI components for five essential things:

  • Specify a person or respondent. Classic address book selection.
  • Specify a place. Harder — more degrees of freedom in this information architecture.
  • Specify a time or period.
  • Specify an action. Russel’s problem is finding an action — the right app to solve his problem.
  • Specify a message or object. A more subtle one; a conversation needs you to be able to refer forwards and backwards among the messages you have exchanged across all media (e-mail, IM, voicemail, Skype, etc) or the objects you have (URLs, files). The Blackberry does this well, too.

The goal is to enable us to quickly navigate broader and deeper information architectures; and where there’s a switching point that requires richer user input to decide which branch to take, it should be as utterly seamless and device-aware as possible.

Once we’ve got these “back to basics” issues sorted, it should help invigorate the mobile handset as a communications device, and divert attention from trying to make it into a rich media device that it doesn’t want to become.

An impossible vision? I think not.

Posted by Martin Geddes at 02:25 PM
Trackback Pings

TrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/503.

Listed below are links to weblogs that reference Choices, choices:

» Just a game from Skype Journal
I can recommend this short but thought-provoking article over at The Mobile Technology weblog. In essence, it critiques mobile J2ME and BREW because they're denied access to the communications-centric functions of the mobile handset. I've long thought ... [Read more]

Tracked on July 23, 2005 02:34 AM
Comments
No comments.
Please enter your comment below. Your comment will not appear immediately -- they all go for pre-approval by me because of the volume of spam I receive.







Remember personal info?