Thursday, August 30, 2007

The 90 Seconds Rule--
In my previous blog I talked about how users can only stand being in Help (and away from the task they would rather be doing) for about 30 seconds. Nice, round number.

Another rule I find useful is the 90 seconds rule: Users will struggle on their own for at least 90 seconds before going to Help. So don't waste your 30 seconds on something the users will discover on their own in their 90 seconds.

For example, a product I work on has a table of firewall rules, and the user can change the order of the rules by selecting a rule and then clicking either an up or down arrow on the UI. Well, this is a fairly well-used and well-known convention to most software users. But even if it's brand new for some users who want to change the order of the rules, they will figure it out in their 90 seconds of fumbling. How long will a user sit there looking a rule that's too low in a list without saying, "Hmmm, I wonder if this up arrow does anything." So I spent my 30 seconds giving tips and guidelines about when a rule should be higher in the list and when it should be lower.

But what about the poor user who doesn't figure it out? I still documented it as a note in one of my tasks. I just didn't create a big procedure about "Changing the order of the firewall rules."

So another way to keep your Help files lean is to focus on information that the user will not be able to get from experimenting on the UI (which is exactly what they do before going to Help).

Monday, August 20, 2007

The new research primer is here, the new research primer is here...
Older readers might remember the Steve Martin movie "The Jerk." I love the scene where the new phone books arrive and Martin, as the title character, is ecstatic to see his name in print for the first time. Well, the book that I coauthored with George Hayhoe arrived at my house last Friday and the scene was pretty similar. Not the first time in print, but it is the first time my byline made the cover. It's even on Amazon.

It's always the same for me anytime I get something published. Instant thrill (oh boy, time for my 15 minutes of fame) followed by disappointment (oh no, I should have done a better job than this). I'm getting better at staying centered and balanced. The thrill used to be "Oh boy, I'm famous." I realize now that we are all famous, some just more so than others, and even the most lasting of fame is still only temporary. And I know that perfection is a fool's target. I'm content now if my output is good enough to do someone some good. I hope this book helps a student who is overwhelmed by having to do a research project, or some practitioner who would like to be a more critical consumer of research. I hope it helps shape research agendas that define our practice for the better.

As Buddha said: Before enlightenment it was chop wood and carry water; after enlightenment it is chop wood and carry water. OK, I've got a research textbook on my shelf with my name on the cover; time to get back to work on the Help file I'm writing that tells users how to back up their log files.

Still, it's a lot of fun to see my name on the cover of a book, and oh, I wish I had done a better job.

Monday, August 13, 2007

Not All Questions Are Hard--
During a walkthrough last week of some Help topics I had written, my colleagues and I were discussing when to put a link in a step in a Help task. We dislike sending the user to other topics in the middle of a task, lest their Help experience start to look like one those Family Circus cartoons where little Jeffy's footsteps can be traced across the entire neighborhood several times and back. The particular problem I was trying to deal with was a situation where I felt the UI was asking the user to make a tough decision (what kind of encryption algorithm did the user want to use) and I could not do justice to the choices within the confines of the choice table (option/description) we typically use in our steps. I felt the need to provide an in-task link to a reference topic that compared the three algorithms we accommodate.

But then someone asked an interesting question, "Are we asking them to decide or are we just asking them to tell us what they already use?"

Wow, does that make a big difference in what the Help has to provide! I've always been big on the fact that Help should support user decision-making when forms have to be filled in. For example, it's not enough to tell users what the upper and lower limits of a parameter are or list the choices available, Help should assist them pick an appropriate value or make an appropriate choice. But my problem might be that I'm treating all fields as if they are decision fields.

For example, if a form asks which type of email client you are using and offers two radio buttons labeled POP3 and SMTP, does the Help have to define, compare, and contrast these choices? If the user doesn't know which one he or she is using, does knowing what they are make it any easier to select the right button?

As basic as this might seem, it is a point I have been missing and adds an important question to my task analysis, "Is this screen asking the users to make decisions or just provide information about their environment?"

In a way, it reminds me of the Family Circus-like joke about the boy who asks his father "Where did I come from? " The father sweats it out and gets through the whole birds and bees thing only to have the son retort, "Well, Jimmy says he's from Ohio and I was wondering where I came from."

Not all questions are hard.

Friday, August 03, 2007

Email vs. e-mail--

I got involved in a debate this week over email vs e-mail. Our UI says "email" and our documentation style guide says "e-mail." Editor's decision was to say "email" when referring to UI text and "e-mail" when talking about the topic. Good decision, but what I found interesting was the discussion about the usage. One writer favored the use of "email" saying that "e-mail" seemed outdated and that we should allow the language to evolve. Anyone who has read my blogs knows that I am all about letting the language evolve, therefore I found it interesting that I was on the side of "e-mail." It gave me pause and made me think. (I like talking like that in blogs because you sure can't talk like that in a Help file, e.g., "Error 404 file not found: Certainly gives you pause and makes you think where the file could be.")

I AM all about evolution of the language, but there are two sides to evolution: The weak and useless go away, but the strong and useful persist. My colleague's reasoning was the compound words tend to eventually lose the hyphens after a period of acceptance, and I think that is an accurate description of the evolutionary life cycle of most compound constructions: two closely associated terms become a hyphenated term and eventually the hyphen goes away and leaves one word. Black board becomes black-board which becomes blackboard.

But the situation under question is a special subset, one in which one of the elements of the compound expression is a letter that stands for a word. I can think of no example where one of these has evolved into a single word. Examples include c-section, t-bar, i-beam, a-bomb, b-school. Many of these terms are much older than e-mail and their hyphens are still intact. The law of language evolution would indicate that the hyphen must be useful in this pattern or else it would be eventually disappearing over time (which it hasn't seemed to). Try reading these words without the hyphen and I think you'll see that the punctuation "earns his rations" as we would say in the army.

Csection, tbar, ibeam, abomb, bschool are awkward constructions to process because our initial instinct is to see them as letters and not as words.

So I am not the linguistic anarchist some of my colleagues fear me to be, merely a pragmatist. As professional communicators, we should throw away the useless bete noires (use that in a Help file), but we should also preserve any aspect of language that adds precision or facilitates processing on the part of the reader.