Designing for Multitasking

For the past two decades, interaction designers have been designing the equivalent of digital hammersreally nice hammersthat do the task at hand (hammering digital nails) but not much else. Our digital tools mostly perform single tasks when they could be multitasking: collecting data about how they are being used and by whom, subtly adjusting themselves to become more personal and more useful.

For humans, multitasking can reduce the quality and quantity of work, but computers mostly don't have this limitation. Most of the time, our computers, mobile phones, and digital appliances sit idle, waiting for a command. Most processing time between keystrokes and cursor movements passes unused. Our computers, mobile phones, and electronic devices are ridiculously powerful now, thanks to the fulfillment of Moore's Law (see Chapter 3), and are starting to contain more memory space than most of us are likely to use. Why shouldn't our devices use this spare memory and power to gather data about our behavior and optimize themselves based on that?

Thanks to increased processing speed and memory, computers and other digital devices can register and record our behaviors like nothing elseexcept perhaps royal manservants and private detectiveshas ever done. And yet, for the most part, devices either don't capture this information or don't use it well. Sure, the occasional site welcomes users back, and your mobile phone remembers whom you last called, but these behaviors are pretty rudimentary.

Most digital devices and applications have no sense of history, but history is information that can be gathered and acted upon. If every time you visit a Web site you go to the same page, chances are good that when you visit that site again you'll want to go to that pageand the site or the browser should somehow acknowledge that, either by simply taking you there or in some way making it easy for you to get there. In 2002, the BBC's online site, BBCi, was redesigned to accomplish just that (Figure 7.1). As a user makes repeated trips to the site, a path is worn through the home page. Sections the user visits frequently slowly become visually distinct via a darker shade of color. Thus, it is easy for return users to find the sections they visit frequently. The site collects data about a user's behavior and then adjusts the site to make it more useful for that user. BBCi called its redesign The Glass Wall.

Figure 7.1. BBCi redesigned its site so that users wear personal paths through it. The left screen shows the original palette, the middle screen shows the screen after several visits, and the right screen shows the palette of a frequent user.

courtesy of BBCi

Amazon understood this in 1996 and, despite its current cluttered pages, still gets some things right, such as showing users where they've been recently (Figure 7.2). Amazon famously, of course, goes one step further, comparing individual user's data to the huge pool of data collected from all Amazon users, showing the "People who bought this also bought..." plus the really interesting "What do customers ultimately buy aft er viewing items like this?" items. Amazon, naturally, has a motive for doing this, but this additional information, this added value for the users that the users did nothing to obtain except perform their usual shopping tasks, is one reason why Amazon has succeeded brilliantly while so many other online retailers have gone under.

Figure 7.2. The Amazon Web site multitasks constantly, comparing your data to other users' data.

BBCi and Amazon made completing tasks in the future easier and more interesting for users, and that's something worth designing. Note, too, that users don't have to set preferences or tell either of these sites what they are interested in doing. The sites learn this from behaviors their users are already engaged in. The onus isn't on users to customize their experiences; the sites themselves are smart enough to do it. They multitask.

Another important point about these sites is that the changes are subtle and appropriatethe sites multitask and adjust in ways that users appreciate. Microsoft's infamous Clippy ("It looks like you are writing a letter!") is an example of unsubtle multitasking. Although the feature was meant to be helpful, it quickly (read instantly) became annoying and intrusive. Yes, I'm writing a letter, but I can format my own letters, thanks. This "help" isn't appropriate because typing a letter isn't a difficult task that most users have trouble doing on their own. Clippy's "help" isn't helpful at all; it's intrusive and demeaning. Which brings us to another key point: multitasking should be appropriate, meaning that it should help users do the things they could never do on their own, or things that would otherwise be tedious to do on their own. Individual users would have no way of knowing what other users bought unless Amazon told them. Similarly, users could keep track of the various sections they visit at BBCi, but it is much easier and certainly much less tedious to let the site do it.

Here is another example of the use of the history of a user's behavior. I frequently misspell the word ubiquitous, always adding in an extra i at the end: "ubiquitious." There's no reason why, after one correction of this word using the spell checker, I should ever have to spell check this word again. The application should record this data ("My user misspells ubiquitous") and auto-correct it the next time I misspell it. After all, how many words could I really be spelling? And since my word processor runs on a computer that is connected to the Internet almost 24/7, there's no reason why this little bit of data couldn't be shared among other users of this application, so that if other people misspell ubiquitous with an extra i, the application can correct them as well.

Note

Obviously, when collecting information based on user history, privacy issues arise: what data is being shared and how easily can that data be traced back to individual users? Suppose, for instance, I am frequently misspelling the word diarrhea. Would I want that shared? Or traced back to me? And just what kind of documents am I writing here anyway? Designers of applications and devices that multitask must be hyper-aware of what data users may not want collected or shared, and users should always be able to opt out of the collecting or sharing of any personal information.

Now imagine tools that can self-correct based on data about how they are being used. Suppose that users are having trouble clicking a button to submit a form. If an application is aware enough to notice where, when, and how clicks are being made, it can move the button or increase its sensitivity for the individual user, and even potentially for all users, if the application notices the same behaviors happening frequently enough.

Of course, data doesn't have to come in only through a user. Devices and applications designed for multitasking can collect information about not only how, but also where and when they are being usedcontext and environment also can be inputs to applications and devices. This information can then be used to improve the product. Why, when I turn it on at night, doesn't my iPod automatically turn on its backlight? It has a clock built into it, so it should (or could) be aware of the time. I'm likely to need the backlight at night, and when I don't, I can always turn it off.

Likewise, why doesn't my e-mail client adjust itself to check for e-mail more frequently during working hours than on weekends? Again, it has a clock and calendar built into it, so why not leverage those? There is no reason that, when my laptop is idle, my e-mail program couldn't analyze my usage patterns and adapt to me.

There is also no reason that devices and objects can't perform complementary tasks at the same time. For example, my car, while taking me from place to place, could also be sensing and reporting the traffic conditions. Factors such as the speed of the car could be used to determine whether traffic is flowing smoothly, and that information could be shared with car navigation systems and maps such as Yahoo's traffic map (Figure 7.3).

Figure 7.3. Imagine how much better Yahoo's traffic map would be if the data was an amalgamation of information coming from cars on the road.

Instant-messaging clients perform complementary tasks well with their inclusion of status messages in their buddy lists (Figure 7.4). Rather than simply showing that a user is online, idle, or away, status messages turn the buddy list into another means of communication. For many, especially teens and young adults, the status message is now as important as the instant messages!

Figure 7.4. Adium's buddy list. Status messages take what could be just a simple conveyance of information and turn it into a whole new channel of communication.