atw: Re: Media and preference: the unravelling thread

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
________________________________
From: austechwriter-bounce@xxxxxxxxxxxxx [austechwriter-bounce@xxxxxxxxxxxxx] 
On Behalf Of Geoffrey Marnell [geoffrey@xxxxxxxxxxxxxx]
Sent: Thursday, 12 March 2009 7:45 AM
To: austechwriter@xxxxxxxxxxxxx
Subject: atw: Media and preference: the unravelling thread

Hello austechies,

A good dinner-party conversation starts at A and moves through the alphabet; a 
good argument shouldn’t. So let me clarify what my point was and what is wasn’t.

It was not an argument about language
Language is, and has always been, in flux. Some usage that many of us were 
taught in primary school as wrong is now quite conventional: that is, it is 
accepted by the majority and passes unremarked. Like it or not, some (but 
certainly not all) the language practices of today’s younger folk will make it 
into conventional language at some time, and at that time, technical writers 
will adopt that usage. Yes, we write for our audiences, and if we want to 
maximise the efficacy of our communication, we don’t (and won’t) write in ways 
that users will find quaint, artificial, archaic or stilted, even if at some 
time those ways were conventional, expected, and considered by many to be 
correct, right and inviolable.

But I was not suggesting we distance ourselves from the language of younger 
folk (or of any group).

It was not an argument about paper versus online
Yes, I used the paper versus online issue in my initial posting. But that was 
simply to provide some concreteness to the argument (and also because it was 
the only relevant, media-specific scientific research I have been able to find 
on the issue of media choice). But to focus on this issue is to be distracted 
by the trees in the forest and not to see the forest. Perhaps presenting the 
argument in abstract logical notation might have prevented this particular 
side-thread ;-).

It was an argument about media choice and reader preferences
In abstract form, here is what I was getting at: if medium A (whatever that 
might be) is better at communicating information (however judged: by 
comprehension tests, performance success, learning outcomes or whatever) than 
medium B (whatever that might be), should this be a consideration that 
overrides widespread reader preference for medium B in some situations? I 
thought so, and gave cases where death and injury are possible as ones where 
user preferences should play second fiddle.

Some considered this conclusion unexceptional, and I was glad to hear that. I 
was hoping that most technical writers would find it so. But Tony’s argument in 
his Southern Communicator article suggested that reader preferences should take 
priority, and his claim, in a subsequent posting to this thread, that readers 
should be king seems to back up this interpretation.

But the argument remains largely theoretical until we have some rigorous way of 
determining that one medium “is better at communicating information” than 
another. And that was the point of my second question (also lost in the trees, 
to some). A lot more research needs to be done on this. And it goes both ways. 
Note that I didn’t ask what has Tony done to prove that wikis, podcasts, 
mash-ups or whatever are better at communicating than user guides and online 
help. I asked what has our profession done to establish scientifically rigorous 
ways for determining that one medium is more efficacious in such and such 
circumstances than another. Cognitive psychologists have produced numerous 
studies to show that paper is superior to online in comprehension testing. This 
is only a start for us. It gives us a bare minimum to go on. In order to avoid 
outright subjectivity in our choice of media (if communicative efficiency, 
rather than secondary issues such as cost or ease of maintenance are primary) 
we need some criteria for assessing the relative merits of all the media at our 
disposal. And the onus falls on all of us, not just on Tony. Readers of Tony’s 
article might conclude that he has to prove to us the benefits of a wiki (or 
whatever) over, say, standard online help. But the argument goes both ways. 
Those who think that standard online help provides more effective communication 
than a wiki (as I do) need to prove the point. The problem is that there is 
scant research available to inform our decisions.

Topics anew
Tony’s paper is rich in discussion points. Here is one: let’s suppose (for the 
sake of argument) that many users don’t read product documentation. (Tony says 
that no-one does, but this is clearly an exaggeration.)  Do they not read 
product documentation because of the media we use to present it to them (which 
seems to be Tony’s point)? Or do they not read product documentation because 
it’s product documentation? Many of us, on buying, say, a new mobile phone, 
start playing with it straight away, without consulting the accompanying 
documentation. And many of us are satisfied with the features we discover for 
ourselves, and never encounter or play with the less obvious features (features 
described in the product documentation). Will such folk start consulting 
product documentation if it were delivered in other media (a wiki, podcast, 
YouTube movie, or whatever)? Or will they continue doing what they have usually 
done: learn by doing. So perhaps the issue is not the medium but the sort of 
information the medium contains.

Cheers

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


---------------------------------------------------------------------
CONFIDENTIALITY NOTE: Please consider our environment before printing this
email.This email and any attachments are confidential and may be subject to
copyright, legal or some other professional privilege. They are intended solely
for the attention and use of the named addressee(s). They may only be copied,
distributed or disclosed with the consent of the copyright owner. If you have
received this email by mistake or by breach of the confidentiality clause,
please notify the sender immediately by return email and delete or destroy all
copies of the email. Any confidentiality, privilege or copyright is not waived
or lost because this email has been sent to you by mistake.
---------------------------------------------------------------------

Other related posts: