EdTech – What to do when it goes wrong (and it will go wrong!)
Terry Freedman suggests some strategies to deal with technical glitches in your classroom – and ideas to help you avoid them in the first place…
You have great technology, and you’re a very competent teacher. Unfortunately, that wonderful combination is no guarantee against disaster. Sooner or later, things will go wrong with edtech – but your lessons don’t have to be ruined because of it.
First of all, adopt the motto “It’s not if something goes wrong, it’s when”.
Always have a Plan B, an activity that does not require a computer.
In fact, have two Plan Bs: one an entire lesson in case the whole system goes down, and the other a standalone activity that can be given to a student who can’t access the technology in that session.
Before the lesson, if you have booked a resource, such as a bank of laptops, check in advance that they have been, or will be, charged up in time. If a student ends up with an uncharged device, pair them up with someone else, or set them the standalone activity.
Match up
Unlike science teachers, computing specialists tend not to enjoy the benefits of a lab technician, so giving out and collecting in laptops, tablets, digital cameras or whatever has to be extremely well organised.
The best way is to allocate each device to a specific student. If the devices are labelled with a number or code, enter that data next to each learner’s name.
As this can be time-consuming and detract from the lesson, allocate the devices in advance and ask a couple of trustworthy students to give them out and collect them in.
Protect passwords
At some point a student is going to forget their password. To minimise the disruption this would cause, ask the head of IT or technical support to set up a number of guest passwords for each Year and/or subject group.
Depending on the way the system is set up, logging in as a guest should give the student access to all the relevant software. As they won’t be able to continue with their previous work, however, this is where the second Plan B comes in.
Minimise data input
A computing class I observed some years ago was devoted entirely to the students entering (or trying to enter) lines of code, and mostly getting it wrong.
When I asked the teacher why he hadn’t simply supplied a completed program so that they could get on with the main activity, he said that entering the data helped to improve their typing skills.
That may or may not be a worthy aim, but typing skills are not in the National Curriculum, and weren’t on his learning objectives.
Given that entering any data, be it lines of code, URLs or numbers in a spreadsheet, can destroy a lesson, minimise the need for doing so.
For example, the length of URLs can be shortened and customised using Bitly, and data in spreadsheets could be entered through drop-down lists.
Beware mischief
Sometimes students do things for a laugh. For example, in one of my lessons we discovered that someone had switched the mice cables of two computers, so that each time the mouse on one was moved, the mouse pointer on the other screen responded.
If you can’t fix it there and then without spending more than a minute or two, either resort to the stand-alone activity or ask if there’s a tech-savvy student in the group who could sort it.
Ultimately, of course, when it comes to technology all sorts of things can go wrong: printer paper jams, loss of internet access, you name it.
Before calling technical support, consider whether the waiting and disruption are worth it.
If there’s a digital champions scheme, a student in your lesson should be able to sort out something simple like refilling the printer paper tray. If not, or for anything more complicated, you know the answer: Plan B!
Terry Freedman is an independent ed tech consultant and freelance writer. He publishes the ICT & Computing in Education website and Digital Education newsletter at ictineducation.org.
