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.

Andrew

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

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.

Andrew

New devices, alien worlds

I wrote earlier about the way in which new devices with curved, round or irregular shaped displays would need new standards and vocabulary in order to describe the interactions with those screens and surfaces, partly because those surfaces are likely to be touch sensitive. It’s not an insurmountable problem, and the biggest issue may well be the politics involved in getting professionals from a variety of manufacturers and background’s to agree. That being said, there are authors who’ve developed a lot of time and thought to the description of novel geometries and I’d like to think that when standards committees meet, they’re going to channel some of the greats of science fiction.

Disc shaped, or round screens

An “always up”, round screen would make a lot of sense for tablets of the future (if Apple are reading this, I’d quite like royalties). We’d have to get used to seeing web-pages cut or scaled in interesting ways, but for many other applications including games and creative apps, there would be many advantages (not least because our eyes are “round” and much of our visual field is wasted with traditional screens). For movements around the screen or involving rotating, we have clockwise and anti-clockwise to fall back on, but what about moving to and from the centre of the screen. Perhaps the best known vocabulary for describing a surface of this type is found in the work of Terry Pratchett who coined four cardinal directions of “Hubward”, “Rimward”, “Turnwise” and “Widershins” to describe navigation on his Discworld. Turnwise and Widershins only really work for a disc already in motion, but hubward and rimward are the words we’re going to need the day we get an iDisc.

Rings, bracelets and wearable tech

As we start to see devices like the Smarty Ring, become more popular we’re going to be looking at non-visual interfaces that work with touch, motion or other forms of manipulation (the link here is to an excellent paper from the University of Glasgow... it’s well worth a look as it gives a good summary of what can be done and isn’t trying to sell anything). Describing the control of such a devices is going to be tricky, in part because the device can rotate around the arm, as well as being touched or manipulated by the voice. I couldn’t really find anything that worked for touch sensitive bands in professional or academic literature but an answer comes, yet again, from a fictional world. This time we turn to Greg Bear and his writing set in the fictional Halo universe. He uses turnwise and crosswise to describe movements around and across a band respectively and this could work when coupled with “left”, “right”, “clockwise” and “anticlockwise”. I initially toyed with the idea of using the geometry and layout of the human body to help with the descriptions, but realised that these devices may be worn on either arm by left or right handed.

Projected space

By projected space, I mean 3D environments created by devices such as Kinect, Google Glass, and the very Minority Report-esque Leap Motion controller. I feel that many of these systems will be dictated by the intent and application of the software and hardware being used, but it’s quite obvious that any directions being given will need a reference point. An example of this being done well can be found in the work of John G Hemry who tells tales of wars in space together with a spatial reference system he’s thought out that allows for ships to quickly orientate themselves in the 3D environment of a new solar system. Documenting a system that relies on the body for imput would not just need a way to describe the like this may well not look forward at all, as what we’re really talking about is whole body movement. The language and presentation of the documentation may borrow heavily from descriptions of other physical movements, whether that be those found in martial arts text books, reference works on magic tricks or even the Karma Sutra.

Answers on a postcard (or in the comments section) for what you think the biggest new interface will be, and how we could go about describing it.

Andrew

That was the year that was...

Thirteen is considered by some to be an unlucky number, so my first thought as I settled down to write was to wonder why. After a few minutes of pleasurable distraction (what did we do before search engines?), I’ve discovered that there are a lot of theories but no hard evidence to support one over another. So how was 2013 for us, good or bad?

Well, as with every small business, we’ve had our ups and downs – sometimes exacerbated by the fact that a family crisis (no matter how small) tends to affect every member of the business when you’re the same family! I’m not going to dwell on the negative, though... there isn’t a lot of that, and I’d much rather focus on the positive.

So, what happened in our world in 2013? Quite a lot, now I come to think of it! In no particular order:

• We changed the legal status of our business – we activated Clearly Stated Limited on 1 November 2013. The company had existed since Clearly Stated started, back in 2004, but had been dormant as until recently the advantages of trading as a company were negated by the extra administrative burden. Now, however, we are beginning to spread our wings a little, and the change in status fits with where we see ourselves going in the future.
• We presented at TCUK 2013 – both Andrew and I delivered sessions at our professional body’s annual conference, and both were well received.
• We delivered more writing skills training courses – both to local authorities and at a university.
• I dusted off my clinical knowledge to work on a health-related application.
• We received a SaBRE Certificate which acknowledges Clearly Stated's support of Andrew's reserve service.
• I developed a CPD framework for the ISTC.
• Andrew passed his first module on the Graduate Certificate in Technical Writing with the University of Limerick.

All things considered, that’s a pretty good year. 2014 is already shaping up quite nicely. We’ve made contact with a few people we’re looking forward to working with and are already planning conference attendance and milestones for the next phase of our development.

Alison