Answered Question on Linkedin.com: What successful techniques have you used to improve learner's retention?

I recently answered a question on the Instructional Design & E-Learning Professionals' Group of LinkedIn, and wanted to share that answer here on my blog. The question posed was:

What successful techniques have you used to improve learner's retention? Based on my experience, there's only so much information you can stuff into people's heads.
What's the best single tip you would give to help improve the quality and quantity of information that people retain after experiencing the training you've developed?

My single most important tip is this: Instead of training your students to perform the task from memory, teach them why and when to perform the task, and how to use support materials to succeed at the task.

If you are training your students to perform a life-and-death skill under strict time constraints, then of course they need to be able to perform the task from memory, on demand. An emergency room medical procedure would be one example. In that kind of situation, you want them to leave class knowing exactly how to perform the task without any kind of support materials. But that is a rare situation.

In most situations, your students will have time to perform the task. That is, they will have time to find and use reference materials to help them with the task.

Instead of overloading your students with the detailed steps of how to perform a task, perhaps you should consider teaching them how to use the reference and support materials to perform the task. Then, you can focus your training on:

1. Why they need to learn to perform the task (motivation).
   
2. Who needs to be involved in the task (roles and responsibilities).
   
3. When they need to perform the task; where it fits into their workflow (context).
   
4. Which steps are critical or especially difficult (roadblocks and "gotchas").
   
5. Where to get supporting materials for the task (reference materials and job aids).
   

Of course you will still take your students through the detailed steps of performing the task. But instead of focusing on memorizing the how-to information, you'll focus on the information above. While demonstrating, you can reassure them that the "clicks, keystrokes, and actions" are all included in the support materials. After the student performs the task on-the-job a few times, with the help of the support materials, then it becomes committed to memory.

In my experience, this approach avoids information overload during class while enabling students to learn complex, long tasks. Does this agree or disagree with your experience? We want to hear from you in the comments!

How to develop training when the subject is a moving target?

Recently, I received this question from someone who had read my book on Writing Successful Software Classes. My answer appears after his question:

Problem: They keep changing the software spec's, as I'm developing training!

> The company is
> currently in the process of creating and implementing a new core business operating system.
> Our legacy system is antiquated to say the least (it is DOS based).
> The new system is being built from scratch, so this is no out of the
> box ERP that we are talking about.
>
> My team and I are competent instructional designers and trainers but
> our experience is limited to training on processes or systems that are
> already complete. What I am struggling with is building training for a
> system that is being built as we are expected to develop training. If
> the system were complete and then we had 6 months to develop the
> training before it was implemented, we would be okay, but that is not
> the case...we are expected to develop training from
> Functional Design Documents which by the way are not necessarily
> well-written. The system is being given to us in milestones, but they keep changing things and changing the milestones.
>
> I have found resources on major software rollouts, and systems
> implementations, but they are very technical in nature and gloss over
> end user training. Other resources that do concentrate on technical
> training make the assumption that a system or concept is complete when
> you develop the training.
>
> Do you have any advice or ideas of how we can tackle this? Let me know
> if you want any more details. I really appreciate your thoughts and your time.

Solution: Focus on documenting business processes first, then write keystrokes-and-clicks second

Training and user documentation almost always comes at the end of a software rollout. By the time the trainers and technical writers have the information we need, almost everyone else has finished their part of the project. And when people at the beginning of the project take more time than planned, and the deadline stays the same, that extra time they get must be taken from someone else. Usually, that's the trainers and technical writers. "We allocated three weeks for you to develop training, but testing and bug fixing took an extra week, so we had to shorten your time to two weeks."

At most companies, this is just the nature of the job. There are ways we can adapt.

First, focus on writing good instructions for your users. Unless your users must perform their work without referring to a manual, the instructions will be the user's safety net when they need to begin using the software.

Research I've done among the users that I serve showed that they prefer printed instructions. They don't like switching between two windows on their computer screen: one with instructions and one with the software. Among my users who have dual monitors, that is not a problem. But most of my users have a single, 17- or 19-inch monitor. I suspect that is why they prefer printed instructions.

Notice that I've been using the term "instructions" and not "user manual." A user manual is more than a collection of instructions. It gives background and context to the instructions. That is, a user manual doesn't just tell how to perform tasks, but also when and why. Think of instructions as a series of cheat sheets, or quick reference guides.

As you're writing those instructions, you will be simultaneously developing the demonstration that you use for training. More on that later. (At this point, you were probably wondering when I'd get around to answering your question about developing training. Hang in there).

