Re: Research on software help

I've even gone so far as to imbed screen-captures into context- 
sensitive RoboHELP files, which were themselves imbedded into the  
interface (so they wouldn't have to juggle between the open app and  
the RoboHELP file), to literally show users which alphanumeric text  
links to click on to achieve the desired tasks along their workflows.

What a waste of clicks and time.

Far better to preconceive user-centered design in the first place.

Greg
On Apr 8, 2011, at 1:16 PM, Meghan Ede wrote:

> 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]
>
>
>
>

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