RE: Research on software help

Cate-

Meghan mentions that conceptual material is often provided as documents
instead of online help, but my experience (no "data" here) with users (and
that of other tech writers I've worked with) is that users are task-oriented
and many don't read conceptual material in preparation for using the
software. That argues for linking to the conceptual material in the help.

Tech writers now classify topics as concept, task, or reference. As others
have pointed out, the requirement for extensive task documentation can be a
sign of an ineffective user interface. But when the software is a "toolbox"
- like many enterprise products I have documented - it is difficult or
impossible for the interface to represent all the high-level tasks that
satisfy user goals. Online help might be a good choice for these
"meta-procedures," or at least the most common or instructive.

You asked about "developers." I'm not sure you if you are asking about
documentation for developers, but here's a perspective on that:
Documentation for developers often includes many reference topics. Most
developers (again, my experience, but no data) expect and use effectively
online access to this material. For example, a programmer using a software
development environment expects to access information about a library easily
from the environment.

-Fred


-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Meghan Ede
Sent: Friday, April 08, 2011 1:16 PM
To: Cate de Heer; Greg Austin
Cc: [email protected]
Subject: Re: [BayCHI Discussions] Research on software help

From my personal experience running usability studies:

- people get really pissed off when "help" simply rephrases the interface
e.g. "under the file menu, you will find..."

- people are usually looking for "how" to do something, rather than an
explanation of the UI, especially tips, tricks or trouble-shooting

- it takes only a few (usually only one) bad experience with a piece of
unhelpful help content for the user to stop using help altogether on that
product

- more technical users are, in my experience, more likely to persist with a
help system or online documentation than consumers, because often the tasks
they are performing require specific and correct actions and errors can have
huge impacts; they also annotate and copy over good, useful help content -
to an internal resource, such as internal wiki

- a great way to get feedback about your online help/documentation is to
include a brief online survey incorporated into the help/doc system, along
the lines of:

   1. How helpful was this topic (then have a rating scale)
   2. What were you looking for? (open-ended)

  This feedback helps to inform you what parts of the content are being
looked at, relative ratings and match between content and needs. The Sun
website has been using this for years to refine their content

I have found perusing forums to be a good way to assess how helpful a
product's documentation is - if many users are asking questions that
could/should have been explained in the help - likely they are not using the
online help or it doesn't provide the answers they need

 - conceptual information is more likely to be printed and shared (and
therefore formatted to make this easy), while step-by-step information is
more likely to be used "on-the-spot" and has less need for easy export
design

Meghan


--- On Fri, 4/8/11, Greg Austin <[email protected]> wrote:

> From: Greg Austin <[email protected]>
> Subject: Re: [BayCHI Discussions] Research on software help
> To: "Cate de Heer" <[email protected]>
> Cc: [email protected]
> Date: Friday, April 8, 2011, 5:19 AM
> When Help is preconceived, then
> usability is not. If one needs to rely on Help to explain
> the communication that is intended by the interface, then
> that interface is wrong, since the functionality is not as
> the target audience expects it. Therefore, users have not
> been studied well enough.
> On Apr 7, 2011, at 10:58 PM, Cate de Heer wrote:
> 
> > Hello,
> > 
> > I'm interested in any data on how users (end users and
> developers) access and use help documentation. In
> particular, I'm interested in the following:
> > 
> > _ Expectations or results when users encounter help
> documentation on the developer's website or via a search
> engine (I'm familiar with studies from 10 or more years ago
> indicating low user expectations from the documentation in a
> software help menu)
> > 
> > _ The success of different approaches to information
> architecture for online documentation; for example,
> self-contained, one-page topics versus the longstanding
> "help manual" model with several levels of hierarchy
> > 
> > _ Any differences between approaches that work well
> for end users specifically or for developers
> > 
> > Cate
> > 
> > 
> > . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . .
> > The real technologybehind all of our other
> technologiesis language.
> > Norman Fischer
> > _______________________________________________
> > This is the BayCHI Discussions mailing list, [email protected]
> > To change your subscription options, or to
> unsubscribe, visit http://baychi.org/mailman/listinfo/discussions
> 
> Greg Austin
> [email protected]
_______________________________________________
This is the BayCHI Discussions mailing list, [email protected]
To change your subscription options, or to unsubscribe, visit
http://baychi.org/mailman/listinfo/discussions
_______________________________________________
This is the BayCHI Discussions mailing list, [email protected]
To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions