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.
At 11:40 AM 5/5/00 -0500, Locke, David wrote:
>Betsy Pfister said:
>>Haha! Welcome to the "Level 0" nightmare.
>
>Keep in mind that the "Level 0" nightmare is self correcting. Miss a few
>ship dates and the people in charge will lose their jobs--provided you are
>in a "performance-based" organization.
>
>But, if you cannot wait that long, you might want to consider specifications
>to be unneccessary. If you are experimenting with the application, you
>should be able to identify all the entities exposed in the UI. And, you
>should be able to identify the functionality exposed in the UI. These things
>contribute to the user's conceptual model. Outside information is only
>necessary when the application deviates from the user's conceptual model.
>But, the application should NEVER deviate from the user's conceptual model.
>If it does, then consider that deviation a bug of the highest order, and
>don't let the product ship. This will drive negative use costs to the moon.
>And, no amount of wallpaper (documents) will be able to paper it over.
>
>If I have to ask you how it works, its broken. Period. Spec or no spec. SME
>descriptions or not.
==========================================================================
An oversimplification if there ever was one. The devil is always in the details.
For instance, if there's a data entry slot in a UI form, and there are upper
and/or lower limits to the values that can be entered therein, those limits
are not explicitly apparent to the user, but they should be in the written
specification. If the range of valid values is stated in the documentation,
it contributes to the user's conceptual model. If it is not state there, the
user, by trial and error, must discover the upper and lower limits. That
definitely would, as you say, "Drive negative use costs to the moon." I can
think of many other instances. The purpose of good documentation is to make
it easier for the user to form a complete conceptual model. If there are no
written specifications, or if the specifications are not maintained current,
then the kind of information I'm describing either won't be in the
documentation, or the documentation will give incorrect values.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.
