Cambio

I never used to be particularly interested in designing mobile applications. I just thought it was a hopeless platform, plagued by tiny screens and keys that were designed for inputting numbers (how often do you actually type numbers into your phone?) I also had never thought of my phone as something that I want to use for various applications. This scepticism had become so ingrained that I initially didn't even see much point in Apple opening up the iPhone for third-party developers. I thought it might destroy the purity of this well-designed platform if developers were suddenly given reign over users' mobile screens.

However, two months ago or so, a certain curiosity, a thirst for a new challenge and a feeling that I was missing a boat (to where I did not know) combined to make me go out and buy an iPod touch (I don't want to buy an iPhone because my current phone deal is too good to give up). I almost immediately appreciated both what a well-designed platform it is and what a compelling playground the third-party application market represents, for users and developers alike.

The science of keyboard design

The Handbook of Human–Computer Interaction, edited by Martin Helander, Thomas Landauer and Prasad Prabhu, is a book published in 1997 that attempts to summarise research relevant to the design of interactive software and hardware. Its 62 chapters fill 1500 pages and provide advice on a multitude of topics, covering analysis, design and evaluation of interactive systems, as well as the psychological and ergonomic underpinnings of human–computer interaction. One of those chapters is titled Keys and Keyboards and was written by James Lewis, Kathleen Potosnak and Regis Magyar. It considers virtually every imaginable factor involved in designing keyboards, and, by drawing from experimental studies, provides recommendations for each of them. Ever since I read this chapter a couple of years ago, I've been meaning to summarise some of their conclusions and to consider them in the context of modern keyboard design. The recent string of keyboard-related links on Daring Fireball (e.g. here, here, here, here, here and here) moved me to finally sit down and do it, so here it is.

The Non-Wheel iPod

Whenever you see the rumoured next-generation video iPod mentioned, the expected features always include a huge screen covering the front of the device and a “virtual”, touch-screen-based click wheel.

I may be missing something here, but what exactly would be the point of that? The reason the iPod has a scroll wheel is to make scrolling easier on a device that doesn’t allow more direct manipulation of screen content. If you had a touch screen, the grounds for having a scroll wheel would disappear, and you could just use a scroll bar, right? A scroll bar would allow scrolling directly to any point in a list and would involve less (and less awkward) physical movement.

Also, if you had such a nonsensical, virtual scroll wheel, you’d be waving your thumb around over the contents of the screen all the time, which doesn’t sound like a clever idea. Of course, you could dedicate a section of the screen for this wheel, but wouldn’t you rather use that space to make the list taller?

So I think either the creative minds behind the rumour sites didn’t think this one through properly, or the creative minds at Apple are making some rather silly decisions. Let’s hope it’s the former.

The Grand Unified Download Manager

Since the introduction of Mac OS X, Apple has been doing a great job of offering more and more functionality at the operating system level that application developers used to have to implement themselves. Spell checking, Address Book, Keychain, Dictionary, disk burning and PDF support are some good examples. Almost everyone wins when this happens: users get a consistent experience and are less dependent on particular applications, and developers have less work to do and can simplify their application code. The only ones who potentially lose out are developers who had seen the gap and were actually trying to offer such a service to other applications, like, for example, Nisus Thesaurus or Adobe Acrobat Distiller.

When I recently saw this post on the Omni Group forums by Jon Hicks, I saw another perfect candidate for Apple to assimilate: the download manager. As it stands, at least six applications on my machine implement their own download managers: OmniWeb, Safari, Firefox, Camino, NetNewsWire and Transmit. And, as Jon pointed out, they all have different UIs.

So what would such an Apple download manager have to offer? It would of course need to support the most common protocols, including HTTP and FTP. (Perhaps even BitTorrent and Gnutella? Maybe not, since Apple wouldn’t want to make life any easier for those not using the iTunes Music Store.) Pausing and resuming downloads would be a must, too. The interface would need to offer enough functionality to compete with most browsers, but be simple enough for the non-geek.

Out of the applications mentioned above, I personally like OmniWeb’s download manager best, because it has a toolbar that offers some useful commands with a single click, like “abandoning” (clearing and trashing) a download. Also, all its commands have text labels. It doesn’t present any puzzles and coordination exercises in the form of little grey circles and pop-up buttons. However, I do like how other apps have managed to be more horizontally compact by putting the progress bar on its own line below the file name.

Again, someone might lose out if Apple were to offer an OS-wide downloading framework. If it offered enough functionality, it could be developers of apps like Download Wizard, iGetter and Speed Download. But, speaking with my user-hat on, I’m afraid I wouldn’t care.

Have they never heard of scrollbars?

When Apple introduced the iTunes Music Store, one thing I hated about it straightaway were those views that have left and right buttons to page through a list of albums. At first I thought it was forgivable, given that the iTMS is more like a web site than a rich client interface. But after a short while I noticed that my eyes had become conditioned to move after clicking those arrows, trying to follow the animation. The problem is that they would never be in sync with the actual animation, especially since there's always a delay, which conjured up my old friend, motion sickness. I've now actually developed a habit of looking away right after clicking the arrows, and look back only after the animation is over.

When Tiger arrived, I was shocked to see the same awful paging view used in the Dashboard when you're adding widgets. The delay there is not nearly as bad as in the Music Store, but why on earth would you not use scrollbars for something like this?

It baffles me how Apple, out of all companies, keeps throwing decades worth of interface design wisdom out the window. They've done it with window title bar controls, with the Dock and with the Mail toolbar, to name just a few obvious examples. Jef Raskin once said that instead of interface architects, Apple has been infested with decorators. I think he had a point.

Scroll-ahead

Although scrolling on the iPod is famously easy compared to other music players because of its wheel, it still has one problem: when scrolling quickly through a long list, for example all your artists, you are very likely to shoot past the artist you want to select. So the typical procedure is:

1. Scroll down quickly until you see the desired artists whizzing past.
2. Scroll back up more slowly until they re-emerge at the top of the screen
3. If you missed them again, scroll down one or two rows until you've finally got them.

The basic problem is that most of the time while scrolling, the selection is right at the top or right at the bottom of the screen, meaning you need superhuman reflexes to stop in time when the correct artist's name appears.

A solution would be to keep the selection near the middle of the screen (unless you're right at the beginning or the end of the list, of course). That way, you can see a few rows ahead while scrolling, because your artist's name will become visible just before it becomes selected.

I sent this as a suggestion to Apple a while ago, but I'm not too optimistic about who actually gets to read what's sent through their feedback page.