Twitter revisited

Here is graph comparing the use of words in Twitter that are commonly associated with the field of technical communication.

Our DITA XML training course - Update

Carol is in the studio today, recording the audio track for the new, updated, version of our self-teach online course on DITA XML. She has to record 140(!) audio segments, which will take some time to complete. The development team will then match (within Abobe Captivate) these segments with the visuals and slides, ready, I think, for the final fettling and publishing stage.

Is Twitter a useful tool for technical authors?

A lot of people I know, it seems, are talking about Twitter. Quite a lot of these discussions seem to revolve around the question: is it actually useful?

At the moment, I'm not sure myself. I'm asking myself whether it's a useful tool for technical authors.

So what is Twitter?

Twitter describes itself as a Web site service for people "to communicate and stay connected" through the exchange of quick, frequent answers to one simple question: What are you doing?

In practice, it's also used to communicate with SMS-like messages and as a "RSS-lite" feed.

Why are people twittering about Twitter?

The Internet began with "One to Many" - Web sites that acted as online brochures. Web 2.0 offers "Many to Many" - social networks, YouTube etc. Twitter is seen as part of a new phase: "Many to one".

It's an idea of being able to follow a person's actions and thoughts; to create or be part of a following. That may sound cultish, but the purpose of doing this is to help us recognise patterns. By using Twitter, you may spot trends - people doing the same thing; people sharing the same goal or intention.

According to one commentator, "You can even read exactly what your contacts are reading and recommend you read too. Content in context."

Is Twitter actually useful for technical authors?

1. Twitter may be useful in understanding your users. You could follow your customers' thoughts and action through Twitter. However, this benefit may be more useful for the technical support, usability and marketing departments.

2. Twitter may be a useful way to track the people who set trends that you may follow In the future. These can be experts in their field, imaginative thinkers etc. People like Seth Godin or Dave Winer.

3. Twitter may generate more heat than light. I know of one person who receives one thousand Twitter updates on his mobile phone every hour! That's not content in context, in my book - it's information overload.

In summary, I'm not convinced. Twitter could be useful in a business context as a way of understanding users. It is certainly something to investigate.

PS

I've now created a Twitter account : www.twitter.com/ellispratt

Tracking - One function of twitter that could be useful is the ability to track topics. If anyone in the "twitterverse" posts an update about topic, you can get a notification. This could be a handy way to keep track of certain keywords that apply to you.

Announcing a Facebook club for technical authors

This week we received this email from a technical author:

"I've been using Facebook for a few months and find it a great way to communicate with old friends and people with similar interests. I would love to set up a Tech Author group so that Tech Authors can share ideas issues etc however I don't know any other tech authors so I'm not really in a position to set this up! I wondered if Cherryleaf could do something like this to get us authors in contact with one another."

This has lead us to create this technical authors club on Facebook.

A while back, we trialled an online club using Drupal, but we made the mistake of aiming too high. A forum is essentially what most people want, and this could be a good time to try again.

Confessions of a technical author - What can technical communicators learn from David Ogilvy?

David Ogilvy was an advertising genius who distilled his successful concepts and techniques into a bestselling book I’ve just finished reading, called "Confessions of an Advertising Man". I wanted to read his book, because I often find it useful to look at other professions and ask whether their ideas could be applied to the world of technical authoring.



So, can a technical authoring company learn any lessons from someone who ran a successful advertising agency? I think so.

The importance of testing, measuring and research

The biggest thing that struck me was Ogilvy’s belief in testing and research.

"The most important word in the vocabulary of advertising is TEST. Test your promise. Test your media. Test your headlines and your illustrations. Test the size of your advertisements. Test your frequency. Test your level of expenditure. Test your commercials. Never stop testing, and your advertising will never stop improving."

"People who ignore research are as dangerous as generals who ignore decodes of enemy signals."

In his early years, Ogilvy had worked for George Gallup Audience Research Institute, which he called “the luckiest break of my life.” To Ogilvy, what mattered were the results for clients, and he saw testing and research as critical to gaining those rewards.

Both technical communication and advertising find it very hard to measure the results of their work. However, advertisers and technical communicators draw different conclusions from this problem:

Advertisers believe that this means they should spend a great deal of time on testing and measuring.

Technical communicators believe this means they should spend little time on testing and measuring - it's too hard.

I think technical authors can learn from advertisers by spending more time on testing. For Web-based content, it’s possible to test and measure some aspects at least, such as the number of times a page is viewed. For this reason, perhaps documentation should be published in most cases on Web servers.

Creating an atmosphere in which partnerships with clients can flourish

Ogilvy "resigned his agency" from numerous accounts where he couldn't see he would be able to get results for his clients. Sometimes this was due to a lack of money available to spend on advertising, a duff product, or a lack of clarity from the client. Ogilvy aimed to take on just one new client per year. His goal was to work for giants such as Lever Brothers, Shell and Bristol-Myers.

The importance of using images

