Monday, September 3, 2007

Barker Chapter 1 - Understanding Task Orientation

Barker begins this chapter with a series of examples showing effective software documentation. He notes that these examples both explain and show the connections between the user’s professional work and the computer program. Scenarios, examples, and page layout can all contribute to this explanation, and according to Barker, any manual that helps the user manage and communicate information related to his or her task can be described as “task oriented.”

Barker then gives a detailed list of techniques to create a manual that helps users solve a complex task, including:
• Emphasizing problem solving – use introductory paragraphs that preview not only the steps to follow, but the goals and objectives of their software work.
• Providing task-oriented organization – Organize a manual or help system in a way that matches the kinds of tasks a user will perform.
• Encouraging user control of information – The manual should show users how to make key decisions, supply key information or determine key outputs (the user decides what the program does for them).
• Orienting pages semantically – Arrange the elements of the page meaningfully, according to elements of the job the user needs to perform.
• Facilitating both routine and complex tasks – Routine tasks include repeatable tasks that are easily represented by conventional procedures, while complex tasks are not performed the same way every time. The more you can help users apply software to complex tasks the more users will value your manual.
• Designing for users – Manuals should be designed for what the user needs and not from a template. User-drive design should allow users to find what they need, understand what they find, and use what they understand appropriately.
• Facilitating communication tasks – Communication tasks are defined as, “tasks that require the use and manipulation of information to coordinate workplace activities.” Document designers can help users see the why behind the program features by analyzing what kinds of information users need and how they communicate, and then identifying those program features.
• Encouraging user communities – Users often need encouragement to rely on other users of the program; task-oriented documentation encourages users to identify and get help from others.
• Supporting cognitive processing – The task-oriented manual uses principles of knowledge representation, parallelism and analogy to convey software features and applications to workplace tasks.

Next, Barker provides a definition of task orientation, stating that it is “a design strategy for software documentation that attempts to increase user knowledge of and application of a program by integrating the software with the user’s work environment.” He also states that exploring the theory behind task orientation can help with documentation design and provide a foundation for techniques discussed later in the book.

Barker goes on to describe both the default manual and user. The default manual has the following characteristics:
• Covers the features of the program
• Implicit role of technological ignorance imposed on the user
• Ignores the user’s workplace use of the program
• Assumes one way of learning
• Overly simplified approach to program operation
The default user has the following characteristics:
• Perceives job skills as decreasing in importance
• Sees computer use as separate from job goals Becomes isolated from other employees
• Fears remote supervision
• Suffers from information overload

Barker then notes that people often resist using computers and software because
of the inherent complexities of abstraction and information overload.

Next, Barker describes the characteristics of a task-oriented user, which include:
• Challenged by redefined work activities
• Conceptually oriented
• Aware of user communities
• Self-managing
• Supplied with resources

Barker continues the chapter by discussing the different forms of software
documentation, which include tutorial, procedural and reference. Tutorial documentation has the following characteristics:
• The user motivation is to learn
• Intention to teach the features of the program
• Relationship of teacher and learner
• Defines the task through scenarios, cases, examples; narrative structures
• Focus on basic actions
Procedural documentation has the following characteristics:
• The user motivation is to perform routine tasks
• Intention to guide through step-by-step procedures for using the program
• Relationship of guide and mentor
• Defines the task through chronological, step-by-step structures following the menu of choices or fields in a pane or screen
• Focus on operations organized around workplace actions
And, reference documentation has the following characteristics:
• The user motivation is to obtain information “about” the program
• Relationship of resource and client
• Lets the user define the task
• Focus on the program

Barker concludes the chapter by discussing the processes of software documentation. He says that to provide useful task-orientated documentation, one must look at the process of writing and find ways to learn about users. You don’t have to know the user if you are writing a default manual, but to have an effective task-oriented document, you must know the user. The process begins with the analyzing the users instead of the program. The process of writing and testing starts with the exploration of needs, and then requires constant involvement of the user. The process is called a usability process and is defined by the following stages:
• Planning Stages
o User interviews to find out what actions users take using the software
o Focus groups to find out user needs and organized constraints
• Development Stages
o User reviews to see how well the manual fits with workplace tasks
o User lab tests to gauge accuracy of manual and help information
o User field tests to gather additional information about workplace users
• Evaluation Stages
o User field evaluation to assess the overall value of documents
o User usage reports to help adjust writing and research processes for subsequent manual releases

3 comments:

Anarchy Andy said...

I'm glad that Barker eventually got around to discussing the difference between software documentation targeted towards beginners, and documentation that serves "advanced users". When I turn to software documentation, it's usually because I'm looking for specific information on a particular feature of the program, and I'm often frustrated by having to wade through more general information aimed at novice users. Sometimes I find that the advanced information that I seek, which Barker terms "reference documentation", isn't even included in the help manual at all. Organizing software documentation so that it can serve both types of users seems like the best approach.

Emily said...

I like Barker talking about field test i think it's something that must be done to make sure you hit your target audience. Being able to test your document you make can give you a lot of useful information before spending to much time or money then to find out you missed your mark for the audience.

Matt Bynum said...

The other part of my internship was creating a manual for the medical software we provided. Long story short it is a year-long process to train a hospital on how to use the software. Had I been around to finish it I'm sure I would have used a lot of the techniques talked about in this chapter.