Re: Font Selection Methodology

[Arlen -dot- P -dot- Walker -at- jci -dot- com]

>Design needs to be done first, not last. That appears
>to me to be the crux of what we are arguing about here.

It seems more to me we're discussing "overdesigning", if I may coin a term
similar to one used among the engineers here -- "overengineering."

The root concept for the word is that when lives are at stake, you go to
greater lengths than when they aren't; you "overengineer" the part. It's
part of an engineering process called Failure Mode Effects Analysis, in
which the effects of a failure at a certain point are graded on a scale of
1 to 10, and you use that as a guideline in deciding what parts of the
design need the most attention. Engineers love to overengineer, and will do
so even if the penalty for the part failing is trivial, hence the aphorism
"There comes a point in every project when it becomes necessary to shoot
the engineer and get on with production."

My remarks were couched for the majority of tech writers, who do not deal
with life threatening situations, where the worst-case penalty for failure
is far less than that. It's not necessary to go to long lengths to deliver
something usable (as opposed to maximally usable). Sure, we'd all like to
turn out works of art, but that's not always something the customer will
pay for, so we turn out something serviceable instead.

The idea is that even a badly-designed document will not result in death or
injury, so there's no need to obsess about it. Sure, do the best you can,
and do what you can to improve, but when the project clock is ticking, make
it as accurate as you can, make the phrasing as clear as possible, and let
the rest happen if there's time. Yes it might take longer to do some
restructuring of the page design after the fact than if you had done so up
front, but that's better than not getting the doc out the door on time, and
next time you'll have another step forward that you can make.

If you get the doc done early (or even after it's done and you still have
the pre-production files and some time on your hands) you can play some
"what-if" games to educate yourself: "what if I'd done *this* with the
heading structure?" That sort of thing. Then you've armed yourself better
for the next project, and life goes on. And a couple of sessions like that
will also teach you a number of tricks that you can employ to make such a
flexible approach more feasible, and the next time you can experiment with
an even greater number of different designs. It's a slight paradigm shift,
but it's painless and doesn't have many nasty side effects.

The biggest problem I've found in all too many writers is "paralysis of
analysis," they spend so much time setting up and tweaking this and nudging
that, that the actual writing begins to suffer "because I didn't have the
time." That's why I'm biased toward Nike, "Just do it." So what if the
design is a little rough. Finish the doc and get it out. Next time you'll
do better. Call it the Bauhaus school of document design (except it uses
both upper and lower case, please). ;{>}

BTW, it's kind of interesting that just when the world of software
development is seriously considering shedding the concept of elaborate
design done up front (see references to "agile development methodologies")
writers should be starting to become attracted to it.

Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224

Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr

Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit http://www.raycomm.com/techwhirl/ for more resources and info.