Designing and developing for interactive whiteboards

I’m writing this partly as a note to myself, but also in the hope it’ll help others too.

We’ve recently been developing a few games and activities for interactive whiteboards, and found that they have a few kinks that it can be hard to keep track of during the design and dev process. So I thought I’d try and put down everything we’ve learned in one place.

Avoid putting critical controls in the top third of the screen. The majority of your audience is kids – kids who are still growing, and often aren’t tall enough to reach up to the top of a whiteboard. It’s also important for accessibility for people in wheelchairs who might not be able to reach as high as others. Schools install their whiteboards at different heights too, so keep any essential controls low on the screen if you want them to be accessible.

Controls that are used by the teacher, like mute, are fine to go nearer the top as the kids don’t need to be able to reach them – in fact, some controls are probably best kept out of the reach of meddling kids anyway to avoid accidental quitting or restarting.

Lots more whiteboard development tips after the jump…

Keep text over a certain size if you want it to be read by a class. There are loads of different modes of use to consider when you’re designing for education: solo use at a computer, groups round a laptop, child using a whiteboard, teacher teaching from a whiteboard…

Important text needs to be large enough so it can be read by children in a classroom. What needs to be legible depends on the content and the lesson, so it’s difficult to lay down hard and fast rules, but you should be able to identify key information.

Conversely (depending on your users) too much over-large text can make content for older children feel too kiddy, which will turn them off it quicker than you can write out “I will research my audience” a hundred times.

Personally, I’ve always thought that lessons where the teacher just read stuff off a screen were deathly dull, so maybe think about how you can help the teacher present information in a more interesting way than a big wall of text. That’s just my opinion, though!

Keep colour contrast high. Whiteboard content needs to work in all manner of classrooms, which will probably vary from dank dungeons to bright-as-the-sun computer labs. There are colour contrast checker tools that make this easy, if time-consuming. Plan for it, and do it while you’re designing, because there’s nothing more annoying than having to go back through all your designs and change everything, again.

Consider including high-visibility modes to help teachers who have crappy low contrast projectors or sunny windows with no curtains.

Don’t make people scroll. Keeping everything on screen at once will make thing easier for teachers, because scrolling means locating the scroll bar and dragging your finger down the board, rather than a quick click of the mouse. If you really do need to scroll, think about how you can minimise the pain – for example, “proper” touchscreen interfaces let you scroll by dragging any point on the screen.

The option to go full-screen is good. It helps teachers focus the class on the content rather than what’s in their bookmarks or any other screen clutter.

An interactive whiteboard is basically a big touchscreen, and it’s worth bearing that in mind when you’re planning functionality. A lot of traditional web HTML content is fine, but for more interactive elements it’s easy to trip yourself up by designing for a single user with a mouse and keyboard. If you’ve got guidelines for designing for iPad then take a look at those because they’re probably relevant – just don’t go too far the other way and neglect the needs of your desktop users.

The touchscreen interface has some important implications:

There’s no mouse cursor. Well, there kind of is, but not in the way it works on a desktop. When you put your finger on the whiteboard the cursor will jump to that point and simulate a mouse button press. Release your finger and you’ll get a mouse button release. Otherwise the cursor will just sit in the same spot until you interact.

You can’t hover over things on a whiteboard. This means no mouse over events, so no interactions on rollover. Don’t rely on rollover popups to deliver information, because they ain’t happening.

When you’ve pressed you can drag the cursor around, which will probably display rollovers (depending on how you’ve coded them) but this behaviour seems inconsistent across different brands and is not obvious to the user.

Similarly, don’t rely on being able to tell when the user has moved their mouse out of something, or even “moved the mouse” at all. It seems obvious, but those events are so common in desktop apps that it’s easy to forget about them. On an interactive whiteboard, there is no mouse. And no-one can hear you scream because your app relies on rollovers and now you have to change it all.

Beware press and hold. On some models of IWB (but not all) pressing and holding in one place for a few seconds will be interpreted as a right-mouse-button click. Maybe that’s what you want – but it probably isn’t.

Fingers are less precise than a mouse cursor (and more chunky). When you’re used to the sensitive, high-spec interface of an iPhone it’s not as obvious, but for uncoordinated kids using a crappy old unbranded whiteboard it can be an issue. Make sure that hit areas are big enough for fingers and well-defined, with as little overlap or confusion as possible. I know that’s good advice generally, but it goes double for a whiteboard.

The minimum suggested hit area for mobile is 50px (I imagine this varies by device etc) – there’s no standard for whiteboards as far as I can tell, but just bear this in mind.

The user’s hand and arm will likely block some of their view of the screen when they reach to interact; showing critical information right below where someone’s interacting will require them to bend their arm or head in an uncomfortable way to spot the cue – if they don’t miss just it altogether. Some whiteboards use overhead projectors which can make the problem even worse by making your entire body cast a shadow.

Some whiteboards will have whiteboard pens, which will give a more precise interaction area and additional controls, but as with most things here it’s best to not assume that classrooms will have the latest, shiniest equipment. Whiteboard pens sometimes contain widgets that make the board interpret them differently as well, which may cause unexpected behaviour.

It takes more effort to move around a whiteboard. When you’re using a mouse, moving to the other side of the screen is a mere flick of the wrist. But on a whiteboard, dragging something from the left to the right involves keeping your finger firmly on the screen and moving your arm (and probably your whole body) a metre or so.

Whiteboards can be very unresponsive, so if your activity includes fast or precise movement bear that in mind. Some brands are pretty bad at detecting taps occurring close together in time (eg double clicking).

Testing is difficult. Different brands of whiteboard offer hugely varied levels of contrast, responsiveness, types of interaction and all kinds of other totally non-obvious stuff. It’s relatively common to encounter those most premature-hair-greying of bugs: something to do with a specific piece of hardware that you don’t have access to.

There’s not much you can do about this except be aware of it and try to build resilient, flexible apps that can be easily tweaked if it looks like a specific thing is causing a problem.

We had trouble when a client’s whiteboard showed weird text distortion artefacts and serious unresponsiveness when ours was completely fine. This mysteriously fixed itself after a day or so, which was just as well because we had no idea what was causing it and no way of fixing it.

The people who are testing your content are probably not teachers. Unless they are, in which case it’s fine. But it’s possible that some errors are coming up because the person doing the testing is unfamiliar with interactive whiteboards. This sounds like a bit of a cop-out, but all child interaction with the board will be teacher-moderated, or at least guided, and most teachers will have experience with boards in general (and specifically the quirks of their board).

It’s not something to rely on, but it is worth bearing in mind when you’re bug-hunting. For example: almost all teachers use fingers to interact and pens to write with on the board – that’s how they’re designed to work. But our testers were using the pens to interact with all the content, which was throwing up some weird results.

Celebrate the teacher! This ties into the “too much crap on screen is boring” bit. You may or may not actually get a say in what the content is that you’re creating, or how it works, but if you do then try to make something that lets the teacher teach, rather than just be a drone who exists only to click through a slideshow.

Use interactivity, audio, quizzes and reveals to make something that can help the teacher inspire their class. There’s a wealth of information online about what makes good teaching content, so check that out, look at presentation skills and information and talk to teachers. The teachers will appreciate it, and so will their pupils!