TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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: http://www.doctohelp.com
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: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
