18 December 2013

Keeping up-to-date...

Things change so fast in our field (technical communication) that it can be difficult to keep up. What can be even more difficult is providing some evidence that you’re at least making the effort. That’s why I’m pleased that the ISTC’s CPD framework is finally up and running. (I’m also pleased because getting it to this stage has taken an inordinate amount of my time over the last 18 months.)

So, aside from getting my life back, why am I so pleased?

Well, in line (I guess) with just about anyone who takes what they do seriously and want to do it to the best of their abilities, I am constantly learning. I don’t mean I’m constantly attending training courses – although I do some of that too – but that I work on a different project, find out how to use a new tool, come across a technique that someone shares... and I find I’ve learnt something really useful.

My problem, until now, was that although I knew I’d learnt lots of good ‘stuff’, put on the spot in an interview or when writing a covering letter for a job, I couldn’t always remember what I’d learnt when, or what the context was at the time. In short, I couldn’t tell a coherent story to support my application.

Now that’s not a problem.

I’m a Fellow of the ISTC myself – and although all our members have a requirement to keep up-to-date, I can now prove it. I have to maintain a CPD record to keep my Fellow status, which makes it all the more valuable to me.

And having to keep a record means that the information that was previously just swimming around in my head and had been absorbed into ‘normal working practice’ can now be accessed as discrete pieces of information and referenced.

You know what it’s like – you’re writing a covering letter to apply for a contract and you’re desperately trying to think how you can show you’ve met a particular requirement. Now instead of frantically trying to remember, I can just have a quick glance at my learning record instead.

Couldn’t I have recorded this anyway? Well, to be honest, I often did... but not to the same level, as it was only notes for my own use. Now there is a little more meat on the bones.

If I want to think of myself as a professional (and more importantly want others to do so), I need to start acting like one.


27 November 2013

Mixed Messages

I don’t usually touch on politics in my blog posts – I believe it’s against policy – but I was struck by a recent article where our illustrious PM decided to link the quality of state education with the inability of many to find a entry level job on a production line. As a technical communicator, I think he’s wrong. My reasoning is based both on my own experiences in education and training, and my current professional practice.

I remember preparing for my GCSE English exams. Our English teacher received a missive from the exam board on the subject of ‘structured writing’. There was a whole section on the types of phrases we could use to compare and contrast arguments and introduce points of view, which our teacher dutifully read out to us. They became more florid the further into the list you progressed, perhaps reflecting the fact that a lower-grade student would only be expected to remember the first few. Right at the end was “there is a train of thought that runs...” – by this point the class was in hysterics. There was something about the way that our teacher chose to read that list that let us know it wasn’t to be taken too seriously. She finished with the staunch admonition that were we ever to use such a convoluted phrase to convey “others think...” she would hunt us down one by one.

There is, however, a train of thought that runs to the acceptance of such phrasing (it has taken me 15 years to work that into a piece of writing with an almost straight face). The people who hold this view were taught by the other type of English teacher: the ones who didn’t laugh and snigger at the directives being sent down from those who view having an education as having the ability to show off (or as it is called in the north of England, ‘ponce about’). The adherents of this doctrine write as floridly, passively and with as many synonyms thrown in as possible because they have been taught that this is how the educated communicate. (If you don't believe me, watch the tortuous pursuit of definition that is Prime Minister's Questions.)

Of course, this is how the ‘educated‘ tend to communicate. Lead engineers, managers, and those at CxO level (where x is some function of the business) generally communicate from within their own comfort zone, blissfully unaware that to those outside their circle they may as well be using a foreign language. The manager states “we must be flexible with regards to the future” when planning layoffs; meanwhile the employee is wondering when the new yoga classes are going to start. In another example, the lead design engineer has referred to the same binary function selector as a switch, toggle, selector and lever interchangeably within a single paragraph of emergency shut-down instructions... that are being read whilst the machine in question trundles towards a cliff edge. Both examples mirror political communication a little too well.

The real problem is that job seekers don't know exactly what they need to do to get the job they want because they aren't told in a way they understand. Therefore, the issue is not in the education and training of the many, but the education of the few who think their communications strategy is fit for purpose when attempting to get a message across different levels in society, organisations and processes. In many cases the problem lies with message and sender, not the befuddled receiver. This gap is why technical communicators exist. We work with subject matter experts and transform their message into something that the end user can understand.

Whilst my services as a professional communicator are a valuable commodity, I feel that on this occasion I can distil 25 years of experience as a learner, teacher and technical communicator to help the Prime Minister and anyone else who fancies being a politician or leader of men avoid some often identified pitfalls.

Answer the question being asked
You may be a leading expert on a particular subject, but when someone asks “what happens if I press the big red button?” your answer should go along the lines of “when you press the big red button, X happens.” Your audience do not want to know about why you think red is a nice colour, why X is such a favourable outcome, or how brilliant you were in suggesting to a colleague that they have their secretary open a bidding process to pay a large company – run by a family friend – to subcontract an electrician to install the big red button.
Think about the context of the recipient
I have an emergency bandage. The instructions are in 5 steps. Steps 1 to 4 deal with applying the bandage, and consist of big clear illustrations that can be read under a torch in low light. Step 5 deals with removing the bandage and consists of black text on a grey background. The pictures exist because when your mate is bleeding to death at 2 in the morning, you don't have time to read an essay. There are people in society who – for whatever reason – are bleeding out and are relying on you and your team to get the job done, and they really don't have time for anyone to wade through verbiage.
Short words are the best
This pithy piece of tech-comms wisdom stems from one of your predecessors, but it is true. I'd suggest that "yes" and "no" are two of the short words that might come in useful for answering questions. If people want your life-story or to know what you've been thinking about recently they can call you "Dave" and add you on Facebook.

09 July 2013

We have ways of making you think!

A good friend of mine is a developer at North 51. Recently we had an interesting discussion about mind control. Not the type of mind control that would let me unleash hordes of hypno-zombies as a tranced and swaying flash-mob at the local Tesco (although having sacrificed last Sunday morning in that edifice of consumerism, I’m not entirely sure someone hasn’t already pulled this off), but rather the kind of mind control that would let me think my pointer across the screen, or these words onto the page.

Whilst even this seems far fetched, headsets like the one pictured here let people play Angry Birds with just the power of their minds. Angry Birds is a fairly simple game, essentially involving the movement of a mouse/pointer and a single click or dragging action (depending on whether you are playing on a PC or a tablet). The fact that the description of the game varies between a tablet and a PC gives some idea of the issues we might face when giving instructions for a user whose interface is their own mind. The cursor in Angry Birds (PC) is a hand, so are people playing the game thinking “I’ll move the mouse around with my hand” or “I’ll move the hand around with my mouse” or even “I’ll move the hand around with my hand via the mouse” (think of your own variant). Any guidance for play-by-brain computing not only has to account for these differences when describing the desired end result but must also cover the thought processes that are involved in reaching it. I have been thinking about how this could work in practice:

You are feeling sleepy
Instructional materials could use techniques from the relaxation or hynotherapy fields to induce a non-cluttered state of mind before operating the game/robot surgeon/share dealing platform. This is not really a new idea. Educators have been springboarding off the work of Soviet scientist Georgi Lozanov to create non-threatening, trance-like language classes filled with baroque music and a brain boosting vibe for decades now, and there’s no reason it could not be coming to technical documentation near you soon.
Enter the Sandman
Sandbox environments are big in the gaming community, and as documentation gets increasingly gamified there’s a lot to be said for blurring the line between the real situation and a simulation. (Pilots do this already, the theory being that in a simulator no-one can hear the passengers screaming, praying or bouncing off the walls.) Yu-kai Chou divides gamification into White Hat (nice) and Black Hat (bad) gamification. A nice happy sandbox environment with all the tips, hints and lessons being presented in a calming and constructive way would blend the best of usability with the logic of well-written instructions and a little bit of Zen.

The future is probably a lot closer than you think on this one, so I’d be really interested to hear from any others (technical communicators or otherwise) who’ve given this fascinating field a bit of thought.


18 June 2013

Freeze frame violence

My first degree (back when I could afford to study out of interest) was Theology and Religious Studies. I’d told people I was studying this subject because I wanted to be a diplomat, but a big part of it was the traces that previous iterations of civilisation have left scratched, carved and drawn in the world. Look at many temples, or even cave paintings, and the depiction you find is often of violence. It might be a Hanuman carving of a battle against demonic forces (Thailand), a beheading (the Sistine Chapel, Rome) or arrows being launched at galloping animals (cave paintings, France). These artistic portrayals of violence are reminiscent of the rapid cuts and flashes seen in the fight scenes of Raging Bull where the freeze frame is chosen as the most dramatic and telling part of the whole physical sequence.

This was particularly fascinating to me as I’ve always studied some form of martial art. First it was Karate, then fencing at university (I even won a medal for that one), then Mongolian wrestling in China, Taikwondo with the air force in Oman, and most recently boxing. All of these come with books of some description that in many ways mirror their artistic counterparts in that they freeze the action at the most telling moment. An example from an early Aikido manual is given here. In this picture the combatant on the right is defending himself against an armed aggressor. The scene is frozen at the moment of impact. Artistically this is all well and good, but what else can we see from this image that is of use for technical authors?

Capture the moment of impact
I’m reminded of a style guide I recently encountered that stated “When accompanying an instruction with a screenshot, the mouse pointer should be displayed carrying out the task.” In this case the mouse pointer is the right hand as it strikes below the chin.
Decide on sensible minimalism
The defender has stepped in with his left leg and lowered his centre of gravity to make himself more difficult to engage with a long bladed weapon. This is shown without any real need for explanation as any martial artist will tell you, footwork eventually becomes reflex. In the same way there are things that we don’t bother to screenshot or explain in great detail as we assume that if the end user cannot turn their PC on, they’d hardly be reading the manual for a complex system.
Establish documentary conventions for important details
In this drawing, our defender has a single finger hooked at the waist of his attacker to off-balance and drag the swordsman forward onto his strike. This is artistic emphasis: the actual move requires a handful of belt, clothing and man to be grabbed in a fist and bodily hauled towards the defender, but when drawn this would look too much like a second fist striking the target and so the single hooked finger is drawn to emphasis the pulling action. This and other stylistic elements are found again and again in hand drawn martial arts manuals. They are not dissimilar to the refined vocabulary used to describe on-screen processes (interestingly the cursor sometimes morphs into a hand with a single extended digit to reflect an action in much the same way).

Revisiting the Sistine Chapel, we see Goliath’s final moment captured. As anyone who’s ever chopped wood or swung a hammer will tell you, the moment to get right is the top of the swing when all the force and balance and energy is about to be released. David is exemplary: his shoulder is cocked, his wrist open and his whole trunk unwound ready to deliver the blow. Goliath is as good as dead, as if the blade had already completed its gore-punctuated descent. As technical authors, we should aim to capture this exemplary and telling moment as well as the final static outcome in what we write and display.


17 June 2013

TCUK 2013: A two session preview

We’ve had some good news at Clearly Stated this week. We are both going to be presenting at TCUK in Bristol, which reflects well on our dedication to not only our own development as technical communicators, but the development of technical communication.

For those of you who are interested, we’re offering a slightly more in-depth sneak peak of our sessions at the conference. There is no need for a spoiler alert, but hopefully a bit more insight into the presentations will helps peers reading this blog choose their session at the conference.

When Culture Meets Content (Andrew’s session)
My first role as an author was creating training materials and designing courses for the Royal Air Force of Oman. This presented unique challenges together with the possibility to conduct research. The audience for these materials and courses were entirely male, Omani and Muslim, and I quickly began to notice that the reaction to materials (either my own or commercially published materials) was coloured by the cultural perspective of the students. Through a comparative study, I set out to explore some of the issues documentation and training materials face when being viewed through the middle eastern cultural lens. It is important to note that many of the cultures that are sensitised in some way to the perceived morality of documentation also favour indirect communication and value face. Many of the lessons learnt may help those wishing to position their documentation and services to avoid faux pas.
Managing as a freelance technical communicator (Alison’s session)
‘Managing’ often conjures up images of project plans, performance appraisals and (of course) meetings. Depending on the size of the organisation, one person may fulfil more than one role (as both a project manager and a people manager, for example) but nowhere do the hats pile as high on one head as when running your own small business. Since I started Clearly Stated, I’ve had to manage my workload, my finances (including estimating and quoting), my clients and my employee – and find time to actually do the work I’m being paid to do! The intention is for you to learn from my mistakes, helping you to work smarter, not harder.

