μεταcole

When teaching software, although the approach you take is paramount, how you deliver the lesson can also significantly affect how easily your lesson is followed, and whether the learner can actually use the software by the end of the lesson.

This post assumes a particular setting – the one I’m most used to (both as the teacher and as the learner) – the teacher in front with a computer and projector, and around 15-30 learners with their own computers.

In such a setting, the learner have at least 3 things to look at and focus on – the teacher, the projection screen, and their own screen. They may also be looking at the handouts, or taking notes.

In other words, the learner isn’t always looking at your screen (the projection screen) even if you want them to, or even if you ask them to. They may be trying to copy what you’re doing – click the same buttons, press the same keys, etc. Inevitably, they would miss something on the screen that you’re trying to show.

Which brings me to my first tip…

1. Slow down or pause your mouse

You may be pretty efficient and accurate with the mouse thanks to your great hand-eye coordination. However, the learner would quickly lose track of the tiny mouse pointer if they’re not completely focused on your screen.

Even if they are focused, it’s still hard to follow if the pointer is skipping to different parts of the screen very quickly.

Added to that, because the learner is new to the software, they have no idea where you’re going to move the mouse next. This uncertainty can become stressful, but can be greatly reduced if your mouse pointer slows down, and the learner is easily able to follow the mouse pointer.

An alternative method I prefer (because I find it hard to slow my mouse pointer) is to pause right after I move the mouse.

So instead of moving the mouse to, say, a button and clicking on the button in one swift motion, I would move the mouse to the button and pause or leave it there first, so that the learner has time to relocate my mouse pointer. Then I continue on.

(An exception to this tip is when the learners are already familiar with the step you’re doing. For example, if they’ve already saved the file many times, there’s no need to do the File > save sequence slowly. Just tell them to save the file.)

2. Verbalize positions of controls (buttons, menu items, etc.)

Sometimes, no matter how slowly you move your mouse, the learner just isn’t looking at your screen.

For example, if you’re teaching Powerpoint and you show them the ‘Slide Sorter View’ button and ask them to click it, if they don’t happen to be looking, they wouldn’t know where it is.

It would help a lot more if you say “click on the ‘Slide Sorter View’ button which is right at the bottom left.”

In fact, I would say this instead: “click on the ‘Slide Sorter View’ button which is over here at the bottom left.”

It’s a slight but important difference.

I’ve found from experience that when I say things like “over here”, they know it’s time to look at my screen. It’s just a subtle way of saying “look over here – what I’m showing now is useful!”

And as mentioned in the previous tip, I would also leave my mouse pointer there on the button to give the slower ones more time to locate it.

If it’s within reach, I would even walk to the projection screen and physically point it out. There’s no way they’d lose you like this.

3. Verbalize mouse and keyboard actions

Besides verbalizing where things are, you also want to verbalize what you’re doing.

The learner isn’t just uncertain about where you’re going to move the mouse next, the learner is also uncertain about when you click the mouse button (and which button) or hit a key (or a combination of keys).

One might think that this seems obvious or trivial, but I’ve been through countless software classes where the learners struggle to keep up simply because the teacher didn’t verbalize an important mouse click.

A context menu appearing out of nowhere is particularly mystifying especially for non-expert learners. Even for expert computer user learners, it still takes a bit of thought before they realize that you’ve clicked the right mouse button.

And all this while they’re trying to remember the steps that you’ve just taken, and understand what’s going on.

Thus, make it a habit to verbalize all your mouse clicks and right-clicks and keystrokes.

4. Repeat the more-difficult procedures

The learners won’t always be able to get the steps right the first time, so it’s often a good idea to repeat them.

There’s usually no need to repeat simple one-click steps since those are easy to follow, but which procedures should be repeated depends on the type of learner you’re dealing with.

I’m most used to the non-expert learner, so any procedure that requires 2 steps or more, I repeat.

And if the process is particularly complicated, I would say something like this:

“I’m gonna show you how to do this first. I’ll do it pretty quickly to give you a feel of how it’s done – don’t try to do it yet. After I’ve finished, I’ll go through it again slowly so that you can follow.”

A few things to note from there:

• I assure them that they’ll get an opportunity to follow my steps later
• I show them the steps quickly as an overview
• I show them the steps slowly, both to reinforce, as well as to make it easy to follow

5. Cut down unnecessary mouse movements

A software teacher of mine had this very annoying habit of jerking the mouse around as he spoke. This meant that the mouse pointer would be flying all over the screen as he spoke.

Unnecessary mouse movements is bad enough in any lesson where a computer is used, but it’s far worse in a software lesson.

During the software lesson, the learner subconsciously realizes that it’s important to pay attention to follow where the mouse pointer is moving, so that the correct procedure can followed.

So if the teacher is making unnecessary mouse movements, the learners are also expending unnecessary effort trying to keep track of those movements.

The next time you’re attending a software lesson and you find the teacher moving the mouse unnecessarily, see if you catch yourself trying to keep track of the pointer. You’ll find it even more annoying when you find it hard to stop yourself from tracking the pointer. Then look around the room – you’ll notice most people’s eyes following the mouse pointer as well.

It’s a sad but funny sight.

Conclusion

These tips are simple and small, but they can make quite a lot of difference in your delivery once you manage to turn them into a habit.

Your learners probably won’t notice the changes you’ve made, since most of these are quite subtle. They’d just find that your software lessons have strangely become much easier to follow.

Most of us who have attended software classes or workshops would know that just because you’re an expert with a software application doesn’t mean you’re good at teaching it.

This applies to most other subjects as well – a history expert or a literature expert doesn’t make them good history or literature teachers.

Except that the situation may be worse for software experts.

The geek species is not known for empathy, and empathy is important for good teaching. (Empathy is also important in creating user-friendly software, which is why most software aren’t user-friendly – but that’s another story.)

Because most software teachers are geeks to some extent, it is no surprise then, that most software classes and workshops are not well-taught.
This situation isn’t going to change overnight, but I hope the tips in this post would contribute to that change.

The tips in this post deal with the strategy or approach of the lesson. I hope to do another post on some tips on the delivery of software classes.

Without further ado, here are the tips:

Help learners answer “why should I bother with this?”

I wouldn’t dare teach any software application (or anything else for that matter) if I can’t help the learner answer the question, “why should I bother with this?”

This is about making the learning relevant. And if it’s relevant, the learner will be more motivated to learn whatever that’s being taught.
If the learner cannot figure out why they should be learning the application or the feature, then you’re likely to lose them very quickly.

If you’re lucky, the learner already knows why, or eventually figures it out on their own, so it doesn’t hurt so much if you miss out this point. If you’re teaching Powerpoint for example, the learner probably already knows that it can help them with their presentations.

But if you’re teaching Excel as part of a Microsoft Office competence program for retirees, you’ll probably have a lot more trouble.

If your idea of making things relevant is to tell them that Excel is “a spreadsheet and it’s important to know how to use spreadsheets”, good luck – you’ll need lots of it.

But if you tell them that Excel is “a program that can help you keep track of your money, including how much you have in your different accounts, how much you’re getting from your pension and investments, and if you’re getting richer or poorer over the years”, they would have a clearer picture of what they’re getting into, and they’d be a lot more motivated too.

That initial reason you’re giving them doesn’t have to give the complete picture. Like in the above example, we know that Excel can do much more than keeping track of money. But as far as learning is concerned, especially with beginners, it’s much better to start with something incomplete but easily within grasp.

Here’s another example. When I teach Photoshop to beginners, I’ll give a brief introduction:

Photoshop, as it’s name suggests, is a program used to edit photos. This means that after you take a photo, you could improve on it, like make it brighter if it’s too dark, or make it darker if it’s too bright. In fact, as you go along, you’ll find that you can do a lot more in Photoshop – you could change the color of a flower, you could make your complexion clearer. But let’s start with the basics first…

I wouldn’t mention that Photoshop can be used for drawing, for painting, for design, until many lessons later, when they are already familiar with editing photos in Photoshop:

Remember in the first lesson when I said that Photoshop is used to edit photos? I must confess that it’s not the whole truth – Photoshop can be used for design too…

Don’t teach feature by feature – paint scenarios

Teaching feature by feature is probably the most common and glaring mistake in teaching software, especially when the learners are beginners. If the class is boring, it’s probably because of this mistake.

This is when the teacher teaches the application by going down the list of features, teaching one feature after another. Some may go down each menu item, or each toolbar button.

This approach is convenient if you want to cover every feature in the application.

But the problem with this approach is that it doesn’t match the mental model of the learner. When the learner uses the application in future, it’s because they have a problem to solve. They have to go through a thinking process that maps the solution with the features that will help them solve the problem.

If they were taught feature by feature, it would take considerable effort and intelligence to pick out the features relevant to solving that problem. It doesn’t occur to them easily that those features (that they’re supposed to have been taught) can actually be used to solve that problem.

So when you do point out to them how those features could be used in concert to solve the problem, they might exclaim, “why didn’t I think of that?”

Perhaps they didn’t think of that because it’s the teacher’s fault.

It would be a lot more useful, interesting, and relevant if you painted scenarios or problems before introducing the application or feature.

So, when teaching Microsoft Word, the typical geek approach when introducing the page break feature is to just introduce it:

To insert a page break, go to Insert > Break > Page Break. See the page break? Good. Try it out, then we’ll go on to the next feature.

Snore. Most learners would just go through the motions, and they would miss the significance of the feature.

It would be far better to introduce a scenario first:

While Word automatically adds new pages for you, as you might have noticed already, there may times when you want to continue on new page, even before you reach the end of the current page.

For example, you may have reached the end of a major section in your report, and you want to start the next section on a fresh page.

To do that, you have to insert a page break. Go to Insert > Break > Page Break.

It takes a little longer, but it will definitely stick a lot better. Even if the learner doesn’t remember exactly how to activate that feature, they’re likely to at least remember that such a feature exist.

Even better, if you have the time, you could make things more interactive and to stimulate more thinking, by asking the learners to come up with their own scenario:

To insert a page break, go to Insert > Break > Page Break. Try this out, then give me an example of a situation when you’d use this feature.

But what if you want to teach a feature, but you can’t think of a scenario that relates to the learners?

Don’t teach every single feature – only the useful ones

It’s tempting to cover as many features as possible, and there’s often some pressure to do so.

I’ve taught some classes where the learners pay for the workshops out of their own pockets, so they want to get the most out of what they’re paying for.

In such cases, I’d tell them at the outset that I won’t be teaching every single feature. After a brief pause to let them regain their composure, I tell them “if you want to know about every feature, you can read the help file. And, there’s not enough time to cover everything anyway”.

Instead, I promise them that what they’ll learn would be useful to them. “We’ll start with the basics, and I’ll make sure you understand the important concepts really well, so that you’ll have a good foundation to build on. Then we’ll move on to the more advanced stuff if we have the time. If not, the foundation you have will help you understand the help file.”

So which features to cover? You should focus on the features that will be most useful to the learner. So if the learners are beginners, start with the basic ones. And if you follow the previous tip and use scenarios, you’ll already have some idea as to which features to cover and which to drop. If the learners are newbies, start with the most basic and common scenarios – these would cover the most useful features.

If you have more time, then go on to other scenarios, from the most common to less common scenarios.

If time doesn’t permit me to cover some other less-common-but-possibly-useful features in detail, I normally spend a short time just “flagging” some of these features.

For example, if I’m teaching Photoshop, I might have taught them the sharpen and blur “filters” (features used to sharpen or blur photos). Photoshop has many other “filters”, but I wouldn’t cover them. Instead, I’d tell the learners,

You’re already familiar with the sharpen and blur filters. If you look at the Filter menu in Photoshop, you’ll see a whole bunch of other filters – each of them will give a different effect to the photo. I won’t cover them, but do go and try each of them out in your own time and play with them to see their effects.

Then I move on to the next scenario.

Conclusion

If you’re already an expert with a software application, teaching it well isn’t a difficult thing once your approach is right.

Take a bit of time to look at your approach, and keep putting yourself in the shoes of the learners (yes try to empathize with them), and you’ll be well on your way to becoming a pretty good software teacher!