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: User Interface Design book recommendation From:SANDRA CHARKER <scharker -at- OZEMAIL -dot- COM -dot- AU> Date:Sun, 21 Jan 1996 08:23:48 +1000
Gary Merrill writes that Sandra Charker writes:
>> > I wish I could say this book is for user interface designers and let it
>> that. Most user interfaces are still designed by programmers, an increasing
>> number of whom are growing uneasy as they glimpse the gulf between the skill
>> set needed for software construction and the skill set needed for software
>> design. Documentation writers, trainers and technical support people
>> increasingly share this same worry. It is for this growing community of
>> design-aware developers that this book is written. <
Sandra Charker wishes to make the pedantic interpolation that the preceding
paragraph is a quotation from Alan Cooper's book _About Face_. She hopes she
would be as fussy about protecting the author of a book she doesn't like.
> It is a mistake to suppose that "software construction" and "software
>are distinct in the manner implied.
Gary, are you saying construction and design are not distinct in practice or in
principle. If they're not distinct in principle, doesn't that mean that
"documentation writers, trainers and technical support people" have, in
principle, no part in the software development process?
Seems to me that 'software development' and 'software documentation
development' are very similar processes, and that when it comes to developing
online documents they can be indistinguishable processes. For application
software, same as for publications, getting a product finished at all, let
alone to a schedule and a budget, requires that design comes before
construction, and that construction uses the design.
Not that designs don't change during construction <g>. But I think design and
construction need different mind sets. Even where the design and construction
teams are identical (like where there's one writer <g>), for the sake of the
end product they need to wear different hats and recognise when to change them.
(scharker -at- ozemail -dot- com -dot- au)
In stormy Sydney, Oztralia, where we swapped
from sunhats to rainhats five times a day,
until the wind blew them all away