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.
> Before cutting us programmers to shreds, consider this: programmers dea=
> l with many of the same issues as writers--tight schedules, not enough=
> info, skimpy resources ... In the end, we are under much more pressur=
> e to make the software work correctly than we are to spend time on usa=
> bility. (Don't get me wrong--I'm not saying we're under more pressure =
> than writers.)
>
> It's the responsibility of management to differentiate between the task=
> s of designing a UI and coding software. Often, good coders are expect=
> ed to be good UI designers and vice versa. Unfortunately, so many of u=
> s are equipped to do one or the other but not both. Or we're capable o=
> f both but don't have the resources.
So let us put the blame where it belongs -- on management!
Actually, even the managers are in a bind. The middle manager gets hit
from below and above. Perhaps the solution is braver managers. I once
worked for a company where the CEO was not afraid to tell a client that
he could get good product, or fast product, but that good and fast
product were mutually exclusive. When it was put on the line like that
by the CEO, clients listened - and decided which kind of product they
wanted for their money. Even the fast product was better than what the
client had coming into the bargain.
My current pet peeve is with software that puts all the complexity out
on the user interface, where the end user, often poorly trained because
of budget constraints, gets to sort everything out.
A manufacturing engineer friend has a different, and quite successful
philosophy: when dealing with relatively non-technical end users, put
the complexity INSIDE the product, then keep the user interface clean and
simple. It works for many products. Why doesn't the computer industry
learn from this?
>
>
--
Robert Garland Amateur Radio Station NX3S
Hilltown Township Bucks County Grid FN20ii
Pennsylvania USA robert -at- jtan -dot- com
