The benefits of looking rubbish
I’ve been using Balsamiq a bit recently. If you’ve not come across it before, it’s a neat little package that’s great for producing prototypes. You get quite a large library of commonly used interface components. Just drop them into place, and off you go. You can link between screens to produce something that mimics a working product – albeit in a rather limited way. There are quite a few prototyping products like this around, (have a look at Axure, or OmniGraffle and of course Visio can do this kind of thing) mainly aimed at the software development mainstream and used by information architects.
But what really sets Balsamiq apart is that it looks rubbish. It’s deliberately been created to look like it’s hand-drawn, not developed on computer. The reasons for this are clear: it’s common practice in prototype-driven cultures (see my article on this here) to make early prototypes look poor and unfinished in order to get users to offer up their ideas for improvements. We know from experience that if you produce a prototype to look good, people are less willing to criticise and improve it.
This set me thinking about how, in the e-learning industry, we often get our priorities in terms of visual quality the wrong way round. It’s common practice to produce a sales presentation version of a potential e-learning solution so that it looks amazing; then once the job is sold we often put huge effort into polished prototypes in order to get them approved by project sponsors. But the general visual standard of finished e-learning courses is still deplorable, and it’s a common experience for project sponsors to receive something that visually is less appealing than the thing they thought they’d bought all those weeks or months before. This is a serious problem for us. The quality and sophistication of graphical interfaces is increasing sharply. Just look at the interface of any new mobile phone – these are teaching consumers (aka learners) what to expect from our interfaces.
One thing that Balsamiq is reminding us is that early versions of what we design need to look rubbish. We learn from other design disciplines that poor early prototypes result in better, and more cost-effective end products. Prototypes need to encourage users to offer their suggestions for development and improvement, and to help us confirm that we we're designing will meet their needs.
And perhaps by removing the need for us to invest time and effort early on in specialist graphic artists, tools such as this will encourage us to improve the visual quality of our end products. I live in hope.
Rapid tools will stimulate more creative e-learning
Rapid tools will stimulate more creative e-learning. Are you kidding?? Sounds as feasible as “square wheel”, “tasty sprouts” or “chocolate teapot”.
I’ve just spent a fruitless hour or so on google, technorati, delicious and elsewhere trying to track down who’s talking about how rapid e-learning tools can be used creatively. And apart from Tom Kulmann, I don’t think many people are. My intention was to be helpful to readers of this blog by providing a bunch of links. But I failed.
This doesn’t quite make sense. We know, from the history of many software types, that initially people are conservative with new software tools: they imitate the real world. We also know that what usually happens is that as enough people get hold of new technologies they do crazy, unpredictable and creative things that initially sound nuts – but soon become normal. Think about texting on mobile devices: it was originally a back-channel for techies.
The idea of pushing simple rapid tools to the edge of their capability really appeals to me. It is in itself a creative challenge, it may well have a commercial rationale (e.g. why employ expensive e-learning agencies who often use proprietary tools when you could employ me!) and, well, dammit, I just like looking at things the wrong way round.
Rapid tools, or their near offspring, will catch up proprietary and specialist tools at some point soon. I’d really like to hear from anyone who’s pushing the boundaries right now. Who is using Articulate to produce complex, rich story-based learning, or game-like experiences? Who’s using Captivate’s excellent questioning functionality to produce fully-scored interactive scenarios (something that I’ve heard Flash developers describe as “hard” and “expensive”). I know both are possible…
Incidentally, what I’m most interested in is work that is genuinely “rapid”. If you look at Articulate’s own gallery of courses, there’s some lovely stuff, but a lot of it needs the services of graphics specialists and animators. This slightly misses my point. If you’re going to employ a Flash designer to do expensive stuff, you probably don’t want to push Articulate; use Flash instead. For now...
Are we nearly there yet - continued
Somebody asked me: "why the concern about in-house/off-the-shelf tools?"
Briefly: a few years ago, with Mark Iliff, I produced what we called "The e-learning buyer's stab-vest". It was part of a job we did for Learning Light, and its aim was to offer defensive responses to the many unreasonable claims made by vendors of e-learning products and services (thereby preventing painful stabs - gebbit? I know...the title was Mark's idea...). Maybe I'll produce an up-to-date one; any suggestions?
My view is that we're increasingly moving from a position where it was a distinct advantage for a vendor (of content) to say something like "...and at the core of our offering is our own, proven, proprietary build tool..." to one where a prospective purchaser might respond "Ah - so you'll be more expensive, less flexible in terms of resourcing, and we'll be tied into you for ever...ok...we'll call you...".
Are we nearly there yet?
One thing we know about most software products is that they tend to follow fairly predictable cycles. We know, for example, that most software starts expensive and gets cheaper, that functionality increases, that quality may initially drop, then improve, that most categories tend to become dominated by a few larger players as the market for each category rationalises. And so on. These are, on the whole, predictable patterns.
One software cycle I've been interested in for a long time is the one where small technical agencies - such as e-learning producers - gradually shift over a period of years, from developing their own in-house tools, to using off-the-shelf packages. This makes sense in most cases. The level of investment that Adobe or Microsoft can make in a product far outweighs the money that even the largest e-learning company can afford.
This is a critical cycle for most e-learning companies to understand right now. The market is swamped by increasingly powerful, well-invested authoring and other development products, all aimed at trying to increase speed of production and lower cost. The decision that all e-learning agencies will face is not if to dump their in-house tools, but when.
The main rationale behind developing in-house tools is to meet subtle or unusual client needs in bespoke projects. And this is always a good rationale - for a while. In the early days of a software category, most off-the-shelf packages are crude. But the problem is that software history shows us that off-the-shelf packages almost always catch up and sweep away the relatively under-invested products developed by agencies (I sometimes compare this to when the main pack in the Tour de France sweeps past one of those many over-optimistic breakaways...).
I've worked for at least two companies who invested heavily in in-house technology at only slightly the wrong time. Needless to say, neither now exists.
So - where are we? Are we at the point where developing in-house authoring tools is a route to extinction? I'd say "very nearly". If I were in the process of developing or even maintaining an in-house authoring system right now, I'd want to be sure that I'd done my sums in terms of shelf-life and payback. Given some of the superb development tools that are arriving now, a time horizon beyond a year or so would look to me like optimism bordering on delusion.
Is Prezi an e-learning tool?
Thanks to everyone who got in contact after I put my eLN/Prezi presentation up here. I've had a lot of questions and discussion points raised; so here are some thoughts.
1. Why do I think Prezi is so great?
- it's about mapping information; giving people an overview. That's the reason I like mindmaps too. So, the ability in Prezi to show people the big picture then move around it is very valuable.
- it's about depth and levels. A lot of information doesn't suit being presented in linear bits (like Powerpoint); a lot of information benefits from being organised in layers, which is what Prezi's zooming facilities allow me to do
- it's great eye-candy (damn! I had to admit that one)
- it's not Powerpoint; don't get me wrong. I love Powerpoint. But anything that challenges our assumptions about how information can be presented is a good thing; anything that gives us a new angle. A possible tangent: how long is our current paradigm of "pages/screens" going to last? There's a lot of work being done at the moment on zooming/panning interfaces. Will page-based e-learning last much longer? And slide-based presentations? I'm not sure.
2. How long does it take to learn and produce stuff?
- I reckon you should assume it takes a couple of hours to get productive.
- I reckon it's a lot slower to produce things on than Powerpoint - say 50% slower, but a lot of that time is invested in re-thinking assumptions about how information is presented
3. Is it an e-learning tool?
Hmm. I've written too many words already. But I'd say "yes, of course"...because it's electronic and it helps people learn things.
If you want to take a more conventional approach, here's something I've used it for recently, as part of a conventional e-learning solution:
- First I produced a whole bunch of text and graphic effects in Prezi; the kind of thing I'd normally get a (cheap) Flash developer to produce. It was great not having to explain what I wanted to somebody else. (Of course, I could have used SwishMax or another easy .swf producer, but I was experimenting...)
- I then used CamStudio to add voiceover and output to video files
- I imported into Articulate
The whole process took no more than a couple of hours, I did it all myself and apart from Articulate, all the tools involved were free.