We look forward to seeing you there.

Andrew and Alison

16 May 2013

Learning by sharing

Two hands holding a ball covered in words relating to learning

I’m in! I’ve received my ‘proposal accepted’ email from the organisers of TCUK (Technical Communication UK – the annual conference for anyone in my field in the UK) and I will be delivering a session on ‘Managing as a freelance technical communicator’.

I'm really looking forward to it, and have between now and mid-September to work out exactly what my message is, how I'm going to deliver it, and how I'm going to learn from the other people in the room.

Wait a minute... learn from the other people in the room? What’s going on – aren’t I the one supposed to be sharing knowledge? Well, this will be the fourth time I’ve presented at this conference (and its predecessor) – and each time I’m sure I’ve learnt at least as much from the experience as those who attended the sessions.

The first session (in 2008) was co-presented with Alison Reeves (of Write to Win). We did a 3-hour (yes, 3-hour) workshop on advanced techniques in Microsoft Word. Alison came to see me before the conference so we could work out who was doing what, and when. I lost count of the times one or the other of us would say, “How did you do that? Do it again... slowly.” We'd both been using Word for years – but we learnt a lot from each other that day.

Last year my session was on CPD (Continuous Professional Development, which some of you may know as CPE or Continuous Professional Education). I incorporated an exercise where people in the room discussed various activities and decided whether – and under what circumstances – they were valid CPD activities. Watching people discussing the options, coming to conclusions, arguing, changing their minds and challenging others opened my eyes to a much wider range of possibilities than the already-wide range I’d had in mind.

It's not just restricted to conferences – I teach writing skills, and am a tutor with the Open University, and it’s rare for me not to experience a fresh perspective at some point during a session.

TCUK is a fantastic learning experience even when I’m not presenting (which is the main reason I go – see 'Why you should attend TCUK 2013 - a personal perspective'). It’s also a great opportunity to catch up with others in my profession... the life of a freelance technical communicator can be somewhat isolating, even now there are two of us. If you are involved in technical communication, we’d love to see you in Bristol!


29 April 2013

The Infinite Monkeys Approach

I once knew an expatriate worker in the Far East who was tasked with liaising with the office cleaners because he could “speak the language”. In theory this was a good idea. However, the cleaners were all profoundly deaf, so whoever got the job was going to have to learn or invent a sign language before they could begin, whatever languages they currently spoke. The assumption of competence being granted because of linguistic faculty is sometimes amusing when it happens in a second language (I ‘speak’ Mandarin, but that doesn’t mean I can quickly and easily understand a lecture about orthopaedic surgery in the language; I’d struggle to keep up with that topic even in English), but from a professional communicator’s point of view it is even more irritating when it's done in the workplace with technical documentation.

Recently I’ve been seeing some particularly bad examples of documentation. The kind of stuff that is so bad that it has passed the point of irritating users and is actively dissuading potential customers. What did it have in common? It was written by ‘experts’ – in the topic, not in communication. I wonder why it gets written like this, particularly when the time of specialist developers and engineers is taken away from their core duties to produce it.

What shocks me is that businesses already know that their geeks often work best when kept away from customers. It’s why they employ sales people to do the verbal communication that brings in sales... because customers want to hear about software meeting their requirements, not how cool the software is because the subroutines are all named after characters from Star Trek, deceased pets or steam trains.

I've also heard of ‘test’ entries into database products that have made their way into training and documentation materials, and even into the finished product. Sometimes these just hinder understanding (“test for empty field” isn't a good example to follow), whilst others can cause offence (“nutty as a fruitcake” as a mental health condition for example).

This criticism is not directed at developers, they do a job I couldn't do, and they do it well. It's directed at the person who decides that because their developers happen to speak English, they're going to save money and give them the documentation to write. As an approach to documentation management this is only marginally better than handing infinite monkeys, infinite typewriters (and marginally cheaper due to the resultant cost of infinite bananas).


22 March 2013

The Underground

