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:GUI Design vs Documentation (longish) From:Alessandro Bottoni <bottoni -at- CADLAB -dot- IT> Date:Fri, 27 Feb 1998 16:11:22 +0100
Hope Cascio wrote:
"...omissis...but I am more drawn to documenting the software,
which I see as my purpose as a technical writer."
Instead, I'm looking to Computer-Human Interface, Software usability and GUI
design as the most interesting direction for computers evolution and,
consequently, for my professional growth.
I consider GUI and documentation as two different way to carry information
from the developing team to the user. Consider the case of a mechanical
engineer who is designing a new car engine. In this case, we can say that
80% of the needed information was carried by the professional education
(university), 10% by software interface (included wizards) and 10% by
documentation. In other cases (a publisher working with FrameMaker, for
example) the ratio can be different, let's say 60% by education, 20% by
interface and 20% by documentation.
In any case, documentation carry just a part of all the needed information,
maybe not the bigger one.
I think we should go toward a documentation that carry just the information
that cannot be effectively carried by the user interface. The user interface
has a "loading capacity". If you try to put in the interface all the
availabe information, you will destroy it. A large part of information has
to be carried by documentation (on paper and on line).
To get good software, we have to split the information needed with care and
write it down where it can be more effective. (of course, we have to reduce
the required information to the least possible amount). For example: it
would be stupid to tell the user how to perform a task, writing a manual
page, when we can "lead" him to the wanted result with a Wizard.
When I say "writing information in the user interface", I do not refer just
to labels, text and icons. User interface carry a lot of information in its
very structure (the conceptual model that lay under it). Software industry
has not yet learnt how to use this unconventional "communication channel"
(and this is a good job opportunity for skilled people, guys).
This is the reason why I think that software developers and technical
documentators should work together. Also, this is the reason why a software
TW should have a good background in programming and GUI design, IMHO.