Main terms of the chapter – Module
Minimalist tutorial: Open-ended tutorial
Elaborative tutorial
Embedded tutorial
EPSS
Scenario
Documentation sets
And others per the glossary listed later in the chapter (p. 54-55)
It is important to remember past experiences with the application you are writing when a writer prepares manuals. This will help the reader understand certain problems that might happen when they are trying to use the system. It is important then to figure out what skills are necessary to teach the reader after presenting the scenario. (p. 31). If the writer plans the tutorial around the action or scenarios, then it becomes easier to see the skills needed to build lessons. The following are the categories needed to write a good tutorial:
Introduction, Overview, Explicit Instructions, Steps to keep the user focused on one task, and graphics integrated with words to show what to do specifically for that particular step. (Page 32).
The features to set in a tutorial depend on several factors, discussed in more details on page 33. Is the task central to job performance, is it essential for efficient software use, what is the frequency of performance for that task. The help system should also detect skill needs.
Objectives in tutorials are important because the writer should be able to state what they want the tutorial to achieve for the user. Objectives should be written down in the tutorial plan as well as being apart of the actual lesson. Objectives = actions the user needs to complete.
Choosing the right type of tutorial is important because they come in many variations. Page 34 talks about how they range from very brief to full-scale manuals. Print and online media is used to display these tutorials so that users have a variety of ways to access them. The choices include a guided tour, demonstration, quick start, guided exploration, and the instruction manual.
Guided Tours help to present an overview of each of the programs features (page 36).
This chapter also asks the writer to present skills in a logical and cumulative structure. This means that the writer needs to organize features in the “form of instructional objectives.” (page 42). Beginning to advanced, simple to complex, generalized to specialized, input/accumulating data to output/reporting data, starting to ending a session, using default options to using customized options and working with text to working with graphics are all varieties of ways to use logical and cumulative structure in your tutorial.
Offer Highly Specific Instructions is very important when writing a tutorial so that the user doesn’t get confused or frustrated.
Specific data
Tools
Screens
Commands
These are all ways to keep the user on track with the specific instructions you are trying to teach them. *It is important to avoid distractions.
Give practice and feedback at each skill level. It is important for the user to give feedback after they are finished with the tutorial. A positive ending to the tutorial is important.
Build a pattern of Exposition: This means to repeat a rhythm such as give action to take, explain the result. (Page 47).
A quiz at the end of the tutorial is important feedback for the writer to see if any improvements need to be made.
Pace the Tutorial to make sure you don’t waste the user’s time. (page 47). This is important for you and the user so that the tutorial will be useful and they will have other people come back to it later. It is important to allow the user to quit during the tutorial and to show them how to quit the program when it is finished.
Testing your tutorial is important to make sure to knock out the kinks before giving it to the end user.
6 steps in the Eleborative Approach
Instruction results in articulated skills
skills transfer capability to real-world performance
steps should present skills in logical and cumulative structure
highly specific instructions work best
give practice and feedback at each skill level
master one skill before going to the next
The minimalist approach
1. Choose an action-oriented approach
2. anchor the tool in the task domain
3. support error recognition and recovery
4. support reading to do, study and locate
Ways people learn software programs
Users jump the gun
Users will skip information
Users like to lead
Page 54-55 displays a glossary that defines terms in the chapter.
Page 57-58 provides a checklist for tutorial design
Practice/Problem solving is at the end of the chapter. The following are exercises the chapter suggests in order to get a better understanding of writing a tutorial.
Analyze a tutorial to get used to different types of tutorials and figure out which you would use where.
Analyze a program operations list, this portion of the chapter mentions to examine program operations list and identify three elements for each operation job performance, important to efficient software use and frequency of performance.
Analyze elaborate vs. minimalist methods of tutorials to get a better understanding of both methods. There are worksheets on page 61 to assist you with this.
“Revise the Objectives Statements using a user orientation, emphasizing the terms the user should know by the end of the lesson, and the commands the user will master.” (Page 61)
Write Practice Problems for Users
Subscribe to:
Post Comments (Atom)
10 comments:
The chapter offered some good tips on creating training material; however, in my experience, I have found that it's so difficult to create useful materials to accommodate users with a wide range of skill levels.
One thing that really stood out to me in this chapter is I do like the idea of creating a more comprehensive manual for novices and a quick reference for more advanced users. That sounds like the best of both worlds.
I would have to agree with Mary this chapter does offer some good tips on creating tutorials. Barker also points out that accomodating the different learning styles is not easy. Each software learner has different motivations that the creater needs to keep in mind. Complying with company directives is usually the biggest motivator at my place of employment.
I thought the section on observations of the software user was interesting. Jumping the gun gave me a good chuckle, kind of sounds like someone that doesn't look at the map before leaving on a trip. It is true that some of us do get a head of ourselves when learning a new software. We want to jump right in with learning the software and skip the "unimportant" pages of the manual.
I appreciated that the chapter also discussed the philosophy behind the different types of tutorials and the fact none was considered a standard giving the writer the freedom to develop their own preferences.
I have never written a tutorial, but have read several. It seems that books on software are easily identified by their approach, and I find that I like the books that use examples from real life to anchor the material learned. These are the ones that are highly elaborative, personalize the lesson materials, and provide results that can be applied to real life. One software book I used taught me how to prepare a flyer about my lost dog to post in windows, etc. Accomplishing the tutorial that helped me create that flyer was satisfying. I don’t have a lost dog that I need to find, but I did have a invitation flyer that I had to create for work and applied a lot of that tutorial into the creation of my own flyer.
The minimalist and elaborative approach are both very sound. I have to say I can see the benefits of using both, with maybe the minimalist tipping the scale just a little. Like others have said, most people learning new software are doing so in the workplace, don’t have a lot of time, and are impatient to get results. If you are somewhat computer savvy, that would seem to be the preferred way to go…as long as it’s good material presented in a concise, logical manner.
I tend to agree with most everything that has been said so far. I think it is very difficult to create training material that effectively trains all types of individuals. I think more importantly is that the training material is able to be understood by someone with the minimal qualifications needed in order to successfully use the software. Training materials are great but risk being too vague or too specific and therefore comprises the quality of the material. Overall, I found this chapter useful.
There was very much info in this chapter. I like some of the minimalist approaches to learning software. It sort of is expecting the user of the software to kind of intuitively figure it out, instead of it just depending on the documentation. I tend to learn best this way, instead of having very structured methods of learning. I can see some downfalls with this type, but I would agree that people learn best from trial and error.
It would be very hard to write documentation for every user, but at least a few classes need to be accomadated to. Two users that need to be written two are the novice and the expert. The novices documentation needs to move very slow, have several illustrations, and even comment on the very simple steps, like starting the program for the first time. With the expert you could jump right in to specific details obviously assuming that they know so much already.
As Robin mentioned, I also did enjoy reading the observations section of this chapter. The jumping the gun behavior is something that I would do and most typical males I believe.
On page 35, there is a great example of an embedded tutorial. I liked this example because it shows that some tutorials can be annoying if not used properly. For example, I find that when I use Word on some computers it will automatically correct things or capitalize letters (when I don't want the letter at the beginning of a line capitalized, it tends to do it anyway! When writing headlines, for example, the letter at the beginning of the second line is never capitalized, so it's always a pain to have to fix this). The information in this chapter was very useful to help a tutorial designer learn how to make proper programs for different skill levels and different actions. I seem to bring up my job every week (and will more than likely continue to do so), but they did a poor job of writing a manual on how to use the computer system for placing orders. They don’t use many models of what different screens look like and the language is confusing. Also, a lot of things aren’t necessarily placed in sequential order. The writer should have spent more time thinking about the users (especially novices) and what they would need to know to perform actions. On page 46, Barker mentions using “highly specific instructions” because it’s important to give the reader a clear idea of how to perform the task efficiently. The steps and tips provided in this chapter gave me a better idea of how to do tutorials/training manuals to benefit the reader in the most positive way possible.
I agree with Mary about creating different types of manuals for different levels of expertise. Personally, I find it annoying when I am using a program I am already familiar with, and I keep getting pop-ups asking if I need help with anything. If I need help- I know where to find it.
It is striking the balance that is difficult. A pro will know where to look for help- so they don't need it popping up at them every time they hover over a tool. On the other hand, a novice might not know where to go for help, and they need that pop-up to get them going.
I find it usefull to use tutorials when im figuring out a new program. Long as it the tutorials match up with a person who hasn't used it before. Really being able to focus your tutorial to just one set of users is almost impossible to do. I think all programs will have experienced users and beginners without easy to follow tutorials it can be useless. Trying to figure out the users ability is always hard to do. I think building tutorials are best used if they have two sets one set for beginners and one for advanced.
Having two sets tends to make both happy from people i know learning a new program.
In Barker Chapter 2, the information was abundant regarding, “writing to teach- tutorials,” I saw that that in this Chapter Pacing is a very important process for the author and the user. The author should be considerate and cut each session down to 10 minutes so that they are not over whelmed with work, and to be aware that maybe while they are using the tutorial they could be getting called away from the desk.
Tutorial Users need special care, and as the author we need to be aware of this. That people have different learning styles. Most adults are goal oriented, and do not like to make mistakes, but this is a healthy process to learn form their own mistakes. I am a trial and error learner… when I worked under a kiosk system at a retail store; I learned the soft ware by myself since the manual was too big to read. I taught the people who had worked there more years than me how to use the kiosk because I was not afraid to make mistakes.
This chapter reminded me of complaints about some open world video games, where there was so much you could do, players had no idea what they should do. Barker provided an important reminder to make sure that you can approach the text from a fresh angle, and figure out how it appears to a person new to the whole system.
Post a Comment