atw: Re: Media and preference: the unravelling thread

Thanks for the clarification Tony. But looking back at the slides that
accompanied your TCANZ presentation, I see that you were suggesting that
there would be a change "in role" for techncial writers. You also suggested
that if collaborative authoring takes off, "users become authors ... and
authors become content editors? Moderators? Deleters?". 

Be that as it may, it sems that we both agree that user-generated
documentation won't be all that widespread. Your qualification that you need
"a critical mass of interested contributors" to make user-generated
documentation work is important. It means that much of what technical
writers write about (being boring, humdrum, every-day products) will fall
outside the net of wikis, and thus we will be saved from being mere content
profiders, moderators or deleters.

I'm not sure Boeing would be pleased with your suggestion. If there were no
operating instructions before the senior Boeing pilots started to fly the
planes (which they presumably need to do before they could collaboratively
write their operating instructions) then we have to ask: how many crashed
planes and deaths would Boeing put up with before the pulled the plug on
this brave new user-generated experiment?

The stats on trust are sort of encouraging. Only 33% put their trust in the
acuracy of wikis. Good news? Or do we ask why do so many people trust them
when there are plenty of reasons not to. You say that wikis are
peer-reviewed by users. But a peer reviewer has to have some knowledge of
the domain. The original Wikipedia model of allowing everyone and anyone to
edit content is a failure because you just don't want everyone to be able to
add, change and delete content. So, in so far as a wiki has the right
permissions and a qualified reviewing team, then fine. But we are starting
to move away from the view that bottom-up documnetation is better than
top-down documentation. If only certain qualified people are allowed to
write and review the documentation, how different is that to documentation
development of the sort engaged in by traditional technical writing teams?

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 4:31 PM
To: austechwriter@xxxxxxxxxxxxx
Subject: 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
**************************************************


**************************************************
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: