Monday, February 21, 2005
making it easy...to make mistakes
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.
always on, always rebooting
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.
Sunday, February 20, 2005
from empathic design to empathic engineering
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 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).
Thursday, February 17, 2005
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.
Sunday, February 13, 2005
the input bottleneck
"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.
Saturday, February 12, 2005
If you think usability is old hat...
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.
Sunday, February 06, 2005
play, feedback, ambiguity
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.
Tuesday, February 01, 2005
Fitness to purpose
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.
The rise and limits of Web Apps
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