Academics, especially the non-scientists, often face the criticism that they have an aloof existence in ivory towers. An easily recollected if ill-favoured example is academic and author H.G. Widdowson who in his book Practical Stylistics has the unfortunate habit of calling non-canonical poems “dogrel”; even when they’ve been written effectively and serve their intended audience well, and especially when they’ve been written in memory of departed relatives. This blindness to, and denigration of, changes in a field weakens not the target of the dismissal and contempt, but the person making the aspersions (which is why traditionalist generals lost out to Germans with panzers and a remarkably modern air force during the early years of WWII). With this in mind this week’s blog is a bit of a walk on the wild side, because out there in cyberspace there are thousands of amateur technical communicators doing very interesting things, sometimes approximating the tools we use, and sometimes innovating to get their message across.

First up there’s YouTube and the ubiquitous video demonstration; the most popular result for the search terms “how to” come from Household Hacker and run from an introduction to the manufacture (at home) of a magnetically responsive liquid to the creation of a candle powered space heater. The presenter uses a variety of camera angles and captions to get his message across, and succeeds in presenting easily reproducible experiments and activities to end users. Whilst he’s not using the latest and greatest technical communications software, he achieves his aims in a way that would make any technical communicator feel it’s a job well done.

Those of us who spend our time writing rather than getting to create video tutorials may feel that there’s less competition from amateur authors, but it does exist for some fairly commonly used software packages. Of course by “commonly used software packages” I’m talking about video games! There are entire communities of gamers on-line who dedicate hours of their lives to documenting the solutions and tricks that go into beating their favourite games. Matt Hughes writes guides to killing (virtual) aliens that are detailed, entertaining AND in line with best-practice in software documentation whilst gamer community forums share exceptionally detailed tips about complex virtual worlds and control methodology with accuracy and incredible end-user awareness (as effectively we have users writing for users).

What does this vibrant underground scene do for us as technical authors? Well, it should be serving to keep us on our toes and pointing towards effective uses of new platforms and media choices for our content.


12 February 2013

Test yourself

Even the best of us make mistakes. How often have you hit ‘Send’ on an email only to wish you could stop it going as you’ve just spotted the howler in the middle of the third line? And the tweets Andrew recently scheduled in the early hours of the morning are testament to this phenomenon too. What phenomenon am I talking about? The wonderful ability of the human mind to ‘fill in the gaps’ – to read what should be there rather than what is there... at least until it’s too late to do anything about it.

We all know it’s much easier to make this sort of mistake with something you’ve written, but even when it’s someone else’s work, we see patterns that don’t exist and make huge leaps of expectation.

Sometimes, though, it’s plain old lack of knowledge that’s the problem – people are hazy on some of the ‘rules’ of grammar and punctuation.

Just for fun, Andrew and I had a go at the Guardian’s grammar and punctuation quiz.

I’m sure our clients will be pleased to know that we passed with flying colours.

How do you think you’ll get on? Go on, I dare you...


31 January 2013

Language marches on

One of my fascinations is the evolution of language and the force that we as writers can sometimes exert to change or preserve it. I feel that the study of the origins and history of the words we use are eximius (that being, something that used to have high value or standing that has fallen out of favour, practice or repute... by learning this word and definition and possibly using it yourself you’re joining my ongoing quest to get a dead word together with a revised and pertinent meaning back into the language and the OED!) and sometimes feel that as authors we have a role to play as the stewards of the language.
This week I’m onsite with a client, sitting next to their existing and quite large technical authoring team. It’s fun to sit with other technical authors shooting the breeze and debating issues for the style sheet. One of the debates has got me thinking about the future of the language, and one about its past:
Articles with extensions?
When mentioning .atd files in a sentence, is it “a .atd file” or “an .atd file”? There didn’t seem to be a definitive source, and we found that we were divided between those who say “an Ay Tee Dee file” and don’t include the dot in the file extension, and those who say “a dot Ay Tee Dee file”. It might sound like a small discussion, but it’s one that would not have been necessary before the computer. Sooner or later, based on consensus, or diktat from one of the style manuals, this issue will pass into a formalised convention and technical communicators will have changed a small part of the grammar and style of English usage.
Wordy Recipes
The second discussion that came up was the consideration of the plural of “formula”. I am pleased to say that as the team was quite strongly weighted with both chemists and those with theological training, the Latin based “formulae” won out. I’m sure there are those out there who think that it doesn’t matter, or that the alternative plural endings we find on some words are tricky to teach the iTunes addled minds of the young. Yet the chemists and theologians amongst us feel compelled to go for the older ending. This was perhaps because in some ways the older variant feels like a richer source of information. Like an old bemedalled soldier on a park bench, the word seemed to lend an air of intrigue and respectability to the otherwise ordinary scene that is painted by a manual.

