It's been years since I got drunk enough to think
of something like this...

Gene Kim-Eng

----- Original Message -----
From: "Ned Bedinger" edwordsmith.com>

Rory Blyth presents the minutes of a staff meeting in cartoon form. The
meeting attendees set out to discover how to share data between MS
Office Apps :-)

Their solution is not the one you would think of. OR IS IT?!

http://www.neopoleon.com/blog/posts/434.aspx

Have fun,

nb

If a large manual is poorly structured, poorly organized and doesn't have a
decent table of contents and index, then you're right... the user's would
have to wade through a lot of stuff to find what they need. However a
well-done manual makes it easy for the user to find the information he/she
needs.

You seem to have little respect for the users and believe they must be
innately timid, passive and dependent, yet you advocate that they learn how
to use products by exploring and experimentation? I don't want to waste
their time. I want them to be able to use the product and if they have a
question I want them to be able to look it up quickly and get back to work,
not get off on some experimental tangent.

I don't create thorough documentation because I want to cover my ass or to
keep myself busy... I create it because I want the users to have everything
they need to use the product with as little inconvenience as possible. I
have no patience for time wasters and CYA approaches.

Do a little experiment for me...

Start up Microsoft Word, choose the Tools>>Options menu item, then click the
Compatibility tab. Scroll down the list and explain to me the differences
between "Suppress extra line spacing at top of page"...

When we started doing task-based documentation rather than just
documenting every feature, button, etc., the question usually came up
"What if you document all the tasks and you still haven't covered every
feature?". All you good techwriters know the answer to that, but the
developers were shocked to learn that if every possible task has been
documented and some UI items or features weren't mentioned, by golly
then maybe they're redundant / unnecessary features! Those conversations
were always a lot of fun -- for me, anyway. I'm with you, Gordon, I'd
argue the case. If it's in the product, and it's something users need,
it should be in the doc.

Gordon McLean wrote:

Thanks to those who replied for the information. It was helpful and
appreciated.

Brian

(I'm hoping this reply ends up in the right place...)

As Melissa Nelson and others have pointed out, "this is a 'know your
audience' type thing." However I would carry that one step further -it
is also a "know your purpose" type thing.

Technical documentation does not have to be a dry presentation of what
every field, function, or menu item does unless that is the purpose of
that documentation. Just as one writes for different audiences, one
should also write for different purposes. Is the document meant to be
informative or instructional? (Yes, there is a difference.) If it is
instructional, how can one document a function or feature without tying
it back to the specific process for which that feature, function or
button was designed? If that is the case, why would you document
buttons, icons, etc. that have nothing to do with that individual
process? You wouldn't. Therefore, I would suggest that both audience and
purpose be the guide, not just audience alone.

--- Joyce Fetterman gtsoftware.com> wrote:

were portable, inexpensive, readily available, and they worked!

They also survive hard-drive crashes.

You need to find out whether the customer support manager's
statement that he had final approval of the release notes is
official or just his opinion. If it is official, than "as far as you
are concerned" is irrelevant, and and if they and the product
managers disagree you (or your manager) need to get them
together so they can duke it out. If one of these people *is*
your manager, that person needs to grow a spine, take on the
other and get him off your back.

Gene Kim-Eng

----- Original Message -----
From: "Carrie Baker" gmail.com>

WritersUA is a very good conference. It's held in Long Beach, CA,
this year March 25 - 28.

http://www.winwriters.com/ohc07/

Looks like there are 5 sessions on single sourcing and 6 on XML.
It's 3 days (with an optional day on Sunday) packed full of
concurrent sessions, an opening panel discussion, and a closing
keynote. There's bound to be something of interest to you each
session.

2 cents,

Dana W.

***************************
Dana Worley
Software Product Manager/Manager, Software Support Group
Campbell Scientific, Inc.
Microsoft MVP, Windows Help

Hey Gang!

To follow up on Geoff Hart's comments about working from home, I would
LOVE to work from home, but no matter how much business talks-the-talk,
they refuse to walk-the-walk (to lift an overused phrase from the
asinine O.J. Simpson trail of the 1990s).

So how does one secure an at-home tech writing contract job for a client
far too far to actually meet with? Occasional visits onsite at client's
expense are just fine, though.

With a wife securely entrenched in her job with 19 years as a
transportation engineer at a firm here in metro Atlanta (a great thing
to be in this city!), and two middle-school-age kids in a pretty good
school district (very uncommon for this state), relocation is not an
option.

I myself have over 22 years documenting everything from computer
accessories (2 years), to factory equipment (12 years), to heavy
earth-moving equipment & forklift trucks (7 years), to cement
manufacturing plant design and startup (now over just 1 year). Plus 10
years before that in other journalistic positions.)