What Satellite Navigation can learn from Technical Communications
These days nearly everyone I know with a car has a Satellite Navigation device. As a communication device they work reasonably well. Their visual instructions are very clear although the audio could be improved. In my experience the audio instructions fail when it comes to even slightly complicated scenarios. For example when on a roundabout (I think these are called traffic circles in the US) with two left hand exists side by side. In such instances “Turn left” is of little use and requires a look at the visual instruction at the same time as ensuring the white van man doesn’t cut you up!
The inadequacy of Satellite Navigation devices was reinforced recently when I was sent a joke email. In it were the following statements:
- The map really needs to start its directions on step 5 as I’m pretty sure I know how to get out of my neighbourhood.
- I wish they had an “Avoid Ghetto” routing option.
This got me thinking of what Technical Writers provide and whether the Satellite Navigation device wish list logic had any relevance in what we deliver. After all, the skills of the technical communicator include designing a structure that allows for where someone is, what they already know and where they are trying to get to. So to apply the logic to technical documentation…
Starting at Step 5
This is potentially perfectly acceptable, although it all depends on your audience. For example, would you tell a Secretary to open up Microsoft Word (or even turn on their PC) in order to type a letter? If you don’t, it assumes the user already knows steps 1 to 4 off by heart. The trouble is, this may not always be the case. Take another example, I bet you know how to operate the indicators on your car. Therefore instructions arguably don’t need to mention the relevant lever, just “Indicate left / right.” Now get into a hire car at the airport and watch the windscreen wipers go into action each time you want to turn a corner.
Getting back to the Satellite Navigation device, a potential solution for this scenario would be to start your procedural steps with something like “Proceed to Acacia Avenue” with a mechanism to display how to do so if you are not sure of how to do so.
Avoid the Ghetto
This one may be slightly more difficult and controversial. My Satellite Navigation device offers the options for taking the fastest or shortest route as well as others to avoid motorways or take a walking route. All great except that you don’t know what the shortest route is in advance. Maybe it leads you directly into that bottleneck by the Shopping Centre just as the school down the road kicks out its 1500 pupils onto the street.
In technical communication terms I’d see the solution to this problem as listing the different options, but explaining the implications of each one. Users can then make an informed choice of which way to go. For example, opening a file in Microsoft Word can be performed any number of ways, some of which do not even require the application to be open. If you describe double clicking a file in Windows Explorer, you could explain that the file is opened and that any other Microsoft Word file already open remains intact in another window. In the applications that I document, there are more technical issues related to how you do something. There are different ways of performing an action, but if users want to perform another action further down the line, they have to have performed the first action in a specific way. Our solution to this is to provide “best practice” tips to explain the best way to avoid a particular pitfall.
Once again getting back to the Satellite Navigation device, the “avoid the ghetto” option could be provided by listing the summary directions after the destination has been specified with the option to accept or divert from them where required. No doubt I can expect a job offer from Tom Tom or Garmin any day now!
Should this be added to the HAT Matrix?
I just couldn’t resist posting one of the requirements for a job post I have just received. Rabid RoboHelpers need not apply 
“I am looking for candidates that have experience of working as a Technical Writer especially with the documentation software MadDog Flare”
2010: Accolades, interactive docs & a death threat
As the dawn of 2010 disappears behind the late December dusk, I feel a retrospective look at what has come to pass is required. Call it being lazy if you will, although personally I’d disagree. It’s definitely not that I can’t think of anything else to blog about (you should see my “To blog about” list) it genuinely is that a lot has happened this year, including:
• Completing two major documentation projects to great acclaim.
• Increased exposure in the technical communication industry, particularly in Adobe circles.
• Blogging related accolades.
2010 started with delivery of a large rewrite of one of the company’s flagship product suites. The year long project involved a bottom up, top down and side to side revisiting of what we provided. As well as the design and look and feel, we focused on ensuring the deliverables had the correct generic information for the entire user base, together with specific use case examples. This was vital for an application that crosses different job functions.
For the first time we used simulations inside the help file to add some interaction and support the existing text. Critically we chose not to replace the help text with simulations, but use them only where they would add value (e.g. areas where the applications interface was a little ambiguous). The toil was well worthwhile as user feedback was very encouraging. Even one user known for his negativity sang our praises!
The results and feedback from this project were to figure several times throughout the year, largely as a result of my use of social media. This blog had been active since early 2009 and had built up a select subscriber base without reaching a massive audience. All of that was changed once I embraced sites like Twitter, LinkedIn and Facebook more strategically. In fact my online presence delivered many opportunities to both me and my company as the year wore on. A reason why all Technical Writers should start using (at least) Twitter.
First up came an offer from Adobe to produce a Use Case Study with their Marketing Department. As part of the documentation rewrite project we had implemented, we embraced the integration between the products in the Adobe Technical Communication Suite 2. We’d been Adobe RoboHelp users for a while and had used Adobe FrameMaker on occasions for specific deliverables, but had not used Adobe Captivate. The level of integration between the three applications, and the generous upgrade options, made the purchase of several suite licenses a no brainer. Additionally we had successfully implemented the Adobe RoboHelp Server 8 feedback analytics application, and were starting to reap the benefits of the statistics it provided. The experience of producing the use case study was an interesting one, not least because of the need to moderate some of the claims made in the initial copy! With the Marketing Department producing the copy following an initial conference call, the style of writing was very different to that used to write software help files. Still it was a worthwhile exercise which brought the company some free marketing.
Around the same time I started getting noticed inside the technical communications industry. I maintained an online presence with my peers and kept in touch with industry trends. I don’t spend much time on online, preferring to dip in and out when I have a few seconds. The TweetDeck Twitter client is an excellent way of allowing me to do this whilst focusing on keywords and users. Add to that, 15 minutes at home reviewing LinkedIn groups and my Facebook wall and that’s it. It need not take a lot of effort to do likewise. Invitations followed to write guest posts on various blogs. Wordtree Consulting, Concise Documentation and DMN Communications all saw the fruits of my craft. Alongside these brushes with minor celebrity I had three articles published in Communicator, the journal of the Institute of Scientific and Technical Communicators journal (ISTC).
In September I was invited to deliver a talk at the Technical Communications UK Conference in Oxford. Another opportunity that came my way via Adobe, this was a chance to tell the faithful about our use of the Technical Communication Suite 2 and RoboHelp Server 8. The three day conference was well organized, full of interesting / varied speakers and excellent value for money. It was also a great opportunity to network amongst fellow technical communicators, put faces to names and meet virtual friends in the flesh. I’d highly recommend any technical communicator to attend.
As the year came to a close, yet another big documentation project was delivered. The success of the last big project raised the bar to what was an acceptable deliverable. Plain text and occasional screen grabs were complimented with yet more simulations to support the text. We also threw in some example use case files that can be downloaded and imported into the application. Now you had a level of user assistance never seen before in our documentation. This brought the Technical Documentation team some welcome attention from other departments. It may not be rocket science to anyone reading this, but people started asking what we could do for them. Where do I start? I have a long list of things to get stuck into in 2011.
Away from the day job I managed to fit in a bit of contract work. Not much, but enough to fill in the odd few hours! Mostly this fell into my lap through my industry contacts. I’m not looking to move from my job but it helps to keep the iron in the fire in case circumstances change. The RoboColum(n) has gone from strength to strength with a loyal following and more regular interaction with subscribers. In the summer it was given the accolade by Mindtouch of being amongst the 25 most influencing technical communication blogs. Although you can pick through the metrics used, it was a major honor, especially as there were only 5 bloggers in the 25 from the UK. My aim now is to better my 15th position and reach the top ten in 2011. I’ve even found time to once again join the beta test team for Adobe RoboHelp 9 and Adobe Technical Communication Suite 3. However don’t ask me about a release date as a) I honestly don’t know b) can’t tell you even if I did c) would have to kill you if I digressed .
So 2010 ends and 2011 starts. As our Managing Director told his top Salesman last week, “You may well be top dog this year but come January 1st you are back equal with the others.” I am truly grateful for all the opportunities and success that has come my way in 2010, but I am not complacent to what still needs to be achieved. There is a long way to go, but this is a sound platform with which to greet the New Year.
It has been a lot of fun and I hope you stick around for the ride. May I wish all my readers a very peaceful and joyous 2011.
Bulls, cats and festive spirit
In this time of seasonal good will to all, our team has played its part. We have decided to stop ranting. Actually to be more precise, we have stopped awarding the Rant Bull to those among us whose rants justify just such an accolade. The Rant Bull “trophy” has graced the presence of most team member’s desk since it was inaugurated two years ago. Whether a rant merits the bull is a very arbitrary process based on an ever moving set of criteria. In fact on occasions the process is downright corrupt! The only rule is that solely uttering expletives does not constitute a rant. We don’t necessarily need a full blown rant either. Just going on about something a little too much could qualify.
You can rant on any subject and team members often do. Previous winners have received the bull for moaning about the bus driver not allowing them to take a coffee on board, what their cats get up to (or don’t get up to) at home and, a little perversely, not having won the Rant Bull for awhile. However one topic is head and shoulders above anything else: software usage. As users of Adobe software, this company’s’ applications feature heavily as does Microsoft and the scientific research applications our company produces! It’s all a bit of light hearted fun designed to relieve some of the pressure and frustration of working for a living.
Statler and Wardorf would be proud of us. Now if you don’t mind I have a reputation to maintain (see below) and as there’s an amnesty…
Merry Christmas!
UPDATE:
I am pleased to report that the be benign dictatorship that governs whether something is a rant or not (i.e. my boss) has decided on an amnesty and expunged all rants from last year. Rumours that my first rant of the new year was seconds after this gallant action are wide of the mark. For the record it wasn’t a rant and I don’t think commenting about winning the rant count from last year counts!
Does a job advert have to be well written?
I remember a conversation I had with a particular Recruitment Consultant when I was looking for my current job. Having sent him my CV he commented on how clear and easy to read it was. This was welcome praise, but I surprised him when I said that as a Technical Writer it should be! He was surprised not because of what I’d said, but because he realised how few people applying for Technical Writers jobs knew how to market their skill set in their CV.
It can work both ways of course. Would I have applied for my current job if it had been badly marketed? Definitely not! It was therefore with absolute horror that I saw this job advertisement. Why any sane Technical Writer would even consider applying for such a position is beyond me. Quite apart from the plethora of grammatical and spelling errors, the employer seems to want someone with a completely different skill set from any Technical Writer I know. What do you think?