"Dr. Gallup reports that if you say something which you don't also illustrate, the viewer immediately forgets it."

Images are often left out of online Help files, in order to avoid confusing users with the application screens themselves. Maybe it’s time to reconsider this. Perhaps images could be used in a way that distinguishes them from the application.

Promoting the documents

"You can’t save souls in an empty church.”
Documents need to be seen and used, in order for them to work.

There were other statements that, with a few word changes, could easily have been said by a technical author:

1. On the average, five times as many people read the headline as read the body copy.
2. Golden rewards await he who has the brains to create a coherent image, and the stability to stick with it over a long period.
3. The most important decision is how to position your product.
4. A good advertisement is one which sells the product without drawing attention to itself.
5. We prefer the discipline of knowledge to the anarchy of ignorance. We pursue knowledge the way a pig pursues truffles.
6. It has taken more than a hundred scientists two years to find out how to make the product in question; I have been given thirty days... If I do my job well, I shall contribute as much as the hundred scientists to the success of this product.

It was an enjoyable book to read, which caused me to think about the way we work.

Issuu - A Web-based pdf viewer for technical authors?

Issuu is a Web site that allows you to upload magazines or newsletters and then view them as interactive, magazine-style online publications in your Web browser. It's a free service and has been described as a YouTube for magazines. There are a few manuals on it already.

The Issuu document is presented in a way that looks similar to a magazine. You can easily flip through it, using the arrow buttons, page numbers, the 'dock' below it, or the index.

Readers can comment on the documents, bookmark them, add authors to favourites or subscribe to them in a RSS newsreader.

Although it is geared towards glossy magazines, it could have uses for technical communicators. My initial thoughts are where you want readers to look and comment on a document, but you don't want them to download it, or where you want your document to look striking visually. The navigation isn't perfect, however.

Zen and the art of Help files

I've finally received my copy of Garr Reynolds' excellent book, "Presentation Zen". This book is about creating better, clearer presentations in a Zen-like frame of mind. If you have seen any of my presentations, then you'll know I prefer his photo-image style to the bullet point style that is more commonly used.

I would argue that "Presentation Zen" contains ideas that are also relevant to technical communication.



So how can the approach espoused by Garr Reynolds be applied to the online Help and the user manuals that technical authors create?

He proposes presenters connect with the audience to inform in a meaningful, unique moment in time. His philosophy includes these beliefs:

- Prepare with three words in mind: simplicity, clarity and brevity.
- Simplicity leads to clarity and can be obtained by reducing to the nonessential.
- Target both the readers' creative and logical sides of their brain.
- Start with the beginner's mind.
- Ask the right questions.
- See the big picture.
- Design and layout are important.
- People remember visuals better than lists.



I believe most online Help (that has been developed by a professional technical author) has most of those boxes ticked. However, I think there are some areas of Garr's ethos that are often missing from user documentation:

1. The "art of being completely present" when delivering the content. The last thing on a user's mind when they call up Help or read a user manual is a Zen-like state of mind! The way in which Help is normally delivered to the user is frankly weak - requiring them to press F1 and admit failure.

2. Targeting the reader's creative side of their brain. The technical author's content is nearly always logical. It's rare, too rare perhaps, to have content that encourages play or experimentation. Manuals rarely reveal any passion in the writer.

3. Seeing "the big picture". I think technical authors do see the big picture, but sometimes miss out on explaining the big picture. Perhaps there's a pressure to dive into the nitty gritty of describing tasks? There's clearly a need from users to understand the big picture. I know someonewho makes a tidy living "explaining anything in less than ten minutes". He does this on paper, within the confines of an A3 poster.

I recommend technical authors take a look at this book and consider whether they could apply these ideas to their work.

Quote of the month

We've just received this nice testimonial from a client:

"I had some basic instructions for my new online application, Opportunity Matrix™, but absolutely no idea how to turn them into a proper help system. Carol at Cherryleaf was able to take my rough notes and turn them into a professional Help file.

She worked through the application, suggesting appropriate changes where I was making assumptions that would have left users confused. Once we were both happy with the file, Carol liaised very effectively with the programmer to make sure that the Help system worked perfectly right from the start.

The information and guidance from Cherryleaf was always top notch, so I always knew exactly where the project was, and what the (quite reasonable) budget needed to be. I shall have no hesitation in using Cherryleaf again, and in recommending them."



Andrew Horder, CEO, Opportunity Matrix™.

Why does this project manager have so many lines on his face?

Notice the man's wrinkles. What have past software development projects done to him?

Maybe this time it will be different.

Maybe this time he can sleep knowing the users will get the documentation they expect. Because maybe this time he'll use a technical author.

Cherryleaf works with developers of software helping them ensure they have the technical authoring resource available to give their users the user assistance they really need. Whether you need either a managed or unmanaged resource, then the people to call are Cherryleaf.

Call us on 01784 258672.

------------
(Testing a new advert)