Zombies, Expertise, and Post-Apocalytic Scenarios

A lot of things kind of converged yesterday. I had lunch with my friend and colleague Miranda Bennett, and she was excited over a new game--lousy UI but engaging premise. Apparently you collect pieces and build a fort-like structure and then zombies come out to get you at night. I'm not a gamer, but I commented that zombies were a popular construct these days and wondered why. Miranda posited it was less about zombies and more about surviving in a post-Apocalyptic world. Hadn't thought about that. Most zombie movies do have that theme.

Miranda went on then to observe that people are being taught that they don't know how to cook (as she nuked her prepackaged lunch). She pointed out that even the simplest dishes, such as baked chicken breast, come prepackaged and pre-prepared. Add to that the other ways technology has embedded expertise into our tools, e.g., spell checker, calculators, etc., and no wonder we view post-Apocalyptic scenarios with horror--we will be helpless. Maybe the zombies are just metaphors for our atrophied brains--that would account for their craving to eat brains.

All this on the same day I received my author's copy of Qualitative Research in Technical Communication, edited by James Conklin and George Hayhoe. At long last, the findings from my doctoral research got published as Chapter 14. In it my major professor, Tom Reeves, and I discuss the role of experts on usability teams. They can streamline the process and even improve the results, but at a cost to team learning. We rely on experts and take them at their word, sometimes deferring our own critical thinking and creativity.

As user assistance tries to take the role of expert (see my article on User Assistance in the Role of Domain Expert in UXmatters) how do we avoid contributing to post-Apocalyptic impotence (PAI--I just made that up)?

I think the answer is simple, expertise should be about transferring insight and not about dictating steps. It should enrich the question so the user can wrap the answer in his or her own context and data. That way the user is enabled and not just directed. See my column in UXmatters Making the Deal: Supporting the Demo with User Assistance for a practical example.

Odd First Sentences

When I read my title, I was reminded of the Stephen Wright joke, "I got in a terrible fight at the roulette table with the croupier over what I considered to be an odd number." (It occurred to me as I read the title that all 1st sentences are odd--literally.)

OK, so I'm reading an article in American Rifleman (not mine, someone left it laying around at work) and the opening sentence is "It's surprising how many of our most useful and reliable cartridges started in the military."

You gotta wonder what is so surprising about that. I don't know much about guns and ammo, but if you came to me and said you needed something good in that line and asked my opinion about where to go, I'd probably come up with "See the Army." That's what they do, they shoot at people and they try to do it accurately and with great effect. They should know.

About 35 years ago I picked up a copy of my company's employee newsletter, and there was an article profiling one of the employees. Its opening line was "Bill certainly fits the mold of 'he's one of a kind.'" If he's one of a kind, why is there a mold? The sad part is that we were a manufacturing company, you'd think we would understand the concept of a mold.

And now a bit of a bonus, the original line that inspired the Bulwer-Lytton award:

"It was a dark and stormy night; the rain fell in torrents--except at occasional intervals, when it was checked by a violent gust of wind which swept up the streets (for it is in London that our scene lies), rattling along the housetops, and fiercely agitating the scanty flame of the lamps that struggled against the darkness."

 --Edward George Bulwer-Lytton, Paul Clifford (1830)

Note that its claim to infamy has more to do with the length and rambling nature, not the inherent badness of its oft abbreviated version, "It was a dark and stormy night." Had he left it at that, I think it would have been right up there with "Call me Ishmael." Hmmmm. Maybe I'll do a sequel to Moby Dick from the perspective of his girlfriend. Opening line: "Call me, Ishmael." (Apologies to Lynne Truss)

Three Myths

When I hear people talk about not getting respect for being a technical communicator (or not getting paid enough) I wonder if the following three myths are holding them back:

• Thoroughly described = adequately explained
• Accurate = useful
• Grammatically correct and correctly punctuated = well said
  

These are the "writer" myths, based on the belief that the value we bring is our ability to write. Technical communicators should be "sense makers" and "explainers." We should deliver timely insight that enables the user to act more like an expert.

Easy words to pen; hard ones to live up to.

Dashboarding

I'm reading a lot about dashboards these days. What a fun challenge in technical communication, trying to put ten pounds of information into a one pound UI.

I'm reading Stephen Few's Information Dashboard Design, and he makes the most elegant points:

Reduce the non-data pixels:

• Eliminate all unnecessary non-data pixels
• De-emphasize and regularize the non-data pixels that remain

Enhance the data pixels:

• Eliminate all unnecessary data pixels
• Highlight the most important data pixels that remain

He also had some interesting things to say about pie charts, as in basically they all suck. His point is that human perception cannot compare 2-D areas as well as other visual attributes such as length. He suggests that bar charts make better comparison graphics than pie charts.

So I'm trying a little experiment on myself. I keep a time sheet in Excel so I can track where my time goes (plus I find that recording my activities makes me way more productive--try it some time). I've been keeping a little pie chart dashboard on the sheet so I can see how my time gets allocated. It seemed useful to me.

So as an experiment, I've added a bar chart of the same data.

Here is the pie:


Here is the bar:


Jury of one is out on this. What's your opinion?

Menu Blind Spot

I'd write this one off to stupid user (moi) except that I saw it a lot when I was a usability tester. I wanted to change presentation colors in my email client. I was pretty sure I did that in Tools > Preferences. It is important to note that my opening assumption, I repeat, was that I would find it under Tools > Preferences. I clicked on Tools.


I couldn't find Preferences.

After some frustrated head scratching wondering where they would have put it, I saw it.

I would see the same phenomenon in usability tests with drop down menus where the top choice was preselected (reverse video). Humans process a list like this:

Top item set off typographically in some way = column title and is not a choice; therefore ignore.

The reversed video selection became invisible as users would scan the not-highlighted choices under it. Because Preferences is a single entry and is underlined, I think I processed it the same way.

These mental shortcuts usually make us more efficient--but sometimes they get in our way. As designers, try to avoid making the top choice different in any way.