Back when understanding language was more cool than eximius, an old man was receiving a literary award. He included in his speech the idea that “Broadly speaking, short words are best, and the old words, when short, are best of all.” This is good advice for a technical communicator, if acted upon it leads to writing that is accessible and understood by a wide audience. The implication however is that if we are to marshal words and have them merrily marching across landing pages, fields, sheets and books we must know something of their character. Given the influence this individual had on history, it will surprise some to know that his eventual Nobel Prize wasn’t in something mundane like peace or economics but Literature which goes to show that words do carry extraordinary weight. To borrow from another of his contemporaries, I feel we should tread softly, and carry a big book.

18 January 2013

Spreading the word

I’ve just found myself involved in TCUK13 (the annual conference hosted by the ISTC to which all are welcome). Kai Weber (Technical Communications blogging legend) and I will be delivering the social media build up to what promises to be a signification event on the international technical communications calendar.

Now, as with any big event, some of the details are currently on a need to know basis, but it has been revealed that TCUK13 is going to be held in Bristol on the 24–26 September this year, and will feature some well-known technical communication personalities from around the world. Last year we had Leah Guren, Scott Abel, and Karen Mardahl as keynote speakers, with other presenters including Dr. Tony Self (of DITA fame) who travelled all the way from the southern hemisphere. This year is going to be even bigger, so if you’re a scientific or technical communicator, or know someone who is, you’ll want to follow the #tcuk13 twitter hashtag and @tcuk_conf feed (which I'm administering this year) where all the important news and information is going to be disseminated.

The next big opportunity is the call for papers, which is where everyone gets a chance to pitch their idea for a presentation or workshop. The call will go out in the near future via the @tcuk_conf twitter account and other channels. Presenting at any conference is an important career milestone, and presenting at the annual conference of a nationally recognised and internationally affiliated professional body grants you a metaphorical ostrich feather for your cap.

The really great thing about technical communicators (who include illustrators, authors, presenters, trainers and anyone else involved in the sharing and communication of scientific and technical information) is that we’re really a very supportive bunch. Even if you’ve never done anything like this before, it’s well worth getting your ideas down on paper and giving it a go as experienced presenters are available to steer you in the right direction.

Will I be presenting? Well, that’s down to the programme committee. I had half an idea for a joint session with Alison (a.k.a. mum) but I’ve been advised that juggling chainsaws has already been done, so I’ll have to think of something a bit more appropriate.


14 January 2013

The hidden costs of dodgy documentation

I’ve just finished opening a bank account for my son. This would have been done a while ago, but the bank lost the copies they’d taken of my driving licence. This means that I had to make another trip to the branch for them to re-photocopy the document (I could name and shame the bank, but in general they’re a very good provider).

What I’ve discovered is that I struggle to turn off my inner documentation beast. They sent me a sheet of A4 paper with two lists on it: one of these lists was titled “identity documents” and the other was titled “proof of address”. The instructions (personalized to me at the top of the screen) said “provide one document from list B”... as neither list was labelled A or B, I had to phone the bank to find out which of the two lists was list “B”. (This was further confounded by the fact that a driving licence is acceptable as both proof of ID and address, and yet was only in one of the lists!)

The implications of that simple mismatch between instructions and the reference table can be far reaching for a business:

The number I called was an 0800 number, so the bank was paying for my call. I spoke to the member of staff for approximately 12 minutes (as they had to “take me through security”). I’d just cost the bank wages and overheads. The individual I spoke to in the bank’s call centre said that they got calls about this “all the time”, which I suppose from their perspective is a good thing as horrid and mismatched documentation is keeping call centre staff in work.
How many people would decide not to pursue things any further with the bank in question? There are plenty of competitors who I wouldn’t have to phone after they’d bodged the letter that they sent through after they’d lost things.
An easy way to tell the difference between a phishing email and genuine communication from a bank (or any business) is the way the conman modifies the language at will, not so much to suit their own purposes, but as a clear indicator that they learnt English gathered around the village TV watching 80’s B movie re-runs. I was given the option of sending my original driving licence to the bank in the post, but there was no way I was doing anything other than taking it into the branch after they’d appeared even slightly dubious.
Bad Press
I suppose this blog is an example. Every time documents are inaccurate and it creates hassle for a customer, they’re likely to repeat the tale later in the day when blowing off steam. This could have serious repercussions for a brand, particularly if your marketplace is somewhat niche.