Our biggest challenge is that as we are writing user instructions and developing training, the software is changing. We need to document and develop training for a moving target. How to do this? Here's something that has been key for me: start first with the information that will not change.

Forget about beginning your writing and course development with the introduction, or the clicks and keystrokes. Instead, begin with the information this is most unlikely to change.

In my experience, the specific list of business tasks that users need to perform with the software is unlikely to change. So I start with that. For example, suppose the business tasks I must teach are:

1. Create a new customer.


2. Enter customer demographics.


3. Attach a mortgage record to the customer.

Each of those tasks will have a quick reference guide, and a demonstration in your training class.

Now, I understand that you do not yet have the keystrokes for performing those tasks. The software is changing, so you can't write the keystrokes and clicks yet. But there are some things you can write about each of these tasks, such as:

• When to perform this task (where does if fit into your workflow?)


• Why to perform this task (what deliverable is produced; what result?)


• Next steps (what do you usually do next?)

So on each of your quick reference guides, you can add that information. For example, for the task "Create a new customer" your quick reference document might look like this:

Section: Creating a new customer

Subsection: When must you create a new customer? [This is business process information. You should be able to write this even if they don't have the software finished]
Subsection: When How to create a new customer [This subsection isblank, you don't have the keystrokes and clicks yet because they keep changing them on you]
Subsection: Results [This is business process information. You should be able to write this even if they don't have the software finished]
Subsection: Next steps [This is business process information. You should be able to write this even if they don't have the software finished]

Notice in that example above, you can write three out of four subsections even while the software is still being changed.

Remember I said that you can simultaneously develop the training demo? So at the same time that you start writing these instructions, you can start writing the slideshow for class. Your slides might read something like this:

Slide 1: Creating a new customer
When must you create a new customer?
Create new customer only when...
Slide 2: Demo
...blank slide, here you begin your demonstration...
Slide 3: Results
A new customer record in....
Slide 4: Next steps
At this point, you can now do this....

You can also start writing the in-class exercise, if there is one. For example, "Create a new customer using the following information..." During the exercise, you would have the students try to perform the task, using the quick reference guide that you wrote.

At this point, you send the instructions back to the subject matter experts for their sign-off. Since you don't have the keystrokes and clicks yet, you probably won't be sending the material to the software guys for sign-off.
But what you do have is the business process information, that is, what the user will do and where that fits into their workflow. So you will send this to the business owner of the software.

As the software team finalizes the screens, you'll be able to fill in your instructions with the keystrokes and clicks. You'll also be able to plan your training demos. When all those instructions and demos are filled in, you have most of a user manual and a nearly complete training course.

When you train, you'll make it clear that you don't expect the people in class to come out with the keystrokes and clicks memorized. That is what user documentation is for. Instead, your purpose in class is to:

• Show the students where each task fits into their workflow.


• Emphasize the critical steps in each task: things you must do.


• Stear them around the mistakes that you cannot recover from.


• Show them where to get further help with the software (if your company offers this kind of support).

In your email, you mentioned Functional Specification documents. You might be able to pull much of this information from those documents. But don't get bogged down in trying to write detailed instructions from those functional specs. It just isn't realistic to document clicks and keystrokes until you have a working product in front of you, and an authority figure who says, "freeze this interface here." Until then, you are writing the framework, or outline, into which you will drop these keystrokes and clicks.

This is the process that has worked for me. I hope that you will find it useful. If you have any questions, I'd be happy to help.

Balancing Act: Keeping Your Screen Movies Small and Beautiful

Screen recordings are a valuable tool for enhancing training, tutorials, manuals and websites. Companies use this technique to produce streaming and downloadable content. The recording tools are readily available and affordable.

In this article, we explore some techniques, tips and tricks for recording sound, mouse movement and happenings from your screen to an AVI file.

File Size vs. Movie Quality

One key to successful screen movies is keeping the files small. Larger files mean longer processing times for you and longer download times for your users. Especially large screen movies may not play at all for some users with outmoded PCs. Also, large files do not stream well over the Internet.

Unfortunately, larger files result in better quality movies. More colors, smoother action, and higher quality sound are all benefits of larger file sizes. Therefore, your most important - and most difficult -- decisions will balance file size against quality. This article presents technique for keeping file sizes small while retaining the quality you need in your screen movies.

Tip 1: Select Your Color Settings

Before you record a screen movie, you need to configure your display for color depth. We recommend setting your color depth to 256 colors, or 8 bits. In Windows, you do this by selecting Start | Settings | Control Panel and then double-clicking the Display icon.

Today, many computers work in True Color. True Color uses 24 or 32 bits per pixel, and can render millions of colors. Let's assume you're capturing an area that is 320 by 240 pixels. That's 76,800 pixels for every complete frame captured. How much storage space would each complete frame in this movie occupy?

Bit Depth	Colors	Storage Space per Complete Frame (320 by 240 pixels)
8	256	76,800 Bytes (76.8kB)
16	64K	153,600 Bytes (153.6kB)
24	16.7 million	230,400 Bytes (230.4kB)

As you can see from the table above, each frame in True color mode contains a lot of information to capture from the screen memory. This information must then be compressed and written to the AVI file. That process requires a lot of time, processor power, and disk space.

In many cases, the programs that you capture will look as good in 8 bit color mode as in True Color. The capture programs optimize the color map to make the best use of them, so you do not lose much quality unless your subject demands higher color depth. In 8-bit color mode the amount of information to capture and compress is a fraction of that in the other modes. These pictures compress the fastest, and produce the smallest AVI files.

If you must record in higher than 256 color mode, consider using 16 bits, and use Intel Indeo codec, configured to the "Quick Compress" option. If you don't have Indeo installed on your machine, you can download it for free from Intel's web site, http://developer.intel.com/ial/indeo/. On HyperCam, for example, this will compress about 10-20% faster than with the default codec of MS Video 1.

A final word of advice on setting colors: You may be tempted to record in True Color and then convert the file to 8 bit color depth. There are two reasons to avoid this. First, the software you are recording will probably do a better job of picking which 256 colors it displays best in, than the screen recording software. So, set your display to 256 colors and let the application you are recording pick its palette. Second, saving and processing a file in True Color takes more time than in 256-color mode. This extra time is wasted if you're just going to convert to 256 colors.

Tip 2: Select a Frame Rate. How Low Can You Go?

The frame rate is the number of frames per second that you record and play back. Television uses about 30 frames per second, and movies about 60 frames per second. This results in very smooth action. However, frame rates this high create very large computer files.

The frame rate needed for smooth motion depends on how fast objects move across the screen, and on the size of the objects. Small, fast moving objects tend to blink as they move. This occurs when the image of a moving object is present in one frame, but not in the next. For example, a cursor moving quickly across the screen will tend to blink. If your screen movie must include such objects, you'll need a high frame rate: 15 to 60 frames per second. If you keep the action on the screen slow, you can obtain good results with a frame rate as low as 2 to 5 frames per second.

Use these recommendations as a guideline, and experiment with a few settings to see how low you can go with the frame rate. The only way to determine how low you can go while maintaining quality is to record and play back a few samples.

HyperCam, like most screen recording software, enables you to select the frame rate for your recording.

Tip 3: Set Key Frames

Your screen capture software does not store information for every single pixel in a frame. Instead, it stores the information for which pixels have changed since the previous frame. For example, assume two frames are identical except that the cursor has changed position. The capture software will store information for only the pixels that have changed because of the cursor's movement. The majority of the screen stayed the same from the first frame to the second. Therefore, there is no need to repeat this information in the second frame. This storage method saves a lot of disk space and results in faster playback.

However, the longer a movie plays, the greater the errors introduced by this storage method. To correct any errors, your recording software inserts key frames. A key frame is a completely recorded frame, with all of its information intact. Then, beginning with the key frame, the software once again records only the changes from frame to frame. When it hits another key frame, it records the entire frame, begins recording only the changes... and so on, again and again.

Because key frames take more storage space than normal frames, the more key frames in your screen movie the larger the file. In our example of recording a 320 by 240 movie at 256 colors, each key frame occupies 76.8kB.

Most programs will automatically choose every tenth frame as a key frame. Most will also enable you to choose how often to insert a key frame.

If your screen movie contains a lot of zooming, panning, and other movement, you'll need more key frames to keep the quality high (every tenth or even fifth frame). If changes from frame to frame are small, you can select fewer key frames and still retain high quality (every fifteenth to thirtieth frame).

As in choosing the frame rate, the only way to determine the minimum number of key frames for the quality you need is to take a few test recordings.

Tip 4: Select the Recording Region

Some screen recording software enables you to select a specific region or Window to record. You can usually select the recording region in three ways:

• Select an area of you display by dragging a selection rectangle. Everything inside the rectangle will be recorded.
• Select a specific window.
• Specify the X and Y coordinates of the recording area on your display.

The smaller the recording area, the smaller your file size.

The best method for determining the minimum size recording area is practice. Run through the sequence you need to record several times, and determine the minimum size window that the sequence requires.

Also, instead of choosing to record the entire window in which the program is running, consider selecting only the interior of the window. If the window's title bar, scroll bar, and status bar do not add useful information, do not record them.

Some programs enable you to move the recording area around the screen, so that you can pan from one area to another. The resulting movie is like watching a large screen through a small, moving window. This is a powerful technique for showing large areas with a small movie. However, it can be disorienting. Keep the action slow and use narration to clearly explain when and where you are panning.

Tip 5: Select the Right Audio Settings

Most of the space your screen movie occupies is comprised of video information. That is why we have focused on techniques for minimizing the size of the video information while still retaining quality. However, selecting the right audio settings can also minimize file size.

First, determine if your screen movie software enables you to select mono or stereo sound. Unless you have a compelling reason to record in stereo, select mono.

Second, select the proper number of bits rate for the quality of sound you want. Most software enables you to choose between 8 bit and 16 bit samples. Think of a sample as a pixel of sound. The more bits you use to store a screen pixel, the greater the number of colors that pixel can take. The more bits you use to store a sound sample, the greater the frequency response of the sample captured. Try your audio setting at 16 bits per sample, before going down to 8 bits. The difference in sound quality between 8 and 16 bits is usually very noticeable, so this is a good place to spend some file size.

Third, select the sampling rate. The sampling rate is how many times per second the capture software will record sound. For example, a sampling rate of 8000 means that the software is capturing 8000 slices of sound every second. For most screen movies with voice narration, a sampling rate of 11025 gives good quality with minimum file size. This combination of bits per sample and sampling rate is approximately equal in quality to an FM radio.

Screen recordings can be valuable tools for demos, tutorials, training videos and various technical applications. The latest commercial and open source tools provide this capability in easy-to-use and affordable packages - take advantage of this great technology!

Taking and Making Better Screenshots

If you’ve been a technical writer for more than 15 minutes, you’ve probably had to take a few screen shots while documenting software. Most tech writers have their favorite software for capturing and processing static screen shots. I won’t compare these applications or try to tell you how to use them. Instead, I’ll give you techniques that help you produce the best possible screen shots, no matter what application you choose.

This article assumes that you’ve taken screen shots before. It uses terms like “hot keys” and “time delay” and “capture cursor.” If you don’t know what these terms mean, look them up in the help for your screen capture software. They represent standard features that are found in most screen capture applications.

This article contains three sections. Each section contains three tips for improving your screen shots. You can print this list of techniques and keep it as a reminder when creating screenshots:

Before the Shot

• Reduce Colors on Your Display
• Decide Which Steps to Shoot
• Get Set to Capture the Action

While Taking the Shot

• Crop Out Extraneous Information
• Set a Time Delay
• Capture the Sequence of Windows

Processing the Shot

• Screen Size: 75% - 50% - 25%
• Edit to Compress
• For Odd Shapes Set Transparency

Before the Shot

A good screen shot starts before you take the picture. You can do several things to set up for a better screen shot:

• Reduce Colors on Your Display
• Decide Which Steps to Shoot
• Get Set to Capture the Action

Reduce Colors on Your Display

The fewer colors in a screen shot, the less disk space it takes up. That’s important for download speed, printing speed, and file storage.

Usually, the best way to reduce the number of colors in a screen shot is to take the shot on a display that’s using fewer colors. This usually gives better results than taking the shot on a display with more colors and then reducing the number of colors after the shot.

Below, the first screen shot on the left was taken at 16 million colors, converted to 256 colors, and then saved as a .png file. Notice the banding by the model’s right eye. The second shot was taken at 256 colors and saved as a .png file. The transitions between shades of grey are much smoother in this version.

Taken in True Color and Converted to 256 Colors

Taken with Screen Set to 256 Colors

Decide Which Steps to Shoot

Do you need to take a screen shot of every step? Probably not.

For example, in Step 1 below the sequence on the left shows the Save As dialog box before the user clicks the New Folder icon. The Save As dialog box is clearly labeled as such, making the screen shot in Step 1 unnecessary. Step 1’s screen shot would be necessary only if the new dialog box were difficult to identify or if you needed to point out special features before the user begins interacting with it.

Step 1’s screen shot could be eliminated with very little loss of usability. This is especially true for screens and dialog boxes that are common (like Save As and Open), and that conform to Windows standards.

The sequence on the right shows the Save As dialog box only after the user begins performing actions inside it. The instructions take less room and are just as clear.

Screen Shot for Every Step	Screen Shot for Selected Step
1. This brings up the Save As dialog box: 2. Create a new folder by clicking the New Folder icon:	1. This brings up the Save As dialog box. 2. Create a new folder by clicking the New Folder icon:

Focus on the Action

If a screen shot illustrates an instruction, then use color or shading to focus on the action. This tip is especially useful for selecting menu items.

For example, let’s use the instruction “From the File menu, select Save.” Below, the shot on the left just shows the File menu pulled down. The reader must search for the Save command. The shot on the right shows the screen while the user performs the instruction. The user immediately sees what must be done in this instruction.

Before the Action

During the Action

Including the cursor in a screen shot is usually a good idea, because it’s an easy way to direct the user’s eye to the action.

While Taking the Shot

While taking the actual screen shot, you can do several things to improve the result:

• Crop Out Extraneous Information
• Set a Time Delay
• Capture the Sequence of Windows

Crop Out Extraneous Information

If the user is interacting with only a small portion of a screen, and that portion is easy to find and easily distinguishable from other portions of the screen, then show only that portion. In the example below, there is only one OK button on the screen that the user could possibly click on. The screen shot on the left shows the button’s position in relation to the rest of the screen, but in a screen this small that doesn’t add much value.

Too Much Screen Click the OK button:

Enough Screen Click

Set a Time Delay

Most screen capture software enables you to capture menus while they are pulled down. You do this by setting the software to capture the cursor. This works with most applications. Some applications, however, will fold up their menus when you press the hotkeys on your screen capture software.

Usually, you then make sure that the hot keys for your screen capture are not interfering with the application. For example, you would make sure that the hot key for your screen capture software is not [Ctrl]-[S], which in most applications is the Save command. Trying to take a picture of a menu pulled down with this hot key would cause most applications to collapse the menu and begin the save process.

When changing the hotkeys fails to solve the problem, frustration ensues. You may even give up on capturing the menu in action. Try this:

1. Set your screen shot software to a time delay of a few seconds.
2. Hit the hotkeys to take the shot.
3. During the delay, choose the menu items you need to set up the shot.
4. Hold still…
5. The screen shot software takes the shot. Success!

Capture the Sequence of Windows

If the user does something to spawn a new window, you may want to show the relationship between the original and new window. Or, you may want to show how information carries over from the original to the new window. In these cases, consider taking a shot of the new, spawned window overlapping the original window.

In the example below, the active window is the result of double-clicking on the appointment in the Calendar window. The Subject and Location data carries over from what is displayed in the Calendar window. This shot clearly displays the relationship between the two windows.

Processing the Shot

These techniques may help you while processing your screen shots:

• Screen Size: 75% - 50% - 25%
• Edit to Compress
• For Odd Shapes Set Transparency

Screen Size: 75% - 50% - 25%

Most paper documentation is read at 75% of the distance to a computer screen. This means you can make screen shots 75% of their actual size and most users will see on paper exactly what is on screen. Use this size screen shot when all of the detail in the screen shot must be clear and all text in the shot must be legible.

If the user needs to read only the large text in a screen, you can usually make the screen shot 50% of actual size. This works for most screens where the display font is 11 or 12 points.

If the user needs to locate the major objects in a screen, but not read text, 25% of actual size is adequate.

Edit to Compress

Sometimes, resizing a screen shot so that it fits a page results in a shot that is unreadable. This usually happens when the elements of a screen have a lot of empty space between them. For example, this screen shot from the home page of the CIA is 641 pixels wide:

Let’s assume you need to resize this so that it fits your page’s margins. Here’s the result:

Notice that the links have gotten difficult to read.

An alternative to resizing is editing to compress. In the example below, I used the marquee tool to select the links on the right and drag them to the left. Then, I cropped off the excess from the right side. Here’s the result:

You may have ethical concerns about editing a screen like this. If so, consider adding a notation that the screen shot has been “edited for size.”

For Odd Shapes Set Transparency

In the example below, a screen shot was taken of two overlapping windows and pasted into an electronic slide. Notice that the lower left corner consists of extraneous information. It also obscures the company logo:

To correct this, the screen shot was processed in a graphics program as follows:

1. The area to be transparent was filled with a color that is not used anywhere else in the graphic. In this case, bright green:
   
   
2. The transparency for the graphic was set to the fill color (bright green):
   
   
   
3. The graphic was saved as a .gif file.
4. Finally, the graphic was imported into the slide:
   
   
   Technically, the graphic still overlaps the company logo, but because the overlapping part of the graphic is transparent the logo shows through.