atw: Re: Media and preference: the unravelling thread

Hi Geoff

I have an advantage in having my notes from the 2007 TCANZ conference you 
mentioned, and I didn't say that I thought Wikis were about to put technical 
writers out of work. I said that Wikis should give us reason to think about 
where we would fit in should peer-generated, collaboratively authoring become 
widespread. I also made the point that document delivery is only one use for 
Wikis; a collaborative authoring tool is another. Microsoft used Wikis during 
the development of their Visual Studio documentation, and then transformed that 
content into "traditional" help files. There are also tools around that allow 
you to convert Wiki-generated content into RoboHelp projects.

I'm not sure that Wikis should be described as a medium. Most Wikis are 
delivered through stock-standard, HTML-based Web pages, just as many Help 
systems are. (Visual Studio users are blissfully unaware that Wikis were used 
in the documentation process.) Wikis would more accurately fit into an 
authoring tool category, or perhaps into a content management category. We need 
to draw a distinction also between customer-generated content (bottom up, 
democratic), and vendor-generated content (top down, autocratic). Wikis can be 
either.

If a group of senior Boeing 747 pilots used a Wiki to collect their knowledge 
and experience on how to fly a Boeing 747, surely the result would be as 
trustworthy (if not more so) as a pilot's manual written by a senior pilot 
using Microsoft Word? A problem may exist if the Wiki was not restricted to 
senior pilots working on the documentation project, but was opened up so that 
anyone in the world could contribute. Nearly all Wiki software that I have 
looked at has permissions built in, because this is an almost universal 
requirement. 

Provided there is a critical mass of interested contributors, user-generated or 
customer generated (ie, peer-generated) content is peer-reviewed by its very 
nature. 

I am not saying there are no problems with peer-generated content and 
customer-generated content. Many companies and organisations have found ways to 
solve many of these problems. I'm not even advocating the use of Wikis, let 
alone suggesting that public Wikis should be used to create nuclear power 
station manuals. I am humbly suggesting that we start thinking how we, as 
technical communicators, confront the challenges of Wikis and other forms of 
peer-generated content.

Finally, on the question of trust. In late 2009, Forrester research released 
results from a survey on how much consumers trust different sources for 
information. They found independent (non-corporate) information were the most 
trustworthy sources. Interestingly, the survey showed that only 16% of 
consumers trusted corporate blogs and only 33% trusted wikis (such as 
Wikipedia). 

Tony Self



>>> "Geoffrey Marnell" <geoffrey@xxxxxxxxxxxxxx> 12/03/2009 11:57 am >>>
Tony, was the problem you encountered a problem with the media (the printed
instructions, the Apple online help)? Or a problem with the cpontent of that
media (namely that it was inadequate). Yes, having crap instructions may
have saved Apple the technical writing costs, but the issue has been one of
communicative efficiency, not costs. If it was just down to costs, our
profession would have died out years ago.

You were lucky you found some documentation you found useful, but the fact
that it was user-generated is no reason to think that wikis are about to put
technical writers out of work, as you suggested in your talk to the TCANZ
conference in 2007. Nor is it a strong reason for abandoning any particular
medium in favour of wikis.

Let me ask some questions I asked in my article on wikis in Southern
Communicator last year. Would you trust user-generated documentation on how
to safely fly a Boeing 747? How to run a nuclear power plant? How to use a
dialysis machine? Further, would there be enough (or any) user-produced
documentation on how to use a steam iron? A bookkeeping application?. A
calculator? And who accepts responsibiltity if someone injures themselves as
a result of following some poorly-written, non-peer-reviewed user-generated
instructions? Would you accept any responsibility for injury,
misinformation, lost productivity and the like resulting from a wiki a
client set up on your advice?

But let's get back to the point: should you judge a medium by the quality of
the information presented in that medium?


Cheers

 
Geoffrey Marnell
Principal Consultant
Abelard Consulting Pty Ltd
T: +61 3 9596 3456
F: +61 3 9596 3625
W: www.abelard.com.au 

-----Original Message-----
From: austechwriter-bounce@xxxxxxxxxxxxx 
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Anthony Self
Sent: Thursday, March 12, 2009 11:28 AM
To: austechwriter@xxxxxxxxxxxxx 
Subject: atw: Re: Media and preference: the unravelling thread

Hi Nikki

I agree with you. I needed to reset an Apple iPod Nano. I tried the "manual"
(I think it was a single folded piece of paper), but the information wasn't
there. I tried the Apple site, but I couldn't (easily) understand the
instructions. (They used names for the buttons I needed to press, but the
buttons weren't labelled on the device.) I Googled, and found a 30 second
YouTube video explaining exactly how to do it. The video made it very clear
how to reset the thing in one viewing, and I successfully reset the iPod.
Then I noticed there were 60 other similar videos. All were contributed by
generous iPod users. Some, such as
http://www.youtube.com/watch?v=-XvCguAzvmk, have even got a music
soundtrack, which makes following the instructions enjoyable. (Not sure
about the copyright implications for the creator of the video, though.) One
of the videos has had over 250,000 viewings. 

It was a win for me as a user. It was a (financial) win for Apple, because
they didn't have to pay a technical communicator to write/create a clear
instruction, and pay to distribute it. It was not a win for the technical
communication profession. 

Tony


>>> "Nikki Ward" <nikki.ward@xxxxxxxxxxxxxx> 12/03/2009 9:56 am >>>
Geoffrey, just on the point about product documentation. I think this
largely depends on prior knowledge of a product. Most people have had prior
exposure to how a mobile works, and also realise that it simply takes time
to play around with its features, experimentation and so on. This is half
the fun when it comes to getting a new communication toy.   I personally
only consult the manual if I am frustrated at not being able to figure
something out. Personally I would prefer a batch of video how-tos so that I
am in control of what I want to know instead of trawling through one-stop
shop, one-size-fits-all mobile how to manual.

In this instance, I determine my own level of knowledge not the author of
the product documentation. I think the fundamental misconception is that the
mobile manual must be written to cover ALL aspects. The mobile manual best
suits U-Tube style online video clips of how-to's with the opportunity to
download PDF file transcripts and if necessary, the entire product manual.
From the documentor's point of view, this means more work, from the user's
point of view, this means determining their own level of knowledge, from the
Company Director's point of view, this means additional cost. These are the
considerations that must be taken into account. That said, if the business
views its customer uptake as a necessary part of promoting brand loyalty
then the expenditure is justified.

I think in all our considerations, these factors must determine what output
we will use to communicate with our readers/customers. At the end of the
day, what is the communication really about?... Safety? User Adoption?
Profit?

Sadly, the $ factor is the main determinant.

Nikki


**************************************************
To view the austechwriter archives, go to
www.freelists.org/archives/austechwriter 

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with
"unsubscribe" in the Subject field (without quotes).

To manage your subscription (e.g., set and unset DIGEST and VACATION modes)
go to www.freelists.org/list/austechwriter 

To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx 
**************************************************


**************************************************
To view the austechwriter archives, go to 
www.freelists.org/archives/austechwriter 

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with 
"unsubscribe" in the Subject field (without quotes).

To manage your subscription (e.g., set and unset DIGEST and VACATION modes) go 
to www.freelists.org/list/austechwriter 

To contact the list administrator, send a message to 
austechwriter-admins@xxxxxxxxxxxxx 
**************************************************
**************************************************
To view the austechwriter archives, go to 
www.freelists.org/archives/austechwriter

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with 
"unsubscribe" in the Subject field (without quotes).

To manage your subscription (e.g., set and unset DIGEST and VACATION modes) go 
to www.freelists.org/list/austechwriter

To contact the list administrator, send a message to 
austechwriter-admins@xxxxxxxxxxxxx
**************************************************

Other related posts: