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 wondered: <<I always wonder where writers like Cooper
get their great examples, and I'm always trying to collect my own.>>
He lived the life for many years. Spend enough time hanging out in
any community and you gradually collect a stock of anecdotes. I could
tell ya many tales about writers and editors, ferinstance... <g>
<<Is it really burdensome to change the wording in a UI? If a prompt
is vaguely worded, or if something is misspelled, is it very hard for
a developer to correct it? I was once told that a change I proposed
would be "too expensive." It involved changing the wording in a
single popup box, and it would have made a huge difference to the
usability of the UI.>>
Usually, that's programmer-speak for "I have 3 hours to do 300 hours
of work, and though I'd love to help, I really don't have time to do
this for you." Other times, it's "I can do that in 30 seconds, but
then I have to wait for an hour while the code recompiles, and I
can't even start the recompile until everyone else finishes what
they're doing".
Changing a text string is trivial, but there's always more to
consider than just the string. For example, if the string has to fit
on a graphical button that won't automatically resize, or if it's
necessary to figure out how to fit a resized button within a fixed-
size dialog box, or if the programmer took a shortcut and used the
same words in several places that really require their own unique
wording, and so on... Then it takes a bit of work to make sure that
changing the text doesn't introduce any unexpected problems in the
interface. Plus there are typos, the risk of editing the wrong string
(a lookalike string in a different part of the interface), and so on.
In short, it adds an additional quality assurance step for each such
change. This is another good reason for designing the interface
correctly right from the start: less things to fix and test later.
Changing the string is easiest if the text is stored in an external
file that is added into the code during compilation; programmers
quite naturally don't trust us to go mucking about in their code, and
while we play with the words, a block of code isn't available for the
programmers to work on.
Delphi makes this much easier, since the developers gave me a .LAN
(language?) file to edit, and so long as I was careful not to wipe
out any of the control codes used to define the boundaries of the
text strings or any of various special characters, I could work
directly in that file without disturbing them at all. In fact, I
could use Word's revision tracking* so they could see what I had done
and discuss it with me if they thought I'd screwed up. But you still
need the quality control step to be sure you haven't screwed anything
up.
* The file is in text format. Open it in Word, save it as a Word
document, edit using revision tracking, return to the developer.
After they incorporate all the edits, and check three times to be
sure they really did it right, save again in text format. Works a treat!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
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
