Stephen,
First, I should say that using terms such as "what silly nonsense"
does *not* impress others as having any sort of open or constructive
attitude. Instead, it comes across as condescending, to put it mildly.
As for your assertion that "Word has failed for years as program of
choice for technical writers"--that simply betrays that you know
little of the current tech writing profession. Although I am new to
LyX and laTeX, I *have* been a tech writer for the better part of
twenty years, and am a longtime member of the Society for Technical
Communications. Although I personally cannot *stand* Word for tech
writing, I would estimate that roughly half of all the commercial tech
writing projects today use it. You are correct, though, that the
"Master Document" feature is an abortion and has never worked
properly--and thus it is rarely attempted for tech pubs work. The more
compelling problem, I believe, is the brain-dead autonumbering in
Word.
Many projects within the tech writing field today are done in
FrameMaker, which Adobe has not *quite* managed to kill yet. However,
they seem to be working to fold more long document features into
InDesign with each upgrade, with their intention being to use its code
base as a next-generation documentation tool.
I know of very few shops using TeX in any flavor for tech
documentation--although it seems to be far more popular in academia
than it is in commercial software development.
That said, I have held on several professional mail lists for tech
writers that the LyX approach seems far better suited for
documentation than other solutions. Entirely too much time is spent by
tech writers fiddling with layout, and version upgrades are
complicated by various style and format overrides in the documents.
At present, I believe that there is increasing interest in XML
authoring solutions, with a document production sequence that permits
these files to be printed properly--although "printed" these days
increasingly does not include printing. Delivery in Acrobat format is
extremely popular and is rapidly replacing printed manual production.
Where I think discussions like this can be most productive is to
address comments on what you believe to be their merits and not by
dismissing them with pejoritives. Otherwise, you simply drive away
people who may be extremely helpful additions to the user community.
Rather than dismissing these comments out of hand with some notion of
what "cannot" be done given the present state of the program, why not
address the ideas based upon whether they are truly desirable on their
merits, with the method of producing such a result left to a separate
discussion.
For example, I could easily see a separate software environment in
which samples of each of the layouts included with LyX could be called
up, with content including instructions on the various particulars of
that format. As it stands, learning the various uses of the included
layout files is chaotic at best, so seeing such sample files onscreen
would be a great help. That would also be a great help in determining
what layout files to use as the basis for any modifications desired.
In such a situation, popup "tool tips" could easily enough show the
laTeX or LyX code required for the given feature (to list just one
example). That would also be extremely helpful in learning the most
commonly used commands.
With such sample and instruction files, a variety of options could be
set to result in the layout alterations desired, and saved when the
software environment is changed back to the regular production
interface.
This would, I believe, be just one method of making the details to
which people have referred relatively easy (at least for basic
changes), while not complicating the basic interface and menu
selections unduly.
This is but an offhand suggestion I have not thought through
completely. However, I offer it as a potential means of arriving at
the goal of a more easily-mastered layout designer. It is similar in
some respects to the development environment of the early Xerox
workstations, which had one environment for average users in whcih
there were no real development options, and another one for
developmers in which alterations ("hacks" in their jargon at the time)
could be easily made, and saved for use in the normal environment.
This was in the days of the 6085 workstation and, before that, the
Star system. Thus, there are few truly new ideas around--but many old
ones are very worthwhile for considering how to address problems
today.
David
