Estimating the time to create a training course

The Question

I received this email asking how to estimate the time it takes to create a software training course:

Hello,

I have a strong background in software development and training development and delivery. My training has always been around soft skills, business processes, and employee orientations.

I recently joined a software company as the Training Manager and I’ve been tasked with “figure out how we should do user training for our product”. I’ve purchased and read your book, User Training for Busy Programmers and it’s been very helpful already in translating my current knowledge of software development and non-software training into what I need to do for software user training.

I was wondering if you have any thoughts or resources around estimating the time it takes to develop user training following the process you outline in the book?

Thank you,

Jennifer

The (somewhat disappointing) Answer

Here's my reply:

Jennifer,

Years ago I asked this question on several of the most popular training and technical writing mailing lists. I also tried equating the time it took to develop training and documentation to things like function point counting, number of screens, number of keystrokes and clicks. None of it worked.

Seriously. The conclusion I arrived at is that there is way to predict the time to develop training and documentation, that is more accurate than your own experience.

Since you have experience developing training in business processes, you're not far off from being able to accurately estimate time to develop training for software. Because at the end of the day, a software class is (or should be) nothing more than a business process class that features a new tool. So when you're trying to estimate development and delivery time for a software class, ask yourself how long it would take to develop and deliver the class if you approached it as teaching a new business process, which just happens to use a new tool.

Sorry I couldn't give a more concrete answer. This is a question the continually challenges me, and I'd be happy to hear of any resources you find that help with it.

Regards,

William Rice

A Plea for Help

I want to hear what you have to say about estimating the time it takes to develop a software training class. Do you have any objective, quantitative methods that work for you? Or like me, must you rely on intuition and experience? How accurate are your estimates?

This topic is ripe for conversation. Leave a comment, and keep the dialog moving!

Creating an Instructor Kit

After you've tested the in-class exercises, polished the presentation
materials, printed the handouts and workbooks, and created the data files
for class, are you ready to hand over the course to an instructor? Not
yet. You have one more thing to do before calling your course finished:
Create the instructor kit.

An instructor kit often differentiates a good course from an exceptional
course. It is more than a pretty package or a finishing touch. It is an
integral part of any training course that you must hand off to an instructor.
The instructor kit's ultimate goal is to increase the quality of the students'
experience, by helping the instructor to assimilate, set up, and deliver
your course.

This article addresses creating an instructor kit for a software course.
However, 90% of this article is directly applicable to creating an instructor
kit for any technical course, and the other 10% is easily adaptable to
non-software courses.

What is in an Instructor Kit?

An instructor kit consists of information and tools.
Most of the information helps the instructor teach. Most of the tools
help the instructor set up, reset, and delete the course. The information
that you should include in an instructor kit is listed below. The software tools that you should include are described after that.

Types of Information in an Instructor Kit

Most instructor kits require the following types of information:

Prerequisites

Prerequisites include:

• Proficiencies the instructor must have to teach the course.
  


• Information the instructor must know about the subject.
  


• Minimum equipment and software needed to teach the course.
  

Setup Directions

Setup directions include:

• Required settings and configurations for the equipment and software before installing the course.
  
• Directions for installing the course files.
  
• Required settings and configurations for the equipment and software after installing the course.
  
• Directions for testing the installation.
  

Delivery Information

Delivery information includes:

• The location of any data or documents that the instructor or student will use in class.
  
• The location of any data or documents, and a list of functions or menu items, that the instructor should steer students away from.
  
• Key points that the instructor must address in class.
  
• Directions for demonstrations.
  
• Information to help the instructor coach students through workshops.
  
• Directions for using the tools listed in the next section.
  

Reset Information

Reset information includes:

• A description of the state of the data and documents used in class, after class.
  
• Directions for returning data and documents to their pre-class state.
  
• Directions for testing the reset procedure.
  

De-installation Directions

De-installation directions tell the instructor how to de-install all
software placed on the training computers, and how to reset the computers
to their original state.

Types of Tools in an Instructor Kit

For a software course, most tools consist of software designed to help
the instructor present the course, such as:

• Installation Software.
  
• Electronic Slide Shows.
  
• Reset Software.
  

Tools may also include a printed instructor guide, and hardware needed
for the course. Most instructor kits require the following types of tools:

Instructor Guide

The Instructor Guide contains all of the information given above. It
is usually a printed document, but most instructor kits also include an
electronic version of the document.

Installation Software

The installation software may be simply files that the instructor copies
to the classroom PCs, or an application that performs the installation
when launched. The installation software can:

• Install the data used during the course.
  
• Install the documents and files used during the course.
  
• Install the Electronic Slide Show.
  
• Configure the settings on the computer(s) used during the course.
  

A course may require separate installation routines and files for the
instructor and students. A non-software course may instead have equipment
that is used during setup. This equipment may differ for the instructor
and student.

Electronic Slide Shows

Electronic slide shows are usually created with an application like PowerPoint
or Astound!. The slide shows may be installed by the same software as
the data and documents used during the course. Or, it may require its
own installation software.A tutorial on creating electronic slide shows
for technical training is beyond the scope of this article.

Training Applications

Training applicatioins consist of the applications that students and
the instructor need for the course. This may include the actual application
being taught, and also:

• The application used to run the slide show.
  
• Applications used to examine documents.
  
• Applications used to examine, create, or modify data that is used in class.
  

Training Files

Training files consist of the data and documents used during class. The
instructor may receive more complete versions of the data, for demonstrating
the results of in-class exercises. If this is so, the instructor and students
will need separate installation routines.

Reset Software

Reset software returns the data and documents used during class to their
pre-class state. It also resets and software settings that the students
changed during class.

De-installation Software

De-installation software removes all training software from the computers
used during training. It also returns the computers to their original
settings.

Outline for the Instructor Kit Guide

Use the following outline as a starting point for writing your instructor guide. I've numbered the sections so that you can see the hierarchy.

1. Introduction to the Course

Explain why the course is taught, what the course covers, and to whom it is taught.

1.1Purpose

List the proficiencies the students will develop during the course.

1.2 Software Covered

States the software that the students will learn to use. Include the version numbers and platforms for the software.

1.3 Audience

Describe the audience and the audience’s situation. For example, "This course is designed for line managers at Company X who must create budgets for the groups they manage."

1.4 Agenda

State the high-level topics and estimates for the time to teach each topic.

2. Contents of this Instructor Kit

An instructor kit is often packaged into a binder that includes a written instructor guide and CD containing all software and files. Usually, the majority of this section lists and describes the files on the CD.

2.1 Documents

Describe the purpose and format of any documents used during this course. If a document must be printed for the course, state so in its description. State when each document is used in the course.

2.2 Data Files

List and describe the data files used in the course. Stating when each file is used helps the instructor trace any problems during the course to a faulty installation. For example, suppose an exercise in loading data does not produce the intended results. If the instructor knows that FileX is used in this exercise, the instructor can check the installation of that file while troubleshooting the workshop.

2.3 Applications

If the course requires the installation of any applications, include the installation files and instructions.

2.4 Hardware

If the course requires special hardware that is not available at the training site, include the hardware in the instructor kit.

3. Prerequisites

This section describes all prerequisites for the course. Prerequisites can include physical items, software, and knowledge.

3.1 Room Equipment

List and describe the non-computer equipment the instructor needs to teach the course. Some items that might appear on this list are:

• A whiteboard.
• A flip chart.
• An overhead projector.
• Give-aways for students.
• Name cards for students and instructor.
• Items used during training games or demonstrations.

3.2 PC Hardware

List the minimum requirements for the student computers, and the instructor computer. Some of the requirements:

• The amount of memory. Does the instructor computer need more memory to run the training application and slide show concurrently?.
• The amount of free hard disk space. Do the instructor files take up extra disk space?
• Processor speed.
• Display resolution.
• Floppy, CD, and/or DVD drives.
• A printer.

3.3 Software

The software on which you are training is an obvious choice for this list. Also consider any applications needed for opening files used during training. For example, if you load a graphics file into the training application during class, will you need a graphics application to examine or edit the file before loading it? If you supply documents in .pdf format, will the students need Adobe Acrobat to view them? If the training application exports data to a spreadsheet, will you need a spreadsheet application to examine the data?

3.4 Instructor Proficiencies

This can consist of a list of tasks the instructor is proficient in. Or, it can state that the instructor must have a certain amount of experience with the application.

Most in-class exercises begin with a list of the proficiencies developed during the exercise. One easy way to complete this section is copying those lists into this subsection.

3.5 Instructor Knowledge

An often-overlooked prerequisite for many technical training courses is instructor knowledge of the business processes that happen before and after training. The instructor should also know who supports the users after training.

Students often ask questions that go just beyond the scope of the application being taught, such as:

• What is the source of the data that the training application accepts?
• What happens to the data or files that the application outputs?
• Who is responsible for supporting the users after training, as they begin to use the application?

3.6 Student Proficiencies

Many software courses list "Basic PC skills" as a student prerequisite. Be more specific. For example, many users who claim they have "Basic PC skills" do not know how to:

• Navigate around a hard disk and find a file from within the Open File dialog box.
• Turn on the display of file name extensions. With the file name extensions turned off, "file.txt" and "file.dat" are both listed as "file."
• Right-click and use shortcut menus.

If you do not state exactly which "Basic PC skills" the student needs, the instructor may need to spend valuable class time teaching teaching remedial PC skills.

3.7 Access Rights

Many training courses are taught off-site, at a client’s offices or a rented training center. While developing the course, you have access to the application and your computer. Do not take for granted that the instructor and students will have this same access when off-site.

When writing this subsection consider whether:

• The students can access the training application from the computers in the training room.
• The instructor has administrative rights to install the training software on the training computers.
• The students can access any network files they may need from the training room.

4. Setup Directions

This section includes setup directions for both the student and instructor computers. Refer to the section on software prerequisites and determine if the instructor needs to install the training application, and supporting applications used during class.

These directions do not always need to be detailed, step-by-step instructions. However, if you assume the instructor knows how to perform some parts of the installation without detailed directions, list this assumption in the Prerequisites section under Instructor Proficiencies.

4.1 Starting Point

Give a starting point for the installation. For example, before installation:

• What software must be on the student and instructor computers?
• What settings must be configured?
• What hardware must be connected?

4.2 Installing and Testing the Student Files

This subsection gives directions for installing the applications and files used by the student.

4.3 Installing and Testing the Instructor Files

This subsection gives directions for installing the applications and files used by the instructor. Sometimes the instructor setup is a completely different process from the student setup. Other times it is an additional process.

4.4 Installing the Slide Show

This subsection gives directions for installing the slide show. The installation may be as simple as copying files to the instructor’s computer, or it may use an installation application.

5. About the Training Application

This section tells the instructor what is unique about the training application. It supplies the kind of information that an instructor will discover after hours of exploring the training application. Save your instructor some preparation time and include a section about the training application.

5.1 Limitations, Instabilities, and Non-functionality

The development of a training course often starts while the product is still in development. For software courses, this means that the training course is often developed using an application that is not completely functional. The instructor must know what parts of the training application are unstable or unusable. Discovering these while presenting the class will undermine the students’ confidence in the instructor and the application.

5.2 Login Information

The instructor and students may use different login information. If all students access the same networked application during class, each will need a separate login.

5.3 Where the Data Is

A training application rarely contains as much data as a fully-functional production application. The instructor must know which settings will show data during demonstrations. Few things are more embarrassing for an instructor than desperately trying random settings during a demonstration, in an attempt to show how the application processes data.

5.4 Differences Between Student and Instructor Applications

The instructor’s application might contain more data than the students’ application, to make demonstrations possible. Or, the instructor’s application may have the finished versions of in-class exercises. The instructor must know about these kinds of differences before class.

5.5 Installing Fail-safe Data

Most software courses require a student to complete a series of in-class exercises. The result of one exercise often provides the starting point for the next exercise. Therefore, if a student fails to produce the desired result from an exercise, the rest of the class exercises can become impossible to complete.

Fail-safe data is data that can be copied into the training application to simulate the successful completion of an exercise. This gives the student the correct starting point for the next exercise.

If you supply the instructor with fail-safe data, include instructions for copying that data into the student application.

6. Module Notes

Each module, or chapter, in a training course usually covers a specific task or group of related tasks. Most modules follow a lecture-demo-exercise sequence. The subsections described below are based on these assumptions. Repeat each of these subsections for each module, or unit, in the course.

6.1 Points to Emphasize

Is there any information that the client asked you to emphasize during the presentation? Are there any procedures or steps that, if omitted, will cause a loss of data or failure in later procedures? Hopefully, all of the information that you have included in the course is important. But this subsection is for information that is essential to the success of the students, in class or when they return to their work.

6.2 Demonstration Script

You don’t need to script the instructor demo click-by-click. Just tell the instructor enough to re-create the demo you have prepared. Of special importance is stating exactly which data to use during the demo, and where the data is located.

6.3 Pre-exercise Checklist

This is a checklist of the menu options and features that the instructor taught during this unit. Just before the instructor tells the students to start the in-class exercise, the instructor can scan this list and determine if (s)he covered all of the topics necessary for the students to succeed at the exercise.

6.4 Starting Point for Exercise

Most students follow along with the instructor during demonstrations. This means that their screens will usually not be as they left them after the last exercise.

Describe the starting point for the in-class exercise. State where in the software the students should be, and what data they should be viewing. A screen shot may be a good idea.

6.5 Fail-safe Files for Exercise

The exercises in most software courses build upon each other. For example, Exercise 2 usually uses the results of Exercise 1 as its starting point. If a student does not produce the correct result from an exercise, this can jeopardize the success of subsequent exercises.

If this is the case in your course, provide fail-safe data for each exercise. State where the data is located and how to activate, or populate, that data if the student does not succeed at the exercise.

6.6 Slide Show Printout and Instructor Notes

You may know exactly why you’ve included each bullet point on each slide, but the instructor to whom you turn over your course may be left guessing. Instructor notes give the instructor more detail about the slides.

The slides do not need to be printed out at full-page size. Two to three slides per page gives the instructor enough detail.

Writing User Manuals from the Middle Out

You need to write the user guide for a complex product. There must be a dozens of functions and hundreds of tasks that can be performed with the product. Where do you begin? How to start writing? Conventional wisdom says: start at the beginning with an introduction to the product, and work your way through each function or task in the order the customer will use them. Don't! Here's a tip I learned the hard way after my ninth or tenth year tech writing: start in the middle, and work your way outward.

This article presents a method of writing user documentation that you may find easier and more effective than starting at "Chapter 1:"

1. Start by writing procedures for each task or menu option. This is the "middle" of the document, and results in a collection of subsections.

2. Then, add material just before and after each procedure. This is working "from the middle out." The result is a collection of sections.

3. Organize the sections into chapters, and add more material to the beginning and end of each chapter.

4. Finally, organize the chapters into a manual.

I have found that this method of writing user manuals from the middle out saves time, and yields more accurate and useable documentation.

Why Not Start at the Beginning?

When you begin your manual with an introduction to the product, you also begin your research with an introduction to the product. Typically, you ask the Marketing or Sales department to describe how the product will help the user: "What will users do with it?" You ask Development or Engineering to describe the product's structure: "What is it?" You experiment with the product long enough to determine how it's used: "How does the user use it?" Then, you write your introduction. Which will probably contain inaccuracies and be less useful than it could be, for three reasons:

First, you are attempting to describe the purpose of the product ("What will users do with it?") before you have completely experienced using the product. By asking others what the product does, you are only discovering what they believe the product should do. You must first use almost every function of the product to determine what it really does. Remember, the manual is for users and should be written from a user's point of view. You can better convey the purpose and advantages of a product to a user when you have completely experienced the product from the user's point of view. This is why, in the middle-out method, you write the introduction last.

Second, you are describing the structure of the product ("What is it?") before you have experienced how the pieces of the product work together. Describing what the modules of a software application are is not nearly as useful to the user as describing what those modules do, and how they work together. You can best determine what they do and how they work together by experience.

Third, you usually develop the outline for your manual at this stage. Remember that the outline will determine the order in which you present the product's functions and tasks. And, you have not yet performed all of the product's functions and tasks. After you have experienced a complete cycle of using the product, you will be qualified to determine the order in which to present the procedures for using the product. At this point, determining the order for these procedures is guesswork.

In sum, when you begin writing a manual at Chapter 1, the manual becomes a diary of your learning curve. The first sectioins tend to be either ambiguous or self-obvious. They become ambiguous when you are conscientious enough to attempt to state something meaningful about the product, when have yet to gain real experience with the product. They become self-obvious when you attempt to state only those facts of which you are sure. Because you have little more experience than the reader, those facts will tend to be self-obvious. Starting in the middle and working outward avoids these problems.

How to Do It

To create user documentation from the inside out, follow the suggested steps below.

Write the Sections

Following the steps below will result in a collection of sections. Later, you will organize these sections into chapters, and then a manual.

1. Write the directions for each task or function.

Let's assume one of the tasks the user performs with the product is, "Create a new record." Write directions for this task. Don't worry about:

• The purpose of the task (Why create a new record).

• Where it fits into the big picture (When to create a new record).

• What the user must do or know before performing the task (Prerequisites for creating a new record).

The only thing you are writing is how to perform the task at hand.

Repeat this for each task or function the user can perform with the product. When you finish, you will have a collection of directions for performing all possible tasks or functions with the product. Label this paragraph "Directions."

2. Add prerequsites in front of each task.

Add a paragraph of prerequisites in front of each task. In our example, the prerequisite might be that the product must be in a particular mode before creating a new record. This paragraph should tell the user only and exactly what conditions must exist before the procedure can be carried out. Label this paragraph "Prerequisites."

3. Add results after each task.

A results paragraph states what the user should see to confirm that the task was successful. It also states what has changed as a result of the task. Label this paragraph "Results."

4. Add background knowledge before the prerequisites.

Examine each task and determine exactly what the user must know to successfully perform that task. Put exactly and only the background knowledge the user must know for a task immediately before the prerequisites for that task.

If several tasks require the same background knowledge, you should probably organize them into a chapter or section and place the background knowledge only once at the beginning of that chapter or section.

5. Add next steps after the results.

State what user must, should, or can do next.

After following the five steps above, you have a collection of procedures. Each procedure comprises a section, consisting of:

• Background information

• Prerequisites

• Directions

• Results

• Next steps

Organize the Sections into Chapters

Only now that you have performed every task possible with the product, and determined the prerequisites and results of each task, can you see how they fit together into the overall process of using the product. Now you are ready to determine the proper sequence for performing the tasks, the purpose of each task.

Organize the sections (procedures) into logical groups. You may organize the procedures in the order in which the user is most likely to perform them. Or, you may group procedures with similar functions together. Whatever scheme you choose, each group of sections becomes a chapter.

Now examine the procedures in each chapter and ask, is there any information that the user must know to perform these procedures? At the beginning of each chapter, add exactly and only the information the user must know to perform the procedures in that chapter. Label this section "Introduction."

Determine the Purpose of Each Procedure

Good user documentation doesn't tell the user only how to perform a procedure. It also tells the user when. Now that you have experienced and organized all of the tasks for the product, you are qualified to determine when it is appropriate to perform each procedure. A "When this... Do this..." table is one effective way of presenting this information. You can place this "When..." information in:

The introduction to the manual. You would probably include "When..." information for all of the procedures here. This is usually the easiest place for the user to find the information.

The introduction to each chapter. You would probably include "When..." information for only the procedures in the chapter here.

Each section. You would probably include "When..." information for only the procedure in the section here. This is usually the most difficult place for the user to find the information.

Finally: Write Chapter 1

Now, look at the whole manual. Is there any background info that a user must know before using any of the procedures in the whole manual? Write it down. Call it "Chapter 1: Introduction."

Assemble the chapters, generate a table of contents, and you've got yourself a manual!

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.