[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: .doc file concerns
Greg A. Woods
Re: .doc file concerns
Wed, 27 Jun 2001 02:46:12 -0400 (EDT)
[ On Tuesday, June 26, 2001 at 22:04:23 (-0700), Paul Sander wrote: ]
> Subject: Re: .doc file concerns
> I would be interested in seeing the study. My evidence is purely empirical,
> interviewed dozens of professional authors over several years. They all
> WYSIWYG editors over markup languages.
Personally I've never met a professional _writer_ of any kind who's
actually preferred any kind of WYSIWYG *or* markup language!
Certainly designers, layout artists, maybe some editors, and the like
are prone to using WYSIWYG tools, and the ones who do usually prefer
Quark or something even more "professional" -- PC-based word processors
are never their first choice, for usually obvious reasons.
Certainly academics who write generally seem to prefer the likes of TeX
or Lout, etc., even those in fields otherwise diverse of technology.
> Productivity over what period of time? From the time they start to the time
> they produce words, from the time that they start until they produce a first
> draft, or from the time they start until they finish a document and ship it?
Real professional writers only produce the words. Unfortunately in the
software business sometimes tech writers get shouldered with the whole
production job (and when there's no tech writer guess who does it! ;-).
Only in very recent years have textbook publishing companies started
accepting camera-ready copy from authors, and that movement seems to
have been driven entirely by the troff and TeX users.
> Well, professional authors are not normal human beings. They don't write the
> same way that you and I do. You and I don't write Visual BASIC, either. They
> need complex tools to do what they do, just as you and I need a different set
> of complex tools to do what we do.
That begs the question -- why do normal human beings need the likes of
M$-Word or WordPerfect, etc. then?
> >(FrameMaker will, IIRC, create reasonably consistent text-based storage
> >files that are reasonably well suited for storage in CVS.)
> MIF is not reasonably well suited for storage in CVS; the result of text-based
> merges like those done by CVS mangle documents very badly. And it's
> unreadable by humans that resolving conflicts is harder than replicating the
> changes by hand.
In the end whether or not CVS is going to be useful for documentation
depends not only on what's being written, and on how the publishing
process will work, but also on how your documentation ties into your
whole SCM process.
I think in the end if it's sofware documentation we're talking about
then indeed the choice of source-code control tools must in fact dictate
at least the style of publishing tools used. If you want your
documentation and source code changes to stay in step and be managed
through the same change-control system then you pretty much must use
something that keeps the documentation in the same basic kind of format
as the source code -- i.e. plain text. That means you're going to be
best off with the likes of troff/TeX/lout/sgml etc.
If your programmers are doing your documentation then getting them to
use programming languages for documentaiton is perhaps a no-brainer, but
if you're using tech writers you might have a bit more of an education
and expectation management issue on your hands.
Greg A. Woods
+1 416 218-0098 VE3TCP <address@hidden> <address@hidden>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>