The Skills We Need as HCI'ers

When I got full-time into HCI, it wasn't with the intention of writing code or picking site colors. I like the psychology and IA stuff a lot better, and even the worst CS students are far superior programmers compared to me. I'm attracted more to the social aspects of technology usage. Few of my HCI brethren seem to come from the web design end of the business. There are programmers, sure, but they tend to be more hard-core, writing software rather than web scripts. Yet, job descriptions for usability people are often hybrids of usability and true web design. Companies don't seem to care if we can do card sorts or usability tests. They want us to program.

Flash is a popular requirement, but there are even more likely items on the corporate wish list. .Net is a favorite, ASP.net , VB.net, or C#. Java has made good inroads, too. Javascript, of course. HTML is a given, but XML is coming up fast. It's tough to know if a company is looking for an HCI pro who can program a little, or a programmer who can recognize horrible usability when he sees it.

I have to admit that at one point between gigs I began looking again at ASP.net, on the advice of Ed Sullivan, a feisty and knowledgeable guy from IUPUI who assured me that an ASP.net programmer would always have a job. It still didn't trip my trigger, but the fact that I was diverting my attention in a direction I never wanted to go is indicative of the state of HCI at the moment. Are we non-programmer HCI'ers at a disadvantage, compared with the ASP.net crowd and New Media grads? Maybe. Depends on where you are in the country, maybe. But around here, I think for sure we're having more trouble justifying our existence.

Users Cannot Prognosticate

One of the favorite usability techniques by the uninformed is to sit a prospective user down in front of an almost-finished application and ask "So...how do you like it?"

This is wrong for at least two reasons. The first is the "New Coke Mistake". Older readers will recall that the Coca-Cola Company's New Coke was released in 1985. It was a sweeter, sprightlier formulation prompted by the enormous success of the Pepsi Challenge, a nationwide taste test that legitimately proved Pepsi to be a runaway favorite of test-sippers. But Coke made a huge mistake by equating sip-tests with long-term purchase and usage. Even hardened Coke drinkers didn't like the sweeter Pepsi, can after can. They wanted their old Coke. The taste tests had panicked the suits at Coke and led to a disaster of such proportions that the whole episode is still taught in marketing classes today.

The second reason is more subtle. It results from our human inability to anticipate. We like to think we're good at anticipating things. What else is a cerebrum for? But in study after study, we humans show a remarkable lack of prognostication skills. We can't correctly predict what we'll like or dislike later, what kind of gifts we'll want down the road, or what we actually do in a crisis. We do very poorly predicting how we'll respond to emotional events. Nor can we reliably predict how we'll like something later that we've just now seen. In actual fact, our conscious mind isn't all that conscious of things, either those things generated within the skull, or from the outside. Drunks aren't aware that they're impaired, for example. Cell phone users insist their reaction times are unaffected while driving, when research plainly shows that reaction is very much diminished, turning 20-somethings into senior citizens. Marketers have repeatedly found to their chagrin that products proposed to focus group members and enthusiastically embraced at the time often fail to catch on when they're actually sold.

That's not to say that focus groups or interviews are useless. They're not, but they're best used for eliciting information about the now, not in anticipating how they will be or feel later. It's almost never worthwhile asking participants to foretell the future.

My Cell Phone, My Death

I've been interested for some time in the hidden cognitive costs of talking on cell phones. I've found that almost nobody believes that their driving is impaired while chatting on a mobile, but the evidence is absolutely unshakable. It's been going on for years. I happened upon an article in Chance magazine from 1997, where the authors provided very strong statistical evidence that individual crashes were closely linked to cell phone use, but it took David Strayer and the University of Utah to actually measure reaction times and prove that cell phone use effectively turned 20-somethings into senior citizens while driving. It's purely a cognitive thing; using a hands-free set doesn't make any difference. Talking with a passenger doesn't have the same effect. Strayer's research shows that using a cell phone degrades change detection.

Of almost equal interest is the refusal of most people to believe the research. We're not conscious of much that happens within us, despite the belief that we are. I find that my usability class students are uniformly indignant at the suggestion that merely talking on a cell compromises their ability to drive. The attention blindness, however, it works, that envelops us during that time is not consciously evident to us. Hence, we remain oblivious to the danger.

The 1997 Chance article by Redelmeier and Tibshirani (cited by Strayer) detailed the meticulous analysis the authors did to conclude that individual car phone users were some four times more likely to crash compared to non-users during crashes. But they also examined why, if the chances soar so dramatically, that the overall accident rate hasn't also risen dramatically, which might by itself make cell users give up the devices while driving. They found that although cell phone use would indeed boost an individual's chances for an accident, the chance of an accident at all is so low that in the aggregate cell phone use doesn't raise the population's rate much at all. Cell phone calls are generally of short duration, which further reduces the overall effect.

What's REALLY Screwing Up Usability

After a considerable period of experience, I have come to the conclusion that most websites suck more because of lousy navigation than from bad controls placement, poor color choices, small text sizes, or anything else related to layout. I've found that users will forgive and use almost any interface mistakes, if only they can find what they're looking for. Poor navigation has left more users looking as confused as goats on Astroturf than any other single cause.

Now, it should be noted that this general rule applies more obviously to information-storage sites, not so much to interactive sites. But even if the emphasis is on interactivity, knowing where to go next in a sequence of steps is only a variant on where to go next to find materials.

It's for this reason that I wish HCI programs put more emphasis on information architecture. Many HCI'ers, even those with grad degrees, can't do card sorts or affinity exercises, nor perform cluster analysis. They have no clue about taxonomies, ontologies, or thesauri. I'm finding that the ability to organize whole site logically is both science and fine art, and deserves more class time than it's getting.

