TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: why and how we write - Learners and Users From:"Sukach, Rebecca" <Rebecca -dot- Sukach -at- ca -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 19 Jul 2001 17:53:39 -0400
Bill Swallow writes:
>Anyhow, writing explicit instructions on how to create a link from a bit of
>text to a topic in Acrobat may help on the usability side, but it doesn't
>educate the user on the capability of the hyperlink functionality. Some may
>argue that is secondary information; I disagree. I think they are both
>equally important (usability in design, and thoroughness in presentation).
>The question is, how do we do both?
Research suggests, you don't do both - you do one or the other. Which one depends on your audience analysis - do you have users or learners?
As an audience, users are "work domain experts." That is, users understand the work that must be done - they have a thorough grasp of the domain in which they are operating. When a user approaches a piece of software, they are faced with learning the tool, not understanding the work. For example, a technical writer asked to create a technical document understands how to write the document yet may be unfamiliar with a particular word processing tool. As part of an existing work environment, users are motivated to learn the tool. (see Jakob Neilson for more cool stuff on UCD)
In contrast, learners are "work domain novices." That is, learners do not understand the work that must be done - they do not have sufficient background in the domain in which they are operating. When a learner approaches a piece of software, they are faced with learning both the tool and the requirements surrounding the work. For example, a student asked to create a technical document does not understand how to write the document or how to use the word processing tool. Since they are often not part of an existing work environment, learners may not be motivated to learn the tool.
Documentation and software designed for learners is usually percieved as cumbersome and overly simple to users. Similarly, pieces designed for users are percieved as inaccessible and confusing by learners. Of course, ideally you would like to create a dynamic environment in which the supports put in place for learners fall away as they become users - there's been some work done in this "scaffolding" type of design, but it's still pretty new and limited (see Chris Quintana's work on LCD).
Most of the studies on this have been done on software design, but it would be interesting to see how documentation fits into this, especially since doc is often considered a "learning aid" rather than a "tool." Perhaps the docs are the scaffolds...? Interesting stuff!
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
