Narrative Technical Writing

Subject: Narrative Technical Writing
From: "Janoff, Steve" <Steve -dot- Janoff2 -at- Teradata -dot- com>
To: "Chris Despopoulos" <despopoulos_chriss -at- yahoo -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Mon, 2 Nov 2009 23:00:17 -0500

Hi Chris,

Yes, I jumped ahead, so apologies for that.

But here are some random thoughts:

Minimalism and DITA are based on the task. If we weren't writing
task-oriented "how-to" content, what would we be doing?

And by the way, the way I meant what I said ("our role largely makes
procedures obsolete") is in the spirit of your point that we don't have
to drill down nearly as far in writing task-oriented material. So maybe
very brief, high-level task instructions. A simple 1-2-3 without much
detail.

The trend is away from writing conceptual material. And reference
material is often just thrown together into tables and such.

The little I've poked around in tech writing history suggests that
writing was a way to memorialize things that had formerly been handed
down through oral tradition -- similar to how scribing and then printing
memorialized the Iliad and Odyssey, the Bible, and other great texts.
But this time, the focus was scientific and technical information.
Things became too complex to hand down by a journeyman teaching an
apprentice.

A lot of us document software GUIs. One of the big points you've been
making is how much detail is needed anymore, regarding how to operate a
GUI. Very little, really.

Another thing: Have you ever noticed that one of the easiest ways to
learn how to use a new tool is to have someone on the team who's
familiar with it sit down and show you a couple shortcuts? Within
seconds, you're up and running. Okay, that's not going to get you very
far with something really complex, but it's great for simple
productivity tools.

So the oral tradition continues, in a way.

Years ago somebody told me that John McPhee had been a technical writer
(I can't find any support for that on the web, though). I only read a
little of his nonfiction but it seemed really nice. I guess I sort of
yearn for the days -- if they ever existed -- when you could really take
your time and write something that really moved a reader at the same
time it educated them. The goal of technical writing in those days (or
those imaginary days) was to educate and inform, and to some degree
create an aesthetic experience. But of course, nowadays that would be
considered way too narrative, not to mention prohibitively expensive.

So we're not really writers in the traditional sense.

Okay, so maybe one has to look for a more recreational kind of technical
writing to read, just for enjoyment. Like Thoreau or someone like that.

Meantime, if anyone has come across any such texts like that, that are
really enjoyable to read and are considered examples of technical
writing, I think they'd be worth checking out, and would be grateful for
a reference to them.

TIA, and as for this thread, maybe I'm just yearning for something
that's not commercially feasible in today's world, and as I say, may
never have been.

PS - Of course, this kind of narrative writing for leisurely
reading/learning is the *opposite* of minimalism! I mean, some of us
write these long posts -- are we not frustrated narrative writers? :)

PPS - By the way, just to kick this off, I don't cook, but I'll bet
there are some wonderful old-timey cookbooks that get into this sort of
leisurely technical exposition of how to create wonderful meals that
make your mouth water just reading about them.

-Steve


-----Original Message-----
From: techwr-l-bounces+steve -dot- janoff2=teradata -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+steve -dot- janoff2=teradata -dot- com -at- lists -dot- techwr-l -dot- com]
On Behalf Of Chris Despopoulos
Sent: Monday, November 02, 2009 8:26 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: TECHWR-L Digest, Vol 48, Issue 27

Hi Steve...

I hope I'm not saying that procedures are obsolete or that we have no
use for them in our writing. What I want to say is that we have to
reconsider what it is we call a viable procedure. Robert Lauriston says
it all... He finds lots of docs that tell him what he could have
figured out on his own. Obviously, the docs were not aimed at him. If
he's the typical user, then the docs are a waste of money to the degree
that they took time and effort to explain the obvious.

I think writers are qualified to serve as user advocates. Also,
stepping through the system and making narrative sense out of it is a
good check to see whether the design works.

Hi-tech product delivery is an information management problem, and it's
done by teams of information professionals. The spectrum of information
management is broad, including customer input, product definition,
design, code implementation, build management, bug management, tech
support, budgeting... And yes, documentation. As tech writers, we're
information management professionals. In that role we're qualified to
contribute lots and lots... Not all of it limited to the production of
pages. Thankfully, modern product development methodologies recognize
this.

cud
**************************


Hey Chris,

Your post inspires me to want to delve into the origins and history of
tech writing.

It seems odd that tech writing has evolved from probably a simple
beginning of written communication to the point where the writer is now
intimately involved with user experience design. That's not a bad
thing, it's just curious.

What qualifies a writer to perform this role? Is he/she the advocate of
the ordinary person? Is the writer somehow more "human" than the
developer, and therefore able to talk to the user in that person's
cognitive language?

I remember the days when you had to fight to get a word change into the
UI -- writers were not allowed to contribute in any way to the
interface, even from a language standpoint.

Now our ideas are welcomed, even solicited, regarding functionality,
user experience, usability, interaction design, navigation design,
screen layout, information architecture, and the rest of it.

Innovators aren't always good writers, and writers aren't always good
innovators. If our role largely makes procedures obsolete, then what
*is* our role?

Meantime, have a great weekend, all! :)

Steve
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you looking for one documentation tool that does it all?&#160; Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at:
http://www.doctohelp.com/

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/ for more resources and info.

Please move off-topic discussions to the Chat list, at:
http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat


Follow-Ups:

References:
Re: TECHWR-L Digest, Vol 48, Issue 27: From: Chris Despopoulos

Previous by Author: Serial Comma Redux
Next by Author: RE: Narrative Technical Writing
Previous by Thread: Re: TECHWR-L Digest, Vol 48, Issue 27
Next by Thread: Re: Narrative Technical Writing


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads