Online Learning

6 Dimensions for More Effective Online Instructional Videos

Quality instructional videos require a balance of content, design, teaching style and more. Here are six factors to consider.

When I first started my career as a senior instructional designer for Microsoft's startup E-Commerce Division 25 years ago, there were no reliable standards of quality for online instruction or courseware. The fact that one could create any type of learning product at all that functioned without crashing on the crude online platforms then available was still considered a minor miracle. Anyone who could legitimately claim the slimmest degree of expertise in any aspect of online learning design, or had even remotely related skills, was likely to have plenty of interviews and more than enough job offers.

Today, the tools of the online instructional design trade are far easier to work with, and support in using them infinitely more available. Companies are no longer impressed that an instructional design job applicant can create online materials quickly using a set of industry-standard software applications. They are looking for professionals who can put together lean, attractive and highly effective online courseware — and have portfolios to prove it. Today's designers need to know what separates a merely adequate product from the totally awesome.

Having trained more than 300 new instructional designers in the Masters of Education program in Instructional Design and Technology at West Texas A&M University in recent years, I know my students would love a recipe book with precise quantities for all the listed ingredients. Specific values for color relations, the optimum number of view changes per minute, the perfect number of bullet points on a summary graphic, would all be most welcome. But designing online instruction is still as much art as science and cannot be reduced to a notebook of formulas. That is a good thing. It means someone who has developed an intuitive creative sense about what works best can still distance themselves in quality from those who are merely following artificial design rules and arbitrary, often outdated, institutional standards. It is still possible to stand out from the pack.

In a sense, it's a lot like photography. A photographer needs to be aware of compositional balance, white balance, f-stop and many other technical factors that can be adjusted either in the camera or in post-production. There are no "perfect settings" for any of these, as it always depends on what the photographer is trying to accomplish in the moment. Similarly, there are design factors that the instructional designer of online courseware must keep in mind and consciously balance. Here are six dimensions that must be well tuned for a successful online instructional video project.

1) Sound-to-Silence Balance

Sound-to-silence balance is the ratio of talk to empty space on the soundtrack of your video. Tools like Camtasia and Captivate show the soundtrack as a display of the visible waveforms, which makes it easy to see this balance at a glance without listening to the content itself.

Beginning instructional design students often try to record their videos from sketchy outlines or vague, fragmentary scripts. They are not quite "winging it" — but are not fully prepared either. Turning such scripts into training content requires a lot of thinking on one's feet and choosing specific words during the recording process, which results in many pauses of varying length. Too many such pauses can make your work sound tentative, unauthoritative and boring.

Even with a solid script or a strong outline of detailed talking points to take into a recording session, I find that about 40 percent of my first-take soundtrack ends up on the virtual cutting room floor. When I need to sound extremely confident and fully professional, the delete key is my best friend.

I go through every second of every instructional movie and ruthlessly eliminate filler words like "uh" and "so." Of course, any statement that has too much potential for confusion or misapprehension has to go. Often, I can just eliminate the problem bit of sound and make a visual adjustment to the screen display that will convey what I wished to say. Just as often, I decide that nothing is lost by simply cutting the awkward portion.

The most common loss of sound content by far is the pauses that happen when I am searching my mind for the perfect word to express a concept. Even when I am very comfortable with the material and have taught it many times before, this can result in as much as 10-20 percent loss of the first-cut product length. (I'm 64, and it would probably be a little less if I were younger!)

Some students and early-career designers take a brute force approach to this problem. They simply scan the waveforms on the soundtrack and cut almost all dead space between waves, even before actually listening to what is being said. This certainly speeds up the editing process, but there are two problems with this approach. The first is that sometimes you are demonstrating a procedure on the screen and it actually takes some silent time either for you to execute a step or for your computer to respond. If you cut the silence out of the audio, you will also be cutting out the video where the work is taking place.

This leads to another debate about whether a recorded demonstration of a computer task should take place in real time or accelerated time. Accelerated time can be very helpful as long as audience members fully understand that they are looking at and hearing accelerated time. For example, there is no need for an audience to watch you type a complete sentence or more. If you show them the first few keystrokes and the last few, they will understand that you also typed what was in the middle. If you are demonstrating a compile process and the computer needs to chug along for four or five minutes, there is no need for your audience to stare impatiently at a thermometer completion bar for that time. Just mention that you are skipping ahead and coming back when the process in progress is complete. Like a good television chef, you can put your casserole in one oven and immediately take a fully baked version out of another.

The second problem with mechanically eliminating pauses from the soundtrack is that the audience needs a certain amount of time between statements to process what is going past. If you eliminate too much of the silence in between bursts of speech, the result can be breathless, rushed and difficult to absorb. Students will find themselves having to listen to your video with a finger on the pause button, always trying to catch up to you. It takes practice to trim a soundtrack to the perfect balance point so that it has a confident brisk pace, but still seems relaxed and in control.

2) Visual Context-to-Detail Balance

