Modules and Wholes

Today I watched in horror as my friend tried to undo a mistake. (I hope he forgives me for telling this story.) Seems he transferred $10,000 in a stranger's bank account, instead of transferring the money into one of his own bank accounts. The unintended beneficiary of the transferred money had once received a small bank transfer for a purchase on an eBay-like auction site. Ever since, the stranger (we'll call him Mr. X) occupied a place of honor in my friends growing registry of accounts that had money deposited in them via online bank transfers. All these accounts conveniently appear in a drop down list. With a few mentally preoccupied auto-pilot clicks of a confirmation screen, a prudent savings account holder can do some damage.

What happened in this upsetting comedy was not, strictly speaking, a case of bad usability. There was nothing misleading or ambiguous about the screens. My friend admits: he made a mistake. Just like us humans, we make mistakes. But the system conspired to make it easy for the mistake to be made. Some people -- IBM for example -- refer to usability as "ease of use." In my friend's case, ease of use itself was the problem. Some tasks require we pay attention, and so they shouldn't be too easy. I once heard a safety consultant compare the design of cars with fighter planes. In fighter planes, designers force the pilot to pay attention and be vigilant. In cars, designers try to make driving less taxing mentally, and offer many distractions to the boring task of following the road. Drivers are rewarded with easy of use, but can be lulled into accidents.

The experience of having my computer always on, tethered to an always available DSL connection, is marred by the constant barrage of software updates that always seem to demand my attention each morning as soon as I visit my keyboard. Unfortunately, I can't tell from the message just how urgent these updates are -- will I catch the plague if I don't load them, or in the case of MSN Messenger, will my software stop working. I dismiss some, only to see them reappear again later, still asking me to load, and reboot. I didn't have this problem in the days of dial-up connections, when I had to turn on my computer each morning anyway. So I cave in and update. More warnings that I must close all applications (drats, my wife was in the middle of something on her side of the computer...) Five minutes later I'm updated, when all I wanted was to quickly check today's weather.

I understand the technical reasons why a computer must be restarted to load a new software version. But my techno-hostile side says it shouldn't be necessary. Just make sure nothing loads without my approval.

A number of people talk about empathic design -- using various techniques to learn and represent the needs of users, so that designs reflect these needs. It can take a lot of skill and talent to spot these unarticulated needs, and make them visible -- and actionable. While it's a wonderful concept, one I practice in my own work, it does have the disadvantage of adding a layer of interpretation to the process of communication between maker and user.

I have come across a couple of stories that speak to something different: what might be called empathic engineering. Instead of applying user empathy to the process of design, which carries with it baggage of translation, think empathic engineering, the melding of making and using in a single act. Wall Street Journal writer Thomas Petzinger tells the story of a company called Anadigics that put engineers in charge of selling. "Selling and engineering, in short, became indistinguishable" as "direct lines of communication emerge between once-autonomous techies and the world of potential customers that lay outside." Business guru Daniel Goldman of Emotional Intelligence fame tells the story of Ford getting engineers to spend a week with customers, instead of relying on market research and focus groups. The lesson for the engineers was to listen, and to forget about data.

Don't get me wrong: I don't think formal design research is unnecessary. In many cases, a trained researcher can spot things not obvious to the untrained observer, and the researcher can offer an fresh and outside perspective as well. But sometimes all that's needed is just a bit more communication between maker and user. The needs to be identified aren't mysterious, just not being heard by the people who need to act on them. If I'm not needed, that's fine too.

The mantra of usability research is to watch what people do, and not necessarily to believe what they say. It is common to find people who say they like something they can't use, and you will occasionally find people of a grumpy disposition who will trash something that works fine, just because they don't like the color. So why talk to users at all? Because there are many situations where you can't just watch -- designs aren't articulated enough to see all the steps involved, or because there are tangential issues entering the situation that are not visible to the moderator.

The standard method for listening to users is the talk-aloud protocol, getting a running commentary from the user on what she or he is doing. It's valuable when tied to observing a specific activity, but doesn't address past situations or outside events that can't be observed.

From the world of medical social research, which has vast experience in developing reliable information from interviews, comes a useful technique called "cognitive interviewing." The approach addresses the many biases that can creep into facilitators' questions and users' responses. Taken to heart, the approach offers a path for usability researchers to develop to a dialog with users, instead of making lab rats out of them. Gordon Willis, a pioneer in the technique, will shortly publish a book on the topic. For a preview of the approach, consult his cognitive interviewing "how to" guide (pdf).

People hate urban sprawl because it's ugly, inefficient, causes inconvenience, and reflects poor planning. One might usefully think of a desktop equivalent to urban sprawl: the "scattering" of information across applications, and the "cluttering" of the screen with pointers to that information.

In an interesting paper, Views on views (PDF), Ariel Shamir explores how to solve the scattering and cluttering problem. His solution involves inviting users to create personal, subjective tags for file items, to escape the serious limitations of PC folder systems without relying on formal or machine generated metadata, which I feel only appeals to database managers, librarians and other fussy, hyper-logical people.

Personal information managers have never been that successful, but their need has never been greater. Some might object that personal tagging is labor intensive and therefore unappealing, but I'd argue that's what allows the information to become personal, instead of being just more stuff filling a hard drive. The approach has some positive similarities to qualitative/ethnographic coding software packages, such as Atlas-ti.

If you want to do anything more ambitions than point at menus on a small gadget, you generally face problems. Some interesting interviews in the January Laptop magazine explore how we'll break through the input bottleneck. Dave Blakely at Ideo says:

"If I were to name one thing that will really benefit users, it's natural language processing. Faster chips and improved software will help your phone understand what you are saying and all these problems with navigating through complex menus on tiny screens will disappear."

I've heard people hyping NLP a while. It has improved, but it still seems a long ways from consumer-ready.

Hartmut Esslinger of Frog Design seems to agree with me, but suggests something equally unrealistic:

"Voice is a problem. I think ultimately it will be gestures. If you look at how we communicate, each healthy person talks with the hands. I think gesture will be a big point, to direct and play with the hands. That's one piece that's coming."

From what I've seen coming from the eminent HCI labs, which are lavishing money to research gesture-based interfaces, I don't see any solutions that will be ready for mobile consumer devices in the near future.

I'm not an expert on the latest in these areas, so maybe I'll be surprised.

I often come across essays that argue that even if at one time usability was once not sufficiently addressed, those days are past: it's time to get one with more cutting edge issues like "design for seduction" or "sensory-centric mediated experiences" or some other goovy angle.

Indeed, usability has improved remarkably on the web over the past decade, but I can still be shocked how bad it can be in 2005. Here is a site that in theory should know better, from the techno-geek publishing giant CNET.com. A first glance would suggest there is useful information available on the site, but in reality it is one of the worst sites I've ever encountered. The site spits out results indiscriminately, the user has no control over how to locate things and navigate, and one can't tell "editorial" content from blatant advertising. What one sees after clicking is completely random. As backend software becomes more powerful, the dangers to users of bad usability escalate. Usability will be a "solved" problem only when software stops innovating, which is still some time from now, I reckon.

I've starting reading a book that's been on my shelf a while now: Brian Sutton-Smith's Ambiguity of Play. I've long been interested in phenomenological issues (e.g., play, imagination, meaning), which factor in both design and daily life. I discovered Sutton-Smith, one of the leading authorities on play, did his earliest research, some fifty years ago, in New Zealand (together with Brazil a world capital of play), which gave me a new incentive to read the book.

Play has gained iconic status following the writing of Pat Kane and the new game-theorists. I am not so interested in play as the new panacea for dull work. What does fascinate me is how contradictory play is.

Consider the hugely popular notion of "Flow." A central aspect of Flow is having immediate feedback to see how one's performance is going. Even the driest writings on quality control mention the importance of immediate feedback, zeroing in on the target. Be it a tennis game, an X-box shoot-up, or a factory floor simulation, people enjoy fine tuning their maneuvers. Some less imaginative commentators suggest we should package all life experiences into joystick-controlled computer games to make "learning" fun.

As reflected in the title of his book, Sutton Smith explores the more paradoxical side of play: ambiguity. Sometimes feedback in an exploration isn't immediate. In complex systems, the feedback may show up later, sideways. Delayed, perplexing feedback is not a recipe for Flow as it is commonly understood. Indeed it can cause angst among many. In business this ambiguity is known as uncertainty. If one has a low tolerance for ambiguity, one doesn't have much fun. But others embrace ambiguity, uncertainty, the creative power of lady luck, and do have fun, despite the lack of instant, directed feedback (where is it is obvious how one is off-target.) All this seems like it could be related to discussions around fast and slow time. (If patient people had a higher tolerance of ambiguity, they might have a better appreciation of ambiguous play. But entrepreneurs are often ambiguity-tolerant and impatient; some have loads of fun, though others just seem frustrated.) But that discussion will have to wait for another day.

Interesting to compare adaptation in nature -- fitness to purpose -- with usability's fitness to purpose. I recent bought a wind ornament of a Pukeko, an interesting New Zealand bird. An interesting quote from Charles Douglas, a 19th century explorer, that came in the box:

The Pukeko can fly, walk, dive and swim, but can do none of them tolerably well. It flies with a contorted, jerky motion, but only for a short distance, alighting on any tree handy, and staggering among the branches as if intoxicated. It walks as if troubled with corns, and running it often stumbles. When swimming it looks like a domestic fowl tumbled in a water butt and wanted some kind friend to rescue it. It's diving is still more absurd....It goes down, with a disordered splutter of legs and wings, coming up at once with a jerk like a cork.

Imagine designing an interface that managed to do everything, but nothing well. Sounds like Microsoft. They are still around, too.

How frequently a word is used is an important part of how clearly a message is understood. Frequently used words are generally better understood (as long as the word doesn't have too many potentially conflicting meanings.) I know from studying foreign languages how useful it is to know the frequency a word appears. In university I worked my way through a list of the top 2000 Chinese characters. But for a native English speaker, this information is often buried in linguistic databases. A more populist approach is offered by WORDCOUNT / Tracking the Way We Use Language /. I would like more functionality on the site, more integration with other ways of viewing a word (such as related concepts), but I still think it is an intriguing idea.

Web app design is a hot topic, with a good book published recently, Web Application Design Handbook : Best Practices for Web-Based Software.

I love the fact the web is getting smarter and more dynamic. Sadly, it seems there are some limits to have far this can go. Joel Spolsky, interviewed in Salon notes:

The other problem is the richness of the user interface. If you want
to make an application like, say, Photoshop, doing it on the Web would really suck. But there are ways you could consider making that happen. If you could have billions of gallons of Javascript, and if the Web browser gave you simple drawing capabilities and a simple canvas to draw on, then you could implement Photoshop 100 percent in Javascript. Trouble is, it's a lot of code, and Javascript is not an efficient language; it's not fast, and for security reasons, it's actually hobbled in all kinds of ways that people don't even know about. For example, by the time you give it about 500,000 Javascript statements, the Web browser just turns it off.