Usable information about help and About boxes

[Susan Fowler <sfowler -at- EJV -dot- COM>]

I thought this piece by Jared Spool from the utest list might interest people
 who are developing online help systems. In the original posting to which he
 responded, the writer asked if it made sense to have a button on the toolbar
 for the "About" information, and if she did that, what symbol should she use
 for it vs. help.

Spool is famous for his low-tech but effective usability tests. He's spoken a
 number of times at the STC Boston regional conferences.

This has been forwarded with his permission.

--Susan Fowler
sfowler -at- ejv -dot- com

----- Forwarded message follows -----
<From Jared Spool>

This isn't what you asked for.  I don't really have an opinion on toolbars.
However, I do have some actual data from usability testing.

We have tested dozens of products with toolbars, all of them with help.  I
have not seen any products with icons for general help or the about box in
any of the products we've tested.  (This includes most of the Microsoft
office products, most Lotus products and dozens of other horizontal and
vertical applications.)  We have seen icons for context-sensitive help, in
terms of the question-mark w/pointer.  We have never seen a user actually
make use of this button.

Users do use help from a variety of sources.  The most common is to press
a help button in a dialog box.  Hitting F1 in a dialog box is also common.
Lotus products use a tiny (14x14, I think) question mark icon in dialogs,
typically where other products put a maximize button.  Users don't use it,
claiming that they don't see it until we point it out.  In several comparisons
of Microsoft vs. Lotus products, users were far more likely to go to help
in Microsoft dialogs than in Lotus dialogs.  They were more likely to look
in the manuals while in Lotus dialogs.

Another common source of help was the help menu itself.  Occasionally, users
will explore a "How Do I?" option in the menu, usually to find that the
problem they are struggling to solve isn't in the list of approved things
to find out.

Users almost always use the search facility in help.  If the search facility
is not in the help menu, it will be the first choice when entering help.  Users
almost never look at a "contents" page.  (In a couple of products that didn't
have contents pages, the users never noticed.)  Users do complain when the
help menu does not offer direct access to the search capabilities of the help
engine.

In observing products that have toolbars with tooltips (as Microsoft calls
them,) or hover-bubbles (as Lotus calls them,) we have never observed anyone
looking for help in the toolbar itself.  An inference would be that the help
menu itself provides a direct affordance.

This data is from observations of approximately 100 individuals using
approximately 25 windows-based applications.  The users were of a variety
of backgrounds and experiences.

Oh yes, Lotus has an icon in their toolbars which is an i in a circle.  It
brings up their tabbed property inspector, which they call the infobox.  Users
don't realize that the icon has any relationship to the infobox.  They don't
press it.

Based on all this information and the details you described, I would focus
on providing help in the menus and not through a toolbar mechanism.  Ensuring
that help is clearly available in dialogs would be good.  I would not embed
any functionality in the about box, users probably won't look there for it.

All of this data is from our usability tests.  As with any data, you need
to take all of the context of its acquisition into account.  Therefore,
your mileage may vary.  Remember, you always have to test your product with
your users.  (Sorry, our standard data disclaimer.)

Hope this was useful.

Jared M. Spool
Sitting on mounds of usability data
User Interface Engineering
(508) 975-4343
spool -dot- chi -at- xerox -dot- com