Visual context-to-detail balance is the control of how often your video editing tool is zooming in and zooming out. Some video tools, such as Camtasia's Smart Focus, allow the software to make these decisions for you, based on the movement of your on-screen cursor, but the top-end instructional designer will always want to control location and magnification precisely and, therefore, manually.

Just as in sound-to-silence balance, it is possible to damage the effectiveness of your presentation by erring in either direction. If you are constantly zoomed out to a whole screen view during the demonstration of a computer procedure, your audience may also have difficulty seeing what you are trying to demonstrate, especially if the screen type is small. If viewers try to compensate by blowing up the image size on their end, they could introduce screen resolution problems. If you are constantly zoomed in to the small details, your audience may lose the context of how the element that you are demonstrating relates to the rest of the screen.

Visual context-to-detail balance practice has been somewhat subject to fashion over the years. It used to be considered good practice to zoom all over the place every few seconds, concentrating first on one element and then another. In recent years, good practice has shifted to a more stable and less dizzying approach, with more full-screen views and fewer screen-focus adjustments. This is partially because the on-screen annotation tools, like animated arrows and boxes, have become so much more sophisticated and easier to use. You can now focus more easily on a single screen element even when the whole screen is in view, provided the element is not too tiny.

Another factor in creating this balance is the level of your target audience. Novices can easily get confused about what they are looking at when all they see are many small portions of a screen in rapid succession. Experienced users are more comfortable with the layout of graphical user interfaces, and so can take advantage of the detailed views more without losing context.

One compromise is to move through full-screen display on the way from one detail to another. For example, imagine you are demonstrating an application and need to focus on a detail in the lower-right corner and then another in the upper-right corner. Instead of just panning from lower-right to upper-right (which doesn't establish that you are on the right-hand side of the screen at all since the whole screen is never seen), you can go from the lower-right detail to a full-screen view first. After a few seconds of full-screen, you can then move to the upper-right detail. Then you will have established the relative position of both detail elements. As with every option, this technique has its cost. You are clearly doubling the amount of zoom movement every time you move through full-screen on the way to another detail, but it may well be worth it to keep a novice audience in context and on track.

3) Feature-to-Application Balance

This is the balance between showing program features in the context of the entire application and giving specific examples of their use.

One of end of this continuum is the feature/function/benefit (FFB) approach, popular in the early days of computer software instruction. It could be summarized as, "It has this, which does that, which allows you to achieve this type of task." FFB is extremely popular in the training provided by hardware and software manufacturers who wish to showcase all the features that their product has and their competitors' products lack. Such training always highlights the latest wrinkles and gizmos, even if only a small percentage of the training audience has any use for them.

FFB tends to be very encyclopedic and often systematically goes through every option in the main menu structure. It can be dull, but also very useful, since it can create a conceptual picture of a software product that facilitates recall. Once we have this schema in mind, we are more likely to remember that a certain function exists, even if we are unclear on just how it is used. Then there can be a second wave of "just-in-time" learning, where we actually go back, find the function in the product, access the help files and learn to really use it to accomplish meaningful work.

The opposite of FFB is the threaded scenario approach. Imagine several important product functions as beads that are threaded on a string of a single integrated project. The focus here is on the project, not on the software tool. The order in which features are introduced is determined by when they are needed in the project, and each feature is only explored to the extent that the project requires it. This approach is often used early in a training program as a "quickstart." The student gets to see what a product or feature can do in a realistic context first through one example of its use. Only later does he or she get to thoroughly learn how the feature works and its many permutations.

High-quality threaded scenarios can be tricky to do well. The whole idea is for the project to be realistic and for the program functions to be used as they typically would be in practice. But what happens when some important functionality just isn't needed for a given project? Rather than leave it out, scenario authors often do something wildly atypical just to give the missing functionality some exercise. A little stretching of normal good practice for this purpose is OK, but if the project gets too far away from the real-world use of the product functions, the whole exercise can become very artificial.

The criticism of FFB is that students' understanding becomes a mile wide and a quarter-inch deep. They have an idea of how the product does many things, but little or no practical experience in using it to do anything well. The criticism of the threaded scenario is that students become a mile deep but a quarter-inch wide. They can execute one amazingly impressive project very quickly because they are given all the steps, and because the project has been carefully engineered to avoid many complications that would naturally occur if the students were attempting even a considerably simpler project on their own. But the transfer value is limited. When students try to do their first independent project on their own, they discover there is a lot more to this than meets the eye.

In the end, each approach is incomplete without some components of the other. Skillful designers learn just how much of each to use and when. Again, the level of the audience is a primary determinant. If you are providing version upgrade training to a seasoned group of technicians already familiar with a technical product, a largely FFB approach might be the shortest line between where they are and where they need to be. If, on the other hand, you are trying to get a group of novices interested in the possibilities of using a software product that is largely new to them, a quickstart to demonstrate its value in relation to their needs might be a good idea. It might make them more attentive to a more comprehensive presentation of the functionality later on.

4) Balance Between Framing/Assessment and Substance

The old military training model had three parts:

  1. Tell them what you are going to tell them.
  2. Tell them.
  3. Tell them what you told them.

Today we call this framing and it is supported by David Ausubel's classic Advance Organizer model. Having a sneak preview graphic at the front-end and a review graphic at the back-end of a step-wise training segment is often a fine idea. This practice can go to several levels, with these "bookends" appearing not just at the start and end of a presentation, but also at the start and end of sections and subsections. The extreme form is signposting, where you interrupt the flow of information to say "We have just completed x and before we go on to major topic y; we need a little more information about function z, which we touched on earlier." Signposting is like a visit to Disney World: "You have now left the Sahara Exhibit and are entering the Rainforest. Turn right for Crocodile Pond, and left for Hippo Heaven."

Of course, even a technique as useful as this can also get out of hand, particularly when you are under time constraints and are dealing with a more creative topic rather than a systematic one. Some students can be resistant to what they consider to be a mechanical approach. They don't want a "school-ish" presentation. They just want the "meat-and-potatoes" of the content as fast as you can serve it up.

A related way your presentation can go off the rails is by an excess of formative assessment, or assessment along the way. Programs like Captivate and Storyline do a fine job of checking on student knowledge in the course of a presentation — which leads some instructional designers to divide the content into tiny bits and assess progress constantly. That can be both annoying for the audience and irrational from a retention point of view. The fact that you still remember and can apply something you learned 10 minutes ago does not mean it is part of your toolkit for life. It is best to stop for formative assessment only when a solid grip on the previous material is essential to make sense of the new material that will be coming up.

5) Personality Balance

Personality balance is how much of yourself as an individual you choose to express in your instructional video. The starting point of this balance is usually determined by the personality of the instructional designer, especially when that designer is also the on-screen "talent" in the video.

Some naturally shy designers/presenters tend to appear on-screen as excessively wooden and formal. This is especially true when they are primarily subject-matter experts rather than performers. They fail to convey their enthusiasm for the subject matter even when it is quite strong. They leave the audience asking, "If my instructor is so minimally invested in this product, why should I be any more so?"

On the other end of the spectrum, extroverted presenters can forget that it's all about transferring marketable skills and not really about how adorable they are personally. They can float off topic, tell too many stories from personal experience, use too much colorful language to convey simple points, and basically get lost in their own glory.

The ideal tone for most presentations is that of a clearly competent and enthusiastic professional who is visibly excited about the great stuff he or she has to share, and is delighted to be the one who is sharing it. Once this persona is established, the talent gets out of the way and lets the subject matter be the star of the show.

But this is not always the right balance, depending on subject and audience. For example, I teach one course I call "Getting and Keeping a Professional Job with Instructional Design Skills." This soft-skills course is all about what I have learned in my career, and is loaded with personal anecdotes and examples of what I have experienced. In this case, a more instructor-centered approach is a good fit.

6) Balance Between Training Solutions and Non-Training Solutions

As an instructional designer, you will need to decide not only how to design but when to design. When a project is proposed, you need to determine whether the objective your organization wishes you to achieve is actually a candidate for training at all.

Imagine a help desk at a mid-size organization. There is a protocol in place that defines the eight steps that are supposed to take place every time a trouble call is filed. Management has determined that the protocol is not being followed, and requests online training to cover the eight steps and the importance of following protocol. Before you type the first word of a project plan, it would be very wise to spend some time down at the help desk. You might discover that the compensation of each technician is based on their competitive ranking for how many calls they process in a work week. As they are currently organized, there is a price to be paid for not processing enough calls and no price to be paid for handling them quickly with little respect for the protocol. If respecting the protocol is really important, there is a problem — it's just not a training problem.

Now that we see the importance of getting the six factors in balance, we can close by considering just how that is done:

It has often been reported that the spaceship that went to the moon needed to have its course evaluated and corrected by technology every few seconds. Without these myriad corrections, it would have hurtled off into trackless space. A major design project is like that, with countless corrections to be made along the way. You need to find a test group that is very much like your target audience. (It is a mistake to test your emerging learning product with a room full of subject-matter experts.) Once your test crew is in place, use them early and often as new pieces of your training product are developed. At first, you will find that your efforts to get one dimension of the project in balance will tend to throw other aspects out of balance. Eventually you will discover the sweet spot where the product is as good as it can be, and further tinkering will not lead to improvement. That is when you call it done.

comments powered by Disqus

Campus Technology News

Sign up for our newsletter.

I agree to this site's Privacy Policy.