Re: Research on software help

... which again makes the argument for user-centered design ("...  
software developers typically want info about SDK tool functions  
integrated into their environments..."). 1. Identify the target  
audience...

But I beg to differ that it is difficult or impossible for the  
interface to represent all the high-level tasks that satisfy user  
goals--since it is EXACTLY that goal that defines user-centered design.

(And, no, throwing ALL features onto an interface is NOT the solution.)

... ah, the proverbial thinking-box again.

Maybe someday they'll learn.

Greg

On Apr 9, 2011, at 9:08 AM, Fred M Jacobson wrote:

> 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

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