So that’s the breakdown of the repercussions of bad documentation. There’s a builder in my local area who I haven’t asked to quote for me because his business card is mis-spelled, and there are call centre staff in India who I’m on first name terms with because their employer’s FAQ section consists of 2 FAQs and a smiley face (David Hamill's treatment of FAQ usability is well worth a read). The question to ask is how many of your customers are doing the same because of simple and easily fixable mistakes.


07 January 2013

It’s only words...

What is it about writing, especially factual (technical) writing, that has so many people believing they can do a better job than – or at least, as good a job as – someone with training and experience? Is it because everyone (at least, all of you reading this) can read and, by extension, write? In the sense of putting one word after another on a piece of paper or a screen, that’s true: everyone can write...but can they write well.

There’s something about the written word that seems to encourage people to do something they would never do with other professions. Or maybe they would. A recent experience reminded me of the attempt by an amateur to restore a Spanish fresco.

I had been commissioned to write about a technical process in an engaging way to highlight the innovative practices a company were following. The first draft was duly submitted and reviewed by my client, quickly followed by an updated version incorporating requested changes – so far, so good. After some time chasing for feedback, I was told that my client’s customer (about whom the piece was written) had made a large number of changes.

I was astonished, amused and annoyed in turn: astonished that someone should take it upon themselves to make changes instead of simply asking for them to be made (especially when someone else was paying the bill); amused (and dismayed) at the stilted and disjointed result and annoyed that my client was subsequently told a ‘favour’ was owed because of the amount of ‘necessary’ work incurred.

I have no problem with people wanting changes to things I have written – this is normal in my world, and part of what I am (and was) paid to do. However, it would have taken seconds for my client’s customer to say, “It’s factually accurate, but I would prefer a more formal style” instead of the hours that apparently were spent ‘improving’ the vocabulary and sentence structure. The changes would have taken me much less time than they reportedly took my client’s customer – and they would have been seamless.

No accounting for taste!


04 January 2013

New year tech

I’ve just read an article on five technology developments that could rewire our world. It’s quite informative, but three of the predicted developments have massive implications for technical authors:

Self-driving cars
I believe that smarter devices often make the world accessible to people without the skills they would otherwise need. Once upon a time (yes, it really does seem that long ago!) computers were only really accessible to those with the ability to code and manipulate command prompts; in the modern world even keyboard skills aren’t that essential thanks to the nature of modern tablets. The same change happening in motor vehicles means that there is going to be a sea-change in the way that we categorise drivers and mechanics. Expect drivers to have far less knowledge of vehicles in future, whilst mechanics will need to further develop into gurus of GPS and guidance systems. The documentation provided to both groups will need to change accordingly, and somewhere an entirely new vocabulary will have to be developed to describe how self-drive cars operate (possibly by tagging the word ‘manual’ onto everything we currently do: “I manual-steer my car round corners and manual-brake for traffic lights”).
Flexible screens
As technical communicators, we still haven’t quite shifted away from the flat nature of paper in books and manuals, as screens are also flat. The issues for our field in terms of accessibility and re-skilling are massive when we consider that our output may be curved around the surface of a cylinder, or even a sphere... This doesn’t make our job impossible, but it may mean fundamentally reconsidering some of the givens in the field (e.g. “in European languages, the eye tracks from top left to bottom right” because on a round surface, there suddenly isn’t a top left and bottom right).
Augmented reality
This has been around for a while in science-fiction (one of the most interesting mentions was in Michael Chrighton’s Airframe) and video games (Batman: Arkham City amongst others) but is yet to make it mainstream. This is about to change and I think that augmented reality is going to be one of the biggest changes to hit technical communications in the next decade. Instead of writing so that an individual user is constantly looking from product to manual and back, we’ll be writing so that the user is seeing and hearing the information overlaid on the product they’re currently looking at.

So there we have it, not necessarily the big five, but the big three. Personally I’m quite looking forward to what the future holds.