Barker Chap 1
Understanding Task OrientationTeam 2: Hilary Warren and Robin Ender
Summary
Chapter Goals1. Encourage user to become more proficient with the programs.
2. Application of the program in the workplace – become more efficient at using programs for problems in the workplace.
3. Creating a manual that adapts the software to the users job instead of having the user adapt to the software.
All software documentation should explain and show the connections between the users' professional work and the computer program.
This can be accomplished by scenarios, examples, and page layout.
Guidelines:
Nine techniques assist in creating a manual or help system that helps users solve complex tasks and see the relation between the new program and their workplace.
Emphasize problem solving
In order for a manual or help system to be user friendly, it should help users to solve problems in their workplace.
The manual should be organized to give sequential tasks.
Encourage user control of information
The user should be able to determine what the program will do for them.
Orient pages semantically
Balance text and graphics on a page so that they compliment each other.
Facilitate both routine and complex tasks
Routine repeatable tasks would require a step by step process in a manual. But complex tasks are more dependent on knowledge and experience, the manual needs to help these users with the application of the software to complete complex tasks.
Design for users
The user needs should drive the organization of the manual.
Facilitate communication tasks
Software programs are the tools (means) for user communicatin about their work in the workplace.
Encourage user communities
The encouragement and identification of user communication to seek help from others.
Support cognitive processing
People use mental models called cognitive schema, this helps the users learn and process new information.
Different Documentation for Different Users
Typically, users first learn how to use software in their everyday work. Users may then begin to use the software on a daily basis. Advanced users will only need to turn to the manual to look for specific information.To assist each type of user, there must be different types of documentation.
Three types of documentation exist:
Tutorial Documentation
Teaches basic functions and features of a program so the user can start using the program for common workplace tasks. Examples of this type of documentation include getting started guides, and online tutorials. Focuses on basic actions.
Procedural Documentation
Guides the user in everyday use of the program. Examples of this type of documentation include users guides and step-by-step procedures. Focuses on operations based on everyday work.
Reference Documentation
Supplies information about the program, typically for advanced users. Examples of this type of documentation include alphabetical listings of program features, lists of examples, and troubleshooting data. Focuses on the program.
Principles of Software Documentation
A definition of task orientationThe book uses the term task orientation to indicate the writer’s purpose.
Theory behind Task Orientation
Default Manual- helps the user to learn the function but not necessarily how to apply the knowledge toward the users job.
Default users share some characteristics that rely heavily on the users perception of themselves, their skills, and how they fit in at work.
1. Computers now perform functions that the user performed in the past causing the user to see their job skills as not important.
2. Users begin to feel isolated from other social groups due to computer use. The need to interact face to face with the other social groups decline with the increased use of email and software programs that are shared in a drive for all to see.
3. Users feel their Supervisors can now micro-manage them from remote places, they no longer need to be face to face with the user in their office.
4. The user feels overwhelmed with information and do not have any direction as to which to apply first.
The Task Oriented User Characteristics
1. The task oriented user feels more challenged to use their skills and with the use of software can engage in complex tasks.
2. Conceptually oriented
3. Awareness of their user group will help the user avoid the feelings of isolation as they interact within their user group.
4. Information Rich
The Forms of Software Documentation
1. Tutorial Documentation – this type of documentation is intended to teach the user the basic functions of the program so they can then apply this knowledge to their tasks at work.
2. Procedural Documentation – This documentation is a more step by step guide to help the user through their everyday tasks.
3. Reference Documentation – This documentation is for the advanced user that
Processes of Software Documentation
Planning Stages
Interviews and focus groups are conducted to discover user's actions, needs, and retraints.
Development Stages
User reviews, lab tests, and field tests are conducted to determine
Evaluation Stages
User field evaluations and usage reports are conducted to find value possible writing changes.
10 comments:
One thing that I have found to be very helpful when learning new software is to create and share tips and and helpful hints during our team meetings. We have also created and published helpful hint documents on our website, and this has proven to be very useful for many users including us.
I thought the chapter did a good job keeping the users in mind when documenting software.
It is very important to make a user of the software to feel connected to it, and have their job function still be important despite more automation. This chapter talks about ways to help the software user become more at ease with the relationship between the software and their place at work, and how one should not feel isolated or disconnected just because face to face interaction isn't always going to happen anymore. At my current job, we talk face to face all the time about specific orders, even though I am at my desk all day. I do feel that it is important for managers and other higher ups to tell us what they're watching remotely and why they are doing it. That would make employees feel much better about not meeting face to face in that regard.
Mary made a good point about the importance of sharing tips to use with software. I think this is nearly as good as the tutorials and training manuals. Since there are users who learn best by doing, this is an effective tool.
This chapter talked about the importance of understanding your intended audience and its needs which reminded me of writing any type of document. Know your audience is the key.
As I read this chapter, I thought about those of us who did not have computers growing up and how our approach to learning software programs might differ. Personally, I use the tutorials rather than manuals (and hints from others using the same software) because I tend to get bogged down with the terminology of a manual. Had I used computers back in high school, maybe my learning method would be different. Just something to consider when writing training manuals and other instructional guides.
One thing that I have found useful when learning new software is to not try and learn too much too fast. I think it's important that when new software is implemented that the intended user knows their particular area of the software very well instead of knowing a little about everything. That may go against conventional wisdom but I think you are surprised when you find out that a lot of questions you may have in your particular expertise apply across the board. I just know the chaos that can erupt when too many cooks are in the kitchen and there is only one contact to answer questions.
It seems like the older I get, the software is shifting from being rather simple to being fairly complex in many ways. The user is getting farther and farther away from the actual guts (programming and low level detail) of a program. I mean I grew up with Windows 95/98 running programs in dos and trying to configure sound cads etc, then 2000 which was a step away from dos running applications and messy gui's in software, and finally XP and Vista where it is so abstracted its like a whole new idea. It's like each time I would jump to a new version, it would take a little longer to figure out how to do those lower level things, like simply getting to the device manager in Windows. When I was younger I used to be able to do so much in Adobe Photoshop, and now with Photoshop CS2/3 it's a challenge to do something so simple, like resize a photo, or reduce red-eye. Although, it is nice nowadays with many software titles having help files and even better yet, online help files which are constantly updated while the software is updated. There is nothing worse than opening a program and just staring at it, trying to figure out what to do first. (Once again, I don't have any books yet... will soon though.)
The section on the three forms of software documentation: Tutorial, Procedural, Reference was intriguing to me. As a user, I have found myself drawn to each form at one time or another depending on what I wanted to accomplish.
I remember when I started using Microsoft Image Composer and knew nothing about the software. I bought this really informative (and cool) book on learning the program. It contained all three facets of documentation. I started with the tutorial, reading every word and doing everything “by the book.” The concepts and procedures immediately started falling into place and I was amazed at how I was learning the software from the bottom up, albeit very, very slowly. Currently, I’m working on databases for my job; my training was hands-on from a friend, and I didn’t use a tutorial or even the procedural documentation to learn the software. When I get stuck on something like how to write a conditional expression, I just want the reference information. I don’t want background, theory, or how to get there from here. I just want to know how the expression is written. Now I can see how well-written software documentation would try to encompass all facets to appeal to all types of users.
I think Microsoft has done an excellent job with their online help, third-party software manuals, and user groups. I don’t ever recall not being able to find the answer I needed (given I knew how to correctly word the question).
Knowing the user is key to decide on what type of document will work for them be it for software or any other type of document. I think Barker is vary clear and the layout makes it easy to go back through for finding information.
Software can be complex enough and without the right type of reference or tutorials it can make it impossible. The right type of software documentation can be what helps a user learn and understand or frustrate them and make them never what to use the software again because the document doesn’t help.
I also agree with Mary that it is helpful to share tips when learning new software. At my job, we don't have an online learning community, but co-workers always share tips and shortcuts with each other. We use a very dated system to place and check on orders as well as perform other functions. In many screens, you can use certain commands to skip to another screen for reference, but many workers don't know about this because it is not in the training manual. This is something that could be presented on a learning community.
I found the explanations of terms in this chapter very helpful as well. I didn't know many of the terms and their explanations and use of them consistently throughout the chapter was helpful. For example, they defined the difference between proficiency and efficiency in the beginning of the chapter and continued using them throughout the chapter to better acquaint readers with the terms.
Chapter one in Barker points out what users are facing in this high pace technology environment. Depending less on co-workers and people can be difficult for people to accept so they have to go through an adaption period. Constructing Documents that can help users learn to work with their programs in new ways, adapting software capabilities to the specific purpose and goals of their jobs. I learned that that is called adaptive computing according to Barker, applying software to complex tasks not represented in the menu selections.
I find this easier for me to do when I Try and figure out the system through trial and error, to do explore and discover independently then turn to the programs that can help me understand the software more. The three forms of Software documentation are very useful to the users (1.) Tutorial Documentation (2.) Procedural Documentation (3.) Reference Documentation, in my case at when I worked a 3M, the Reference documentation helped me out a lot since I was an advance user of their load program. That had constant modification and upgrades to this program that I would just have to look back at the new manual.
I've found that I generally will go from tutorials directly to reference materials, and I'll only use the tutorials when I've already failed at trying to figure out the program without them. I'm generally able to extract quite a bit from a tutorial, and then it's just a process of figuring out what else those lessons can be used for. I needed tutorials to break me into both Photoshop and Bryce, for instance. Paint Shop Pro I found to be a bit easier, but then it also had fewer features to confuse you with.
Post a Comment