One job of a learning technologist is making sure that teachers have easy access to “how-to” resources. These resources mean people can fix problems themselves, saving them from having to call on someone else for support.
Most of the time, resources already exist that can provide the self-help that people want. In those cases, we just need to track down where these resources are, quality check them, and then make sure they’re easy to find. But sometimes there’s a more specific need, and that’s when you might want to create some new resources yourself. Before you can do this, you need to make sure that you understand the process you’re trying to explain. Then you need to break that process into a series of steps.
It’s really a teaching problem.
At this stage, there are a few choices you have to make. The two I’m going to discuss here are:
(1) What type of media are you going to use to explain the process?
(2) How are you going to deal with non-linear aspects of the process?
Media: text/pictures vs. screencasts
If you want to show how to accomplish a task with a piece of software, you might go for a series of written steps, beautifully illustrated with screenshots and large yellow arrows. Alternatively, you might go for a video of a cursor moving round a screen while you talk over the top of it (a screencast).
Text and pictures are good if your reader wants to skim-read the steps before they start following them. Maybe you’re explaining steps 1-10, and your reader only needs steps 6-10. If it’s text and pictures, skimming past 1-5 (“done that, done that”) is nice and easy for them. In contrast, screencasts typically don’t let people see what’s coming up in much detail. Sometimes you get a message at the start of a screencast saying “In this tutorial, I’m going to cover X, Y and Z”. Even so, I frequently watch twenty seconds of a screencast before I get a vague feeling that it’s not what I needed. Twenty whole seconds! Can you imagine it.
Secondly, skim-reading gives your reader an overall picture of what the process is going to be like. Is it easy? Complex?
Finally, skim-reading also lets your reader quality check the instructions themselves. There’s a wide variety of how-to guides available online, and your reader may come to your instructions looking for clues that they’re going to be easy to follow and reliable.
This is not to say screencasts don’t have their place. The thing screencasts do better than text is that they show and tell, rather than just tell. It’s difficult to follow a written instruction like, “Click the gear icon in the top-right corner of the grey box on the left of the screen”; but it’s a piece of cake to copy a video of a cursor clicking that icon. Using screenshot images with your written instructions does reduce this problem, but computer interfaces sometimes react in ways that are hard to illustrate in static images. For example, what if that gear icon only appears when you hover the cursor over the top-right of the grey box? This is hard to illustrate unless the illustration moves. What if a bunch of warnings pop up on the screen which you have to ignore? It can be tedious explaining this in text.
Screencasts more accurately represent our interactions with computers: these interactions partly take place through language, but also through visual cues such as symbols, colour, movement, and position.
Using audio in screencasts
You can record yourself talking over a screencast. If you do this, there are a few things to bear in mind:
(1) Keep what you say as concise as possible. Script it and trim it. Almost all of your audience are watching the screencast to help them get something done, and they aren’t looking for entertainment. Remember that 10 seconds of video time = 1 minute of time in real life. Kind of like dog years. Are dogs like videos? I’m wasting your time. It’s annoying, isn’t it. Now imagine you were listening to me say this over a video of a motionless mouse pointer on a Windows desktop when all you want to do is find out how to use the Pen Tool in Adobe Illustrator.
(2) Is everyone watching the screencast going to have speakers / headphones? Some screencasts can work quite well if you cut the audio and just have instructions written on the screen, Buster Keaton style.
(3) One more reason not to use audio: You’re almost certainly going to have to tweak the screencast, and audio is harder to tweak than text.
Sometimes audio is good. If it’s good, use it – these points are just things to think about.
If you search for directions on Google Maps, it’s possible to get a print-out of the route as a series of written instructions, like this:
These directions above are an example of a linear process. Start at the beginning, follow the instructions, and reach your destination. If you’ve ever tried to follow a route using instructions like these, you’ll know they’re a guaranteed recipe for frustration. For a route involving even the slightest complexity, they don’t work unless you’re using a map as well. Why is that?
- You’ll probably take a wrong turn at some point, and there are no instructions for how to get back on the route.
- One of the roads might be closed, and there are no instructions for a detour.
- If a signpost is hard to read, you’re going to miss your turn.
This is a useful example for our purposes: all three of the problems listed above can happen when someone’s using an unfamiliar piece of software.
- The tiniest breakdown in communication can mean your reader takes a wrong turn.
- Your reader might hit a Road Closed sign in the form of “Computer says no”.
- Sometimes a button that you think is obvious is actually easily missed by your reader.
Using maps to deal with non-linear processes
Now, the linear directions provided in your print-out from Google are markedly improved by the addition of one thing: a map. In fact, if we look at our three bullet-point problems with the directions, we notice that all of them are solved by someone sitting in the passenger seat with a decent map . Let’s look at how a map might work alongside our step-by-step instructions for software.
The standard “map” for using a piece of technology is a flowchart. The analogy’s not perfect, but it’ll do for now:
This is excellent for a simple process. However, when the process becomes more complex, I’m not convinced that they’re the best way of guiding someone. Take a look at this one: (click to embiggen)
Maybe it’s just me, but I find it hard to read large flowcharts like this the way you’re supposed to. Instead of following a line and answering questions on the way to a destination, my eye disobediently skims over the whole thing. Instead of clarifying the process of choosing a typeface, this flowchart just makes me feel overwhelmed by all the choices that are available. This is obviously a tongue-in-cheek example of a flowchart, but all I want to prove is that complex flowcharts take more effort to read than, say, a list of steps. They require a certain level of goodwill on the part of the reader – not something you can rely on when you’re explaining how to use software.
That said, we could take the same information from a flowchart and present it in small chunks. Reducing the cognitive load like this would make the process a whole lot easier for our reader to follow. Funnily enough, someone called Ian Li did that for the Typeface poster here. For another example, look at how Sky help their users troubleshoot a problem with their broadband connection:
Then we see a different screen depending on which of those four options we choose at step 2. It’s kind of like an exceptionally dull “Choose your own adventure” book. But interesting for me, because the screen above is really just showing a small chunk of a flowchart. I have to say I’m a fan of how they walk you through the troubleshooting process, though when I used it the end result was “Call our tech support team”. Oh well.
My one reservation about this whole approach is that it treats intelligent people like the stupid machines they want to operate. There’s no assumption that our reader is building a set of concepts which they will use to understand how the machine works. They’re just being told what to do, and are expected to follow these instructions almost thoughtlessly.
This seems like a real waste. I’ve never officially taught maths, but I’m sure there are cases where it’s better to get your students to build up a conceptual understanding of what they’re doing, rather than just teach them a series of steps which they have to follow to achieve objective X.
Maybe learning technologists should explain how to use software with more of a nod towards conceptual understanding. So rather than saying “Don’t cut text from Word and paste it into an HTML editor”, explain why this is a bad idea. It doesn’t need to be complicated, and the people you’re helping might find that the concepts come in useful the next time they face a related technology problem.
Here’s a screencast I made at work today:
And here’s a screencast which taught me how to use the Pen Tool in Adobe Illustrator. It’s great – I think she explains how it works really well.