Sunday, September 13, 2009

Different Ways to Access Online Help

What started out as non-scientific observations about how Windows software can access online Help has transformed into assembling opinions from the HATT list.

Chuck Martin brings up excellent points.
It sounds to me like you're limiting the definition of "help" (or capital-H "Help) to something that we might define as a separate system used to display hypertext information. But I think of user assistance as much broader than that.

Nevertheless, some people have noted the F1, something that I'm not sure a lot of users are familiar with anymore, although we as user assistance professionals usually strive to make sure works, at least in Windows applications.

Access to content outside the application window is also often provided by links. Sometimes the links are general. Often they are contextual, frequently asking in the UI text a question a user might have at that point and linking to the answer.

Some applications don't use the word "Help" at all on their buttons or links, having found that users disdain the concept (probably from having been exposed to too many non-helpful help systems, likely as not written by programmers or marketing folk), and choose other terms that users are more willing to click on.

Some applications create a number of access points in the Help menu. For example, direct links to tutorials or getting started content. Some may put a Help item in pop-up menus if it makes sense contextually.

Pop-ups are also a technique used, and there are many variants, from tooltips and other windows that appear from merely hovering, to panes that appear only after a defined user action.


I have seen also, usually in dialog boxes, a separate pane that can be opened as part of the dialog box that contains contextual content.

Sometimes a pane is built in to the UI that contains UA content.

And of course, all the UI content, iconography, titles, and other elements in the user interface give users information.


The always brilliant Rick Stone suggested "Some applications use embedded help where content appears in a specific location within the application."

And yes, I’m more interested in how a separate Help system is accessed at the moment. I've attended the embedded UA sessions @ WinWriters and know how much it rocks. I’m all on board with that.

However, the background of this query is that we are discussing the standards for how Help should be accessed from our systems.

Some of our apps currently do not have any visual cue but if you press F1, you get a window-level topic. Is that the industry standard? Should there be F1 *and* a Help button? Should there just be F1 and not take up “real estate on the screen” with a Help button? Should we do the new Vista standard, which says to not have a Help button and, instead, have hyperlinks that say “Tell Me More About ” as the standard? Do we do that on each field? At that point, isn’t it better to have a single Help button rather than 10 links like that?

The issue I’m really struggling with is that while MS has stated “rules” for how user assistance should be accessed, no one seems to follow them. I get it, on one level, because it means (hopefully) the audience was considered in designing how they would access user assistance. On the other hand, how do you argue a point with an example of having a Help button on the window when the “other side of the aisle” can find counterpoint examples where pressing F1 opens Help and there is no Help button or visual cue?

The following are examples of how Windows apps access user assistance

1. Some MS apps have a ? in the upper right hand corner next to the X that calls window-level help.


2. Some MS apps have no indication that you can get to Help from the window.

which accesses:


3. Some MS apps have a ? icon to the far right on the ribbon


4. Some non-MS apps that run on Windows have a help icon in the lower left corner that calls window-level help.


5. Some non-MS apps have a generic Help button.


Another example:


6. Some non-MS apps have a ? icon to the far right on each module that the program can include. If there is a menu, there’s a Help menu option as well.


7. Dana Worley said, "In our programming software, you can also right-click any parameter to display a pick list of valid options. If valid options do not fall into a discrete little list it will display context sensitive help."
Examples:


Another example:


Another example:


8. David Spreadbury said, "In one application I have developed help for, clicking an alarm in the alarm screen opens the help at the location where the alarm is described providing information on what may have caused it, and possibly a way to correct it."

9. Will Turner said, "Of course, there has been tooltips -- "hover help" -- for many years. Recently, I have been intrigued by Yahoo's use of hover help in the list of company quotes that Yahoo enables me to put on my Yahoo home page. Holding the cursor over a small box next to a stock name yields a pop-up containing several headlines. You can click on one of those headlines to open its details page. I gather that Yahoo accomplishes this with CSS, but I remember reading about the same facility using XML."

10. Some apps only allow access from a Help menu.


11. Some non-MS apps have no indication that Help is available.

So there's some examples... how many zillion more exist?

No comments: