Contacts
Show/Do/Cue A Technique for Introductory Software Instruction
Steve Schatz, Professor of Instructional Technology at SFSU
Introducing students to new software is a challenging and frustrating task for both student and teacher. Many techniques which intuitively seem appropriate do not offer good results. Over the past several years, I have developed a combination of existing techniques which has proven surprisingly effective. I call this approach Show/Do/Cue.
The ideas pursued herein are with specific application to introducing software. There may be parallels with other types of training, but they have not been explored. They have proven effective in many different class settings with a broad base of students, from elementary through adult, and with many levels of computer experience and in many settings, but mostly in a class setting with computer access for students.
Introducing software presents unique challenges. So much of teaching is based on previous experience and knowledge. By referring to skills the student already has, one can more easily build on that framework and add new knowledge. When introducing software, there is no frame of reference. So, a training must introduce the context or metaphor as well as teach specific tools and tasks.
The Show/Do/Cue Technique
Show/Do/Cue combines parts of established techniques -- using lecture, demonstration, coaching, printed guides and modified CBT.
The basic steps are:
There is nothing new in Show/Do/Cue. All these techniques are being used. The surprising event happens when they are used in conjunction and the strongest parts of lecture, demo, coaching, peer coaching and CBT . The result is students who very quickly gain an understanding of even complex programs, apply that knowledge and build on it to produce advanced work in a short time. In order to understand the effectiveness of Show/Do/Cue, it may be useful to examine the limitations of other methods of instruction.
The Problem
Current techniques are inadequate in providing both the context of a new program and teaching tools and skills. The problem seems to stem from 3 areas: What is taught (quantitative); Frame of reference; and Training techniques.
What is Taught
What, or how much is taught is essential to success. Software packages often are sold by feature set. Often many of the features are unnecessary to understand and use the program at an introductory level. While trainings often try to teach all the functionality of a software program, they need not. Indeed, they should not. Often, it is best to not show all of the tools and menu functions. By limited the scope of the initial training, students may focus on the essential. Intermediate and advanced skills can be more easily taught at a later date.
During development of training, time spent testing how little can be taught and still capture the essence of the program will be time well spent. This “Up and Running” approach to training is surprisingly effective, particularly for the task of introducing the metaphor of the software package.
Frame of Reference
Often, software training teaches skills first and foremost. Trainers often begin a training by showing what each of the tools and menu items do. The training then progresses to teaching how do several different skills. These skills are then combined into an activity.
Students understand the software and learn more quickly when this order is turned on its head by focusing on a project. While working on a simple project, students must learn skills in order to accomplish that project. Learning skills is directed toward a specific goal or task. The skills are given a context. This leads to a better and faster understanding and greater retention. Projects increase in complexity to reinforce basic skills and teach new skills. Developing training becomes the process of developing projects which require skills at different levels of knowledge.
Training Techniques
The training techniques currently in use are problematic. Each has strengths and weaknesses. None has proven to be very successful in this context. The usual suspects are lecture/demo, coaching, written tutorials, and CBT.
Lecture/Demo
This is the most common classroom teaching technique. A teacher builds while students build along with, or the teacher builds first and then the students build. One of the main advantages of this technique is the ease of implementation. Teachers are often overburdened. This technique requires knowledge of the software and a decision on the project to be built and little else in preparation time.
In addition, it feels like the right thing to do. If someone doesn’t understand the application of a program, let’s spend some time explaining the thing. Let’s show some examples of good work with the program.
This is not necessarily a bad thing, but it is a bad time. Without a frame of reference developed from students’ experiences with the software, these explanations make little sense to the student. There is no context in which to understand them. As the instructor shows excellent examples of the software at work, the class is getting more and more lost.
It is terrible to watch students’ eyes dull while vainly trying to clarify. While the instructor becomes more and more animated in delivery and more and more clear with information and explanations, the students slip further and further away.
Another problem with this method is pacing. Students learn at very different speeds and often have very different levels of experience. When the teacher begins building while students follow along, it rarely turns out well. One student gets confused, so the teacher stops to explain and demonstrate. The other students work ahead because they are impatient and uninterested in the other student’s problem. Suddenly, the teacher says something that is of importance, but the students working ahead have only heard the tail end. They either don’t get the information, or they make the teacher repeat. Often, the teacher while building has a problem and, trying to fix it, forgets the class, or, trying to fill in, explains what the problem is -- often far above the knowledge and understanding of the students.
In addition, some teachers get sidelined with “interesting” tidbits on what the program is doing or how to do shortcuts to activities the students haven’t learned yet. This does not serve to enlighten, it confuses. In this rather ungainly fashion, the class lurches forward until the teacher takes mercy and tells the class to finish the assignment from the workbook on their own.
Another significant problem with lecture/demo is retention. Students get exposure during class. They may have success completing a project or using a skill. However, by the time they try to use the material outside of class, they are unable to remember the procedure.
Written Tutorials
Written tutorials are cheap and widely available. They have several strengths instructionally. Many students want/need to see the steps written. They can’t understand without a clear, written guide. Written tutorials often aid in retention. When the student forgets, they can return to the page. Finally, written tutorials can help overcome the pacing problem. Students can be assigned an end point in the tutorial ( i.e. work through chapter 5) and take as much time as each needs to attain that goal.
However, for introducing software, written tutorials have inherent problems. Students approach software instruction with many different needs and levels of experience. They have different uses for the same software. They learn at many very different rates. To ensure the tutorial works for the beginners, printed tutorials often must err toward the pedantic. This leads to slightly more advanced students jumping ahead until they are lost, then trying to backtrack until they find themselves. It speeds the learning considerably to have a personal touch, to be able to decide the pacing of the information based on feedback from the class and to decide the skills to be taught based on the needs of the students. This kind of personalizing is not possible with printed tutorials, which must be aimed at the mass market in order to make them cost effective. Instructors can overcome this by developing their own written tutorials. This is very time consuming, but can often be a good alternative.
A larger problem is the tendency for written tutorials to get lost in discrete skills without providing a cognitive view of the process or the purpose. The sum of the parts does not necessary reveal the whole. The medium encourages authors to break down instruction this way. But, while this behaviorist approach can work to teach how to put a nut on a bolt, it rarely works with software. It particularly does not work for introductory software training because print does a poor job of presenting a cognitive picture of what a package can do and when and why to use it.
A final problem is that the translation of training from print to computer seems a particularly hard one for many students. Computer users don’t like to read printed instructions. It is said that the best place to hide something from a computer user is to put it in the manual. As a backup reminder or guide of instruction presented in another form, written tutorials work. For more advanced learning, printed references with short examples are a fine way to transmit knowledge. They can be effective ancillary material to aid in retention and reference for introductory teaching. However, for the introductory learning, book tutorials are not particularly effective by themselves.
Coaching
Coaching is wonderful if the student teacher ratio is low enough to use this technique. Rarely is this the case. With more than 2 or 3 students, many of the problems of lecture/demo come into play, in particular, pacing. The biggest trap with coaching is the very confused student. While trying to bring that one up to speed, the instructor tends to neglect the other students.
Coaching works best as an ancillary technique, giving students written guidelines either from the demo or from a written tutorial. Then, through coaching, the instructor can tailor the explanations to the needs of each student. If this precoaching is not clear and effective, coaching quickly becomes individual repeats of the demonstration. This is not a time effective way of providing instruction.
The final problem with coaching is retention. Students can work through exercises when the instructor is there to help. However, they have not had the opportunity to learn through mistakes. As soon as they get a little confused, the instructor is there to provide guidance. Once the student is away from class, too often, the skills are not in mind.
CBT
Computer Based Training can provide easy branching of lessons. The information provided can be tailored to the student based on their input. This is more effective than printed materials. Techniques can be demonstrated through animations or movies. So, CBT is more effective than print. However, it still suffers from many of the problems of written tutorials.
Even more than writing, CBTs tend toward dissecting skills into discrete bits, teaching techniques rather than overall process. Instead of the project approach, skills are taught discretely, then combined for a project. While CBT does not require a skill based instruction, the media does lend itself to a focus on skill drill. There are excellent CBTs. These do a good job of presenting the cognitive picture of the program and use a project focus to teach skills in context. Unfortunately, these seem to be the exception, rather than the rule.
The biggest drawback to using CBT is the time and money required to make a good project. The programs, hardware and people necessary to plan and build a good project do not come cheap. The job is not done quickly. In the world of software, where products are often revised every 12-18 months, it is prohibitively expensive to make and market projects for specialized students or programs with any but a very large product base. The focus must be on teaching the software in toto. Limited the skills taught, while an effective instructional technique, would not be feasible with a CBT. One could segment the CBT and exhort users to take several weeks between segments in order to develop their own understanding of the product. However, one questions the effectiveness of this approach.
Moreover, it takes CBT out of the realm of possibility of a single teacher teaching at a single school. For one person to build a CBT would be a huge undertaking. It is not a practical tool for most teachers who teach a two or more software programs that are revised every couple of years. The investment of time and money is so great to develop a CBT that there is a great resistance to changing or customizing the information.
Accessibility is also a problem. CBT is not as easily accessed as paper -- a computer is necessary at least, and often the program is only available in labs. In addition, the computer screen is a poor second to paper for accessing information. It is difficult to put large amounts of information on screen. CBT usually trims details in order to effectively present text. If not, the user, overwhelmed with too much sensory input, ignores some or all of the screen text.
An Answer
None of the techniques seems a good answer for introducing software in a classroom setting. However, by combining pieces of each, instructors have a very powerful approach.
The Show/Do/Cue technique uses an instructor demonstration of a simple project. Students watch, but do not build. After the demo, students build the project using a written step by step guide. The instructor provides coaching as needed. Students are encouraged to build in pairs in class. An on-screen step by step guide with screen captures to remind students of the stages of the project is taken home and the students are encouraged to build the project one more time one their own, using the written guides and the on screen tutorial as guides.
Show/Do/Cue works in many settings. It can be built by one teacher. It can be customized for different groups and based on experience and feedback. The instruction is remarkably effective even with classes which have a broad range of student experience. Retention of material by students is good. Using the knowledge acquired, students usually continue to explore the software and advance their knowledge rapidly and independently. The Technique
Show/Do/Cue is not only a technique to deliver instruction. It is a model for instructional design. Returning to the steps, they are:
As you can see, there is nothing new in Show/Do/Cue. All these techniques are being used. The surprising result is that when they are used in conjunction, the strongest parts of lecture, demo, coaching, peer coaching and CBT combine to produce students who very quickly gain an understanding of even complex programs, apply that knowledge and build on it to produce advanced work in a short time.
Specifics - How To Build a Show/Do/Cue
Preparation
The most important part of building a successful Show/Do/Cue instruction is selection of the skills necessary to understand the program. The greatest temptation is to include too much. In this situation, less is more. There is great benefit in testing in class situations, trying ever less information. It is often surprising what the essential skills of a program are, and what are not necessary to understand and use the program. Start with too much and chip away. The test is whether students have enough knowledge after the instruction to continue to learn own their own. If they can, there is at least enough information, but perhaps too much.
The second stage of preparation is developing a project which uses these skills. Some guidelines for the project include: It must be “chunkable” into 3 or four separate pieces. The training is presented one chunk at a time. The first chunk should be very fast and easy to construct. It is best when students can have success building something within the first half hour of a training. The chunks should build in complexity. Important skills should be used several times within the 3-4 chunks. Consider using humor in the project. When working so hard on learning a program, a bit of levity can help keep attention and boost the spirits of students.
After deciding on the project, it is necessary to construct the step by step guide to be used by the students as they build. It should be divided by chunks. Remember that they will use this after watching the instructor build each chunk. It is a reminder, not a tutorial. It needs to give very brief instructions for each step, but not teach. (Example: Group items. Select both. Control G or Group under Object menu.) This does not provide detail explanation, it is a reminder of what the student has seen a few minutes before.
In addition, the instructor must build a computer based step by step guide. This is not as detailed as a CBT. It contains the steps from the step by step guide. In addition, it has screen captures of each step. A button next to each step will open the appropriate picture. The screen captures can be easily made with one of many screen capture utilities. (Screen Thief, CameraMan and others.) The tutorial can be built with a simple authoring program. (HyperStudio on Mac or PC, SuperCard on Mac, Astound on both platforms, Toolbook on PC). Keep the construction simple. This will save time in preparation. The tutorial is to aid memory, not teach. The students have already seen you build the project and have built it in class. This is only to aid retention when they return to the project a few days later. It should fit on a disk, contain any media (pictures, sounds, etc.) necessary to complete the project and be self running so students can use it at any computer.
With a project designed which uses the necessary skills, a step by step printed guide written, and a step by step tutorial built, the instructor is ready to present the training.
Introduction
When the class meets, the program is introduced very briefly. The metaphor or use of the program is demonstrated. Examples, if used now, must be very very brief. The examples will mean more to the students when they have worked with the program a bit. Until then, they have no idea what is easy or hard within the program. The goal is only to illustrate and categorize the program's utility.
In addition, give a very brief description of the Show/Do/Cue technique, so students will know what to expect.
Resist the temptation to explain the main window of the program and explain each of the tools, or, worse, all the menu items. This will take a long time and serve no useful purpose. It will, however, confuse the students. Until they need to use a tool to work on a project, the name and use of a tool is unnecessary and confusing information. The goal is to get the students hands on to the program within 15 minutes and for the students to have successfully completed the first chunk within 45 minutes maximum.
Example: To provide a clearer picture of the technique, a series of sidebars will illustrate a show/do/cue tutorial developed for Astound, a presentation program which uses a slide show metaphor and features effects, interactivity and timelines.
Show -- Part 1 -- The Completed Project
Show the completed project to the class. This provides a cognitive model the end result. Suspense is fine in movies, but not in instruction. Do not offer much in the way of explanation. Point out special features of each slide in passing, but keep the pace fast.
Example:
The Astound project has three slides which detail the dangers of
Attack Chickens.. A Fowl Menace. The first slide introduces the main
metaphor, text and transitions. The second slide shows importing a
photo and introduces the important timeline techniques. The third
slide introduces interactivity and uses sound.
4. Show -- Part 2 -- Building chunk 1
Build the first activity chunk only (lecture/demo). Do it quickly, describing each step as you go. Encourage the class NOT to take notes. Remind the class that the goal here is to get a feeling for the process, not to test their memory. Remind the class that they will have a written list of steps when they build. Building the first chunk should only take 5 minutes. If it takes more, you will lose the students. Keep this first chunk as small as possible.
If there are questions about other features during this “show” phase, do not answer them. Keep students on task during this phase of the lesson. Once they have had success and have completed the tasks, they will be free to explore. However, if they go exploring before, they invariably miss some essential skills. Students are impatient, but by keeping each of the 3 clusters short and keeping the focus on the skills at hand, students will work through them all.
Note: Use either an LCD panel or a TV connected to the instructor station when possible. Encourage (require) students to turn off their computers. Attention must be focused on the brief demonstration of building. Remind students throughout to think about the process, not each specific step. Remember, this first step must be short or students will lose track and lose confidence.
5. Do
Immediately after seeing the process, the students must do - they must build the first chunk. Working in pairs using a printed step by step guide, students build the first chunk while the instructor provides coaching as needed. Working in pairs is preferred so students can help each other remember the process. This makes better use of instructor time as many questions can be answered by a partner. When the instructor sees that a particular task is causing a problem for many students, repeating that part of the demo for the entire class will speed success.
Notice that the students get their hands on the program very quickly. They are directed in their exploration. They can relatively quickly and easily have success. As noted above, keep students on task until completing the chunk. After initial success, they can, and should, explore possibilities. This will give the students who finish first something to do.
6. Show -- Part Three -- chunk two building
When all students have completed the first cluster, proceed with building cluster two. This can be done either after a break or at another class meeting. (See note on timing below.) Whenever it is done, proceed as before, focusing on the process of building each chunk, then having students working in pairs build it. Each chunk can be increasingly complex, but keep the building time limited to about 10 minutes. If one of the chunks is too big, divide it into two halves with a break in between. It is better to teach more small pieces than to have a piece which takes longer than 10 minutes to build. Longer sections of building lead to students losing track of the work, and so compromises the effectiveness of the process.
Example:
The second slide in the Astound presentation brought in text, made a
master, imported a picture and added a frame. Then it dealt with the
difficult technique of timelines. When presenting this as one chunk,
students became confused, necessitating frequent repeat
demonstrations and much more coaching. By breaking the second slide
into two sections, students were able to finish the slide more
quickly and with better understanding.
It is important to take a break after the second chunk. Learning new software is very difficult. In order to keep the students from being overwhelmed, it is important to schedule frequent breaks. After a significant time, such as after the second chunk, a long break (lunch or if the class is weekly, a break until the following week) will give the students a chance to let the dust settle and put the information into perspective. Plowing through all three chunks will not give the students the time reference needed. They may remember a piece of a skill, but not be able to put it to its proper task.
7. Cue
The final step in the show/do/cue process is to give the students a tutorial which includes the step by step guide and shows each step in the process. This can be after the first class session, if the training is presented over two or more weeks, or it can be at the end of the day for all day sessions. It is optimal to have a training session, a break of some days and then another training session. This gives students a chance to forget, explore and develop new questions.
When given the tutorial, students are directed to go home and repeat the exercise of building the activity chunk by themselves. This step (having the reminder tutorial and repeating the task after a delay) has made an enormous difference in student success. Everyone has had the experience of sitting down to a procedure that was very clear in a class a few days before and being struck with the "Duh Syndrome." -- remembering basically what needs to be done, but forgetting the steps to accomplish the goal. With the tutorial as a reminder, this task reinforces the skills, the overall understanding, aids retention and gives students the confidence to continue to learn on their own. It is a common experience when the instruction is broken into two separate days to find the students working ahead to complete the third slide on their own, and exploring other functionalities. Students can also use this tutorial as a review whenever they return to using the program.
After the Break
Whether the long break after chunk two is an hour or a week, it is important to remind students of the overview. Show the completed project again. Then build the third chunk. Remind students to watch, not build along with. Remind them that they are trying to get an overview, a feeling of the process. Then coach them as they build the third chunk. Follow with the fourth chunk if there is one.
Considerations/Tips
Summary
The combination of techniques and the reliance on a project approach makes Show/Do/Cue effective. Upon further application with other software programs, it’s results are often surprising in their effectiveness. Most study of this technique has been in small to mid sized classes (15 maximum). Using this basic approach, other presentations have been developed for other software. The result remains constantly positive. The latest trails have included mini lessons with only one or two chunks with no disk tutorial, but with a printed step by step and a disk with media and the finished product. This has worked very well.
Future study is warranted in different applications of the show/do/cue technique. Of particular interest is the efficacy of this technique in other types of training. Does it work equally well in other than introductory software training.