Life Poses Usability Problems

As if life didn't have enough usability problems, Second Life is apparently even worse. Over at Meta Versatility, there's a nice blog note about Second Life's usability difficulties. Linden Labs has engaged Adaptive Path to clean up the interface.

Building Levels and Websites

Stewart Brand, the author of "How Buildings Learn" is a proponent of the layered theory of time and space. In buildings, for example, he identifies six levels: site, structure, services, skin, space plan, and stuff. The site is the basis for everything else. It's the lot, the foundation, the ground underneath. It sets limits for everything else. The structure is then the load-bearing part of the building, and sets still more limits for further construction. The skin is the outer covering, and services are the functional parts of the building, the electrical, water, heat, elevators, and so forth. Space plan is the movable walls within, and stuff is people, furniture, and other readily-moved items.

In this view, each layer has its own time cycle, and woe betide the building owner who ties them together or makes them move too quickly. The stuff can change daily, while the space plan typically changes in two or three years, or perhaps more. The skin may change only once a decade. Services longer than that, and the site almost never. He counsels strongly against tying the various levels together, such as built-in furniture, because it forces levels with inherently different time-scales to stick together, creating (in the case of built-in sofas, tables, or chairs, for example) either radical surgery on the space plan or tolerance of out-of-date furniture.

I think this structural metaphor can be applied to portals and websites, and it can help us understand why some sites always seem to give us trouble. Of course, the absolute time-scale has to be reduced for the IT world, but the relative splits in levels seems to hold.

Try these equivalents:

Site = Server hardware and underlying base code, such as portal
Structure = Information architecture
Services = App code (portlets, Javascript, etc.)
Space plan = Links, portlets, pages, actual "places" that are delineated from one another
Skin = Appearance (CSS, colors, layout)
Stuff = Content (text, news items, and so on)

From this perspective, it can be seen why CSS is such a good idea -- it isolates the skin from the space plan and the stuff, giving us distinctly different time-scales for them. But there is also a caution here, that changing a space plan too often, for example, because the stuff changes, is a mistake. And in the Web world, the skin is generally replaced more often than the space plan, but they are often replaced together, too. Is this a mistake? Is novelty so important that we have to mess with the user's comfort levels?

I may not have the right Web components identified with the right building metaphors, or the whole comparison may be futile. Look through Brand's book and tell me what you think.

At Last I'm a Lert

As the saying goes, "Be alert...the world needs more lerts!" I'm contributing my share.

I've discovered Google Alerts, and I'm using it to watch for some terms. Google Alerts lets you know when something is published on the Web that matches your keyword in the Alert. I, for example, am using three alerts: my name, "usability", and "information architecture".

So far the results have been mixed. I've caught a couple of references to my old books, which is exceedingly gratifying. And I've caught a few good blog entries here and there about my professional subjects. But a good many notifications are less than intriguing. Signal-to-noise definitely trending toward noise, but infinitely easier than doing tedious, full-out Google searches to stay current.

A REAL Man-Machine Interface

I see they're shutting down the PEAR, the Princeton Engineering Anomalies Research laboratory. After some 30 years of generating controversy and reams of odd data about telekinesis, the PEAR is closing up shop, done in by exhaustion and time. Opened in 1979, the lab explored whether humans could change physical events with just the power of mind. Turns out, as the lab concludes, they can, but only very slightly, something like 2 or 3 events out of 10,000.

Research into the paranormal isn't what it once was. The Psychophysical Research Laboratories (PRL), also located in Princeton, shut down. Duke University's Parapsychology Laboratory, perhaps the most famous of them all, spun off its parapsychology work into the now-independent Rhine Research Center. It's named after Dr. Joseph Banks Rhine who invented those famous cards while at Duke. Interest in the paranormal appears to have peaked many years ago, and now even the scientists who had high hopes for actual results may be drifting away.

But the PEAR was interesting to HCI'ers because it focused on telekinesis, controlling things with thoughts. If telekinesis could be shown, then it might be possible to change the TV channel just by projecting a thought in that direction. Sadly, the prospect now looks bleak.

Usability in Disaster Relief

Just as I published a self-congratulatory posting about my own article in ACM's Interactions magazine, I got to read several articles in the March issue of Communications of the ACM about the HCI of disaster relief. Fascinating stuff. You can see the TOC on the site, although you can't read the articles unless you're an ACM member.

The technical challenges of breakdowns, weather, and moving to stay safe and dry are joined by the problems of designing exceedingly hardened systems ahead of time that will function when the hammer falls. Interactivity is a big issue, of course, but so are the human frailties that kick in during disasters. Reading about the work being done makes me feel a little sad that I'm not involved in such noble work.

Usability as Risk Management

Keep an eye out for the March edition of ACM's Interactions. I'm supposed to be in it. Pays to be humble, no?

The article deals with a mechanism I developed when I worked for a consulting company. We constantly have problems convincing our employers and clients to use usability techniques. But why force the issue? Why not let the brass decide by putting the decision in their language? That's when I started doing risk analysis of new online efforts, using usability factors. I get the business stakeholders of a new website, intranet, portal, or whatnot into a room together and spend some time quantifying how bad things could get if the initiative fails, and then out of that comes an index of risk. Using usability techniques can reduce the risk, but they're expensive. The use of techniques must be matched to a risk level, because otherwise usability won't be included in the project plan.

If you can lay your hands on a copy, let me know your opinion.