Monthly Archives: October 2010

How to become a big e-learning nerd by mistake

Inherit a class. Inherit a class containing a really, really, really dully, repetitive, and entirely necessary component. One that the students must repeat ad nauseam, because rote-learning is the only thing that’s going to make a difference. Anything involving students learning how to drive a piece of software will be perfect.

Teach that class for a decade. Teach it until you can’t stand the rote and repetition any more, and until you find yourself atop a soapbox — metaphorical or actual — proclaiming to anyone who will listen that it is madness to spend valuable face-time with students demonstrating tasks that a poorly-trained monkey could teach.

Serve out another year of repetition, swearing to yourself that This Will Be The Last Time, Damn It. (NB: this works particularly well if the class is one you must teach several times per year, to accommodate the small computer room and the very large number of students.)

Choose a suitable moment during the summer months to crack. Demand — nicely — face-time with the people who run the course*. Explain to them that developments in e-learning are now such that this repetitive task that is driving you crazy and that you cannot stand to teach for one more year without serious risk of going postal can now be experienced by students not for one brief, rushed, 60-minute session, but in their own time and as many times as they like. This will, of course, free up your class times to do something considerably more interactive, like having enough time to answer students’ questions, or discussing ideas as well as specifics.

Watch your colleagues savour the idea. You can tell the moment when they buy into it: it’s about three seconds before they want to know how you are going to achieve this thing.

Gird your loins to achieve this thing. You’re going to need software. And you’re going to need to know how to use it. And then you’re going to need time in which to make things. Software is just about money, and learning how to use it is largely about tenacity. Time, though, you’ll need to create for yourself; nobody is going to pay you to take an extended e-learning sabbatical. And you can forget about manpower: if you want this thing doing, you’re going to have to do it yourself.

Get recommendations. Rope in your network of contacts. Find out from eavesdropping on Twitter that there is something called Adobe Captivate and something else called Camtasia. Pay particular attention when people start enthusing about Camtasia, because in a moment it will turn out that your institution only has a licence for Captivate.

Cultivate your Learning Development people. Our LDU contains some of the nicest and most helpful people you could ever hope to meet. They are super-smart, and they are way nerdy — and nerdy is what you are going to need. In spades. Ideally, your learning development guys will have time to get to know the software a bit, so they can talk you through your early, clumsy steps, and feed you jaffa cakes and cups of tea when you are having a meltdown (thank you, Liz). For full bonus points, they should have managers who are wildly enthusiastic about e-learning and believe that it’s worth the significant investment of time taken to learn a new thing so they can support you effectively while you learn it (thank you, Jim).

I mean, failing that, there are a gazillion text and video tutorials out there, not to mention some enormously helpful people on Twitter. But the learning development guys rule, man; I can’t see person-to-person learning interaction going out of style anytime soon.

Recognise that you are on a learning curve. First of all, it is vital that your software does not always remind you to save individual files before closing the program. It is especially helpful if you can demonstrate this three times inside a week, so that you end up losing the equivalent of about two days’ work: this will provide you with a learning experience that is pretty much optimised.

Swear. Vigorously.

Become a virtuoso of the panic-save, performing Ctrl+S reflexively in your sleep, every three minutes.

Attend a workshop on Adobe Captivate. Devour as many hints and tips as you can, like the fact that it’s possible to record your demo and training simulations simultaneously. Have the blinding realisation that creating good Captivate demonstrations requires exactly the same skills as creating meaningful, transformative PowerPoint animations.

Hate yourself a little bit for thinking PowerPoint when you should have thought slideware.

Embrace everything you know about the psychology of watching things happen on a screen. (Hey, wouldn’t it be cool if there was a word for that? Like televisionomics.) Go to town on the Gestalt laws:

* objects that appear simultaneously will appear to be related
* objects that are the same colour or shape will appear to be related
* objects that are close together will appear to be related
… etc.

Remember to consider the brain’s many idiosyncrasies when processing the flow of visual information:

* inattentional blindness [YouTube] — we may not spot things that are peripheral or that we think are irrelevant;
* change blindness [flash video] – we may not notice changes that occur concurrently with a visual discontinuity such as a slide-change or other interruption;
* gradual change blindness [PDF] slow changes over several seconds may prevent us noticing them altogether. (By the way, the intro to this paper provides a nice overview of the change blindness literature.)

Keep in mind at all times that the brain is really only capable of holding onto about four new things at once.

Wildly, wildly underestimate how much time it will take to create your new project. Plan to create five software demonstrations and five matching software training simulations. Since recording the demonstration takes just a few minutes, annotating it and creating the training simulation will surely only take two or three times as long … right?


Correcting the callouts and highlight boxes and animation timings so they don’t look like they were put together by committee is complicated. Also, writing really clear, unambiguous copy takes time. Start putting in the kind of hours that you can’t blog about for fear of reprimand.

Gameify it. Gameification is a big buzzword at the moment, as people try to budge learning from functional to fun. And god knows you are shovelling some pretty dry material down students’ throats with this software simulation. So lighten the mood a bit: use terminology like “your mission”, and reward correctly-answered questions with slides that say things like “You win a cake!” Include hand-drawn pictures.

Wonder how many students are going to email you to ask when they can collect their cake.

Then start worrying whether students will find the fun and the pictures patronising.

Attempt usability testing. Because of time constraints, this will be pretty crude, basically involving a colleague clicking through your simulation while you lurk behind them making notes about everything that causes them to tut. Helpful feedback will include things like giving people a button to click to move them onto the next screen so they don’t have to wait, and making users aware of the ‘view in fast-forward’ mode.

Recognise that, like any process of product development, this is a cycle. Try to be okay with the fact that each time you look at your work, you will find things wrong with it. Try to remember that it is okay to produce a first draft that is good enough; there will be time for refinements later.

Start fantasising about mass usability testing involving all the students in the class. Wonder about rigging up cameras in the computer labs; get cold feet when you start to consider the privacy, consent, and data protection issues.

Resolve to ask around for help with some kind of smaller-scale usability testing anyway.

Angst about making it accessible as well as usable. Enable the accessibility options. (Hat-tip to Karen Mardahl for making a potentially daunting issue seem straightforward and achievable.) Start wrestling with technical issues like whether uploading the interactive PDF is really okay if students can only access it from on-campus because remote access doesn’t support Adobe Reader 9. Have qualms about flash in general. Briefly consider enabling the iPhone option; get distracted by the question of how many students actually have iPhones.

Breathe out.

Start brewing this blog-post while you brush your teeth before bed, then accidentally stay up until 3am writing about it.

Realise that this project has eaten your life, worn out your body, and driven you into the hairy, caffeinated arms of Diet Coke. Realise, too, that you have acquired a whole new set of skills, and that this opens the door for colleagues who may have been considering similar learning solutions, but who may not have known where to start. Resolve to run a demonstration session soon, and to buy the guys in the LDU some nice cookies.

Then cross your fingers, Ctrl+S again for good measure, and unleash your work on the students.

*Note for North American faculty: it is not unusual in UK universities to teach piecemeal sessions on someone else’s course or module, rather than designing, teaching, and managing a course or module entirely on your own (in fact, many UK faculty will do some of each).


Filed under Uncategorized