Re: Metrics in its own thread

Subject: Re: Metrics in its own thread
From: Keith Hood <klhra -at- yahoo -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com, Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
Date: Wed, 24 Mar 2010 08:30:16 -0700 (PDT)

> The problem I see with this is in
> what metrics you'll look for.  Project methodology is
> changing (witness Agile), the GUI/Documentation division is
> evaporating (witness Flex and other web-served GUIs), and
> the definition of a "product" is on a threshold of change
> (witness clouds, services, and virtual machines).  If
> your metrics prove the value of buggy whips, that's fine for
> now...

OK, so methodology is changing. This is new and different? When was it not changing? Change is the reason why our job exists. If there were no changes that need documenting we'd all be working as Walmart greeters.

There never was a *real* division between GUI and documentation. The user still needs to be shown how to use it (not necessarily to make it do what he wants - that often is a way different thing). They're two sides of the same coin. Designers and managers thinking there is such a division is part of the reason we have problems being included in the process. But while GUI and docs are two sides of the same coin, they can't be made a one-sided object. You might as well say that the steering wheel and dashboard are the same as the engine. The needs are not the same, trying to handle them as one and the same is a guarantee of a screwup. The work to develop them is not the same. The type of thinking and the type of training needed to know how to develop them is not the same. (i.e., engineers still can't write.)

Remember Microsoft's "Longhorn" project a few years ago? They tried that approach. They tried creating a UI which was supposedly so user-friendly that separate documentation was unneeded. It didn't just include code that tied help to the UI, it incorporated help features directly into the UI code. They even tried having the same developers do the help as the UI. Result? A jumbled mess, confusion and inefficiency in the development process, and a bunch of angry/frustrated developers.

I don't care what kind of product you're talking about. The users and even the developers still need clear guidance.

What metrics to look for? Why is this even a question? The ones that can show our work improves product value. That's true whether you're talking about buggy whips or telepathic user interfaces. The fact that things change does not mean it is impossible to develop metrics. If it did there would be no such thing as metrics for call center operations - we didn't have call centers 50 years ago. That changed, but we came up with metrics anyway.


Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial:

Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at:

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

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 for more resources and info.

Please move off-topic discussions to the Chat list, at:

Re: Metrics in its own thread: From: Chris Despopoulos

Previous by Author: Re: AW: How do hiring companies view TW resumes?
Next by Author: RE: Top 10 mistakes unstructured FrameMaker Users make in content before translation
Previous by Thread: Re: Metrics in its own thread
Next by Thread: RH can't open the settings.isf file. NOW what am I to do?

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

Sponsored Ads