26 February 2014

Talking to users

This week I’ve been preparing Captivate videos with voiceovers for a client. It’s a task I particularly enjoy, and wish that more clients would request this kind of service. I think adding sound to training materials is brilliant for accessibility reasons, as well as improving the customer engagement with what can otherwise be very dry texts. You may be thinking of producing something similar in your organisation, so here are a few tips:

Learn the tools
Preparing a good software simulation or e-learning experience is a very different task to writing a manual or online help file. I see a lot of adverts out there for technical communication roles where Captivate is thrown in on the same list as Word. Captivate is excellent software, but in terms of complexity it sits somewhere between PowerPoint and the high end production software used to make movies. It’s relatively easy to learn, but tricky to master, and the difference will show in your final products. Help is at hand with some very nice on-demand training from Adobe, but nothing beats a bit of practice.
Choose a voice - watch the Simpsons!
If you don’t know the show, listen to a few episodes of the Simpsons before voicing training material... it’s an excellent guide to the non-verbal qualities we hear when people speak. When doing voiceovers, I’m always tempted to channel Troy McClure; the character famous for introducing himself at the start of his segments with comments like “Hi, I'm Troy McClure, you may remember me from such instructional videos as Mothballing Your Battleship and Dig Your Own Grave and Save”. I’m not talking about dropping in my own name, or having some other semi-comedic catch phrase. However, choosing Troy’s confident, paced timbre over Crusty’s manic laugh, Homer’s grunts, or any of the accent-heavy, metaphor-rich, and confusing dialogue we find from Willie, Apu, Mo or Bart pays off. Accents are a wonderful sign of the breadth of the English language, but if you’re constantly frustrated by automated telephone systems failing to understand you, then you might want to consider finding a colleague to read your script. Back up your planned voice with a nice microphone and Audacity and you’re good to go.
Have a conversation, with pauses
If users were able to cope with a deluge of information, they wouldn’t have started the training video in the first place. The last thing they want is more self-loathing because they can’t execute the steps fast enough to keep up with you. The lazy solution to this is to put a loop into the video so that they see and hear everything twice, in the hope that you’ll catch them the second time round. What I prefer is to have a more natural conversation with the user that includes details from the user case I’ve generated... so when documenting a course management platform, I’ll include information that may not make it into the manual, like the reasons an experienced teacher would choose to set certain genres of reading assignments, to give the user time to catch up with the on-screen steps.

A good tutorial video has many uses, it becomes business-wide content that can be streamed to the TV in the reception area, used by the marketing team at client presentations and trade fairs... most importantly it gives a real alternative to the written manual for users with accessibility issues or a paucity of time. If you’ve had any experiences (good or bad) with training videos and e-learning content, feel free to share in the comments below.


17 February 2014

Intentionally bad

Have you ever encountered tasks or subjects that are are written about so badly or sparsely, you get the impression that it’s been done on purpose? I can think of two topic areas where the documentation fits this description together with some pretty good reasons why.

Gunpowder, treason and plot
Most people know the composition of gunpowder and the ratios of the mix aren’t too hard to come by. If you watch the news you probably have a reasonable idea of what goes into home-made high explosives... but that’s as far as it goes. Most descriptions of anything that goes “bang” are curiously short of a step by step guide to manufacture, whilst the literature that does exist seems subject to a campaign of nay-saying and warnings of disaster. The reason (of course) is that those of us who understand how these things are made would rather people who shouldn’t have explosives blew themselves up in their own garden shed when getting it wrong.
Hacking is performed much like any advanced task on a computer. It’s not The Matrix, often it’s just a case of putting the right bits of SQL into a box on a webpage or working out that email addresses in a company follow a pattern (such as [firstname].[lastname]) and going through their login page one employee at a time to find the dude who’s been allowed to use 123456 or password for their login credentials. In a less than ideal world, admin@[company].com with an obvious password will exist with all the implied access. More advanced hacking (the kind that makes the newspapers) requires detailed knowledge of exploits and weaknesses in systems (that I don’t have) which are painstakingly researched and closely guarded secrets. Often tutorials on hacking stop just short of allowing the reader to do any damage, whilst most of what happens has no easily accessible knowledge base as it would allow software companies to conduct a bit of counter research and fix their products.

What are the implications for technical communicators from these two nefarious examples? Well, firstly, there is a rebuttal to the school of thought that says “share everything, and put it on the web“ – anything that gets released out the door should be vetted so that it doesn’t give away commercially sensitive details or allow harm to come to the organisation and its customers – this includes the habit that some software providers have of publishing their default admin account details and passwords in manuals available in soft-copy form without reminding (or forcing) their customers to change them. Somewhere, a customer will place these documents on an unsecured intranet, and that will open up a vulnerability for every client you have who hasn’t bothered removing or changing the default account settings.

Secondly, there’s the social proof provided by these well known examples... if products don’t have documentation, or if documentation is incomplete, there is a risk of damaging reputation because clients will identify the product with the dodgy, and one way or another they’ll trust you less than they should.