Thursday, October 26, 2006

There is a thin line between the skillful interconnection of related information in an online help file and the fragmentation of the user's cognitive flow. Some user assistance authors seem seduced by a converse Cartesian credo of sum ergo tripudio, I am therefore I link. The result can disorient the users by forcing a cyber version of attention deficit disorder upon them by jumping them around too casually--what I term hyperjacking them. The following are some guidelines to consider:

Signal what kind of link the user is about to take.
There are four ways the user assistance can respond to a link:

  1. Initiate a popup
  2. Expand the text being displayed to reveal additional text
  3. Jump to a new topic and display it in the current pane--replacing the current text
  4. Jump to a new topic and display it in a new window or pane--keeping the current text in tact

I was in a help file yesterday that had links of types 1, 2, and 3, yet used the same presentation for all three. In one instance I clicked on a term in the middle of a paragraph and a definition popup appeared; in another situation, that same scenario jumped me to a new topic page. The solution is to provide different affordances (how the link looks) or pliancy (how it changes when moused over) behaviors to signal to the user what kind of response to expect from clicking on a link.

Don't break chunks into fragments.
In Information Mapping (R) lingo, don't jerk someone out of the middle of a block and send them to another map. Blocks such as paragraphs, tables, and illustrations should use only type 1 and type 2 links (as defined above). Consider the following scenario I experienced recently:

  1. I clicked on a link that was the title of a procedure (out of a list of 3) and it expanded to display the steps.
  2. I then clicked on a term in one of the steps (expecting a definition popup) and was hyperjacked to a new topic. It looked very involved and had lots of other links and I decided it was much more of a commitment to the term than I was willing to make, so I clicked the back button.
  3. I was returned to the page I had just come from, but it was in the default state with all the expanded text collapsed. I wasn't really sure which procedure I had been in when I took the original link.

Breaking up the user assistance in the middle of a unit of discourse (sentence, paragraph, etc.) moves the user into a new thought before you've let them get through the current one. Decide what your smallest unit of discourse is going to be. Info mappers would probably define this as the block. For non-mappers, I recommend the paragraph, procedure, and table as being unbreakable units of discourse.

Tomorrow I will discuss guidelines for when to employ which type of link behavior in a help file.

Stay posted!

1 comment:

Steve Kersten said...

This is a particularly well thought out post. Not only is it good guidance for user assistance writers/designers, but, perhaps more importantly, it's a good note for our tool makers. For example, we had to hire a contractor to write custom JavaScript to allow a RoboHelp WebHelp system to use the RoboHelp glossary as a single-source document. What this means is that via the JavaScript (because this functionality is not possible otherwise in RoboHelp, as far as I know), I can "code" a term so that it is underlined with a dashed underline (it's still blue, asking to be clicked on!) that, when clicked, presents the terms definition, pulled from the glossary. This kind of post is a good way to send the makers of RoboHelp (and Flare and Doc-to-help, etc.) a user requirement! The better tool makers (a funny phrase that brings to mind humans, raccoons, ants, etc.) understand how we're designing user assistance, the better (I hope!) they can match their tools functionality to our needs. Thanks, Mike.