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.
Nancy Allison wonders: <<I'd like to be able to explain why it's a
bad idea for a company to develop a product's functions first, before
thinking about the user interface (or documentation).>>
Here's an example even an engineer could understand. <gdr> "So you're
building a car. You don't know what it'll look like, but you've got a
killer engine designer, the world's greatest radio designer, a guy
who eats sheet metal for breakfast, and so on. You send them off to
design an engine, a radio, and the skin of the car without any
thought about how the parts are going to fit together, and hope the
result will fit into something recognizable as a modern car, right?
No? Let me guess... you start with a clear idea of how the car is
going to work, then figure out how those functions determine the type
of engine, radio, and frame you'll need, then you fit all this
together, and revise it if necessary to ensure it fits. So why can't
you do that with software?"
Or try the architecture metaphor: "OK, here's the deal. I want you to
build me a house. Head over to the local [name of big-box hardware
store] and buy everything you need, then build me my house. What do
you mean 'I want a blueprint'? Blueprints are for architects. You're
a professional. You don't need no steenken' blueprints!"
<Fe>By the evidence, modern software development managers don't get
it, so don't waste your time explaining it to them. Stick to the
engineers... they know how the world works.</Fe>
<<I know of a startup where the developers have created very powerful
functions, with the strangest user interface you have ever seen. It
is just plain bizarre. Functions have strange names; tools are
scattered around the interface in no discernible order; different
buttons lead to confusingly similar drop-down lists and directories,
with no clear indication of what you can or can't do in each area.
It's a geek's paradise, and a total mess. The lead developer said to
me, "Oh, we'll fix the UI later.">>
Strictly speaking--and I hate to admit it--they're right, at least in
part. The thing about modern software design is that the hard part is
the plumbing--the code that actually does the work. Connecting the
plumbing together to create an interface is trivial by comparison--
though designing the interface is considerably harder. Of course,
it's smarter to start with your car design or house blueprint first,
but unlike physical products, software is infinitely malleable: it's
much easier to put together a working interface now than at any
previous time in programming history.
<<I have heard that it may not be possible to completely redo a UI
once the software architecture is in place.>>
It's certainly possible to design a software architecture that
imposes a certain interface, but that's not inevitable. Software that
is coded in intelligently designed modules can be reconfigured
relatively easily: the interface provides access to the modules, but
is separate from the modules. The problem comes in the workflow: if
the natural interface for the way people would work suggests a
certain workflow, this imposes certain constraints on the software
plumbing that will implement that workflow. So you may need to revise
some of the plumbing, and that's painful and difficult... just as it
would be if you decided to move your bathroom from the basement to
the attic after construction of the house is already complete.
Alan Cooper has written elegantly about these issues for many years
(most notably, in _About Face 2.0_), and since he has serious street
cred in the programming community, he's a good name to drop.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
