Re: ANNOUNCEMENT: My book on SGML has been published

[Chet Ensign <censign -at- INTERSERV -dot- COM>]

John,

Thanks for your response to my post. You are asking the right kinds of
questions and making completely appropriate observations. Keep this up and you
may well end up with a successful system. (wink)

OK, now I'll be serious. To give you a broad answer, I **am** guilty of trying
to hype the intended audience (managers and execs) on the subject. Of SGML, but
even more of the importance of document-based information to their
organization. That, to me, is the only thing that makes SGML a valuable
technology. It is also what makes its application rigorous and demanding, and I
have tried to educate the audience to that aspect of these stories as well.

I did examine costs and benefits as much as I was able, though that information
is not set out in tables or detailed spreadsheets. In general, the case study
implementations were expensive and did involve reengineering work processes.
They also paid for themselves and in every single case gave the people working
with the data new opportunities that they would not have even thought of had
their information not been in SGML.

But the issue you raise is where I think so many of corporate solutions -- not
just SGML -- go awry. Somebody wants a magic bullet to solve their problem.
They do not want to have to think too hard, or look too deeply, into the
underlying problem. Few people and few organizations are used to thinking about
local problems on a global scale.

That's one reason that coming up with cost/benefit data was difficult. Most
companies can't measure expenses related to processes, especially those that
cross a departmental boundary. When engineering release notes come into tech
doc in either LaTex, Script or Ami Pro, organized and formatted 47 different
ways from Sunday, you spend a substantial amount of time turning them into
something you can work with -- your writing tool's format, your team's
organization and structure. That's expense, but rarely can it be measured. When
you send out FrameMaker documents or PostScript files to customer service and
training, ditto for them. But those costs are hidden, and when you try to track
them you get the feeling that they are not small.

The SGML industry **has** been guilty of near religious zeal -- partly from
enthusiasm, partly from ignorance, and partly from good, old-fashioned greed.
You are right to be wary of the pitches and the promises. The truth is more
like this:

- SGML is a demanding discipline
- It is still easy to develop rigid, brittle applications that don't scale well
- Tools are just beginning to get beyond what I'd term "primitive"
- Building useful systems takes time and demands input from a broad range of
users

In fact, I'd be really depressed about SGML, if the current state of affairs
weren't so darned bleak:

- We produce beautiful, WYSIWYG pages that are next to useless for any other
application
- The volume of information we have to convey is exploding, but we are still
only capable of dealing with it one page at a time
- We each possess huge amounts of expertise **about** the content we are
producing, with no way to capture it or leverage to anyone's benefit. Once we
hit the print button, it is gone!
- Our tools output blobs of stuff, not useful, general-purpose data

Basically, in an age when we need to be thinking about "information
manufacturing" we still work in an "information cottage-industry."

I've put some answers to particular questions below. And I'll provide some info
about particular applications in another message. My daughter is waking up and
I have to get my day started. Thanks again for asking these questions. By the
way, I'm a bit familar with Schlumberger; I've talked to people there. Be happy
to discuss particulars with you another time.

>> The estimate I got from one of the SAS people was that it took 30 people
two years to work out all of the kinks--and that got them to the prototype
stage. <<

I would not call that typical by any means. And whether it was appropriate in
their circumstances depends on the scale of what they were trying to do, the
problem they were trying to solve, the experience level of the people going in,
etc.

>> Too many books blithely hype SGML as a cure-all . Too few address in
detail the substantial issues surrounding design and implementation, or
the dependencies a successful implementation has on organizational
structure and cooperation. <<

This is a valid criticism of the industry in general. My present job is, in
large part, to clean up the mess left behind by a vendor who overhyped what the
technology would do. I haven't -- at least I hope I haven't -- presented SGML
as the magic solution, and part of my reason for writing the book the way I did
was to provide a level of education to managers about what a successful
application demands. A book that I think anyone serious about SGML should read
before they get into it is Dale Waldt's and Brian Travis's "SGML Implementation
Guide" because it goes into precisely that kind of detail.

>> I am currently working with some managers who are being pushed
to accept SGML (including responsibility for maintenance!), but do
not have resources to support it (2 tech writers, no support programmers) nor
an adequate understanding of it <<

Well, I hope that my book could help address some of that problem. But the
bigger question is, what problem do the people promoting SGML want to solve?
And what resources will they supply -- not providing the necessary resources is
a problem for any technology, not just SGML.

>> 1. Authoring interface. Productivity is a big issue here, because
companies usually scrimp on hiring authors. Frame or Interleaf
are examples of high-productivity interfaces. <<

The bigger problem, I think, is changing people's perceptions of what their job
is. Too many content-creators fall in love with a beautiful piece of paper and
don't think about the nature of the information. There are more options today
than ever before for developing both useful information and an attractive page
layout, but if people remain focused on how to get indented courier, there will
still be problems in the final application.

>> 2. DTDs. There are a lot of forms of communication out there, each
with its own visual style:  training, documentation, marketing, business
communications, reports, etc.  It is a challenge to come up with a set
of tags that allow information elements to travel well between contexts.
SAS spent time with this issue. <<

Yes, this is a significant issue. But it is not a show stopper and, in fact,
the process of getting together to review/document/address common information
requirements is probably beneficial to the entire organization. There's a lot
of thought going into the best ways to address this question.

>> 3. Production filters. SGML browsers represent a "special case" way
of thinking. Both IBM and SAS planned to use filters to convert SGML to
Windows Help, HTML, or other more univerally accepted forms of output. <<

Certainly true. Access to the information is what this is ultimately all about.
I'd rather have SGML as my starting point than just about anything else. James
Clark's public domain tools provide useful starting points, including mappings
to HTML that are built right in. In essence, I see this as the main reason
you'd want SGML as your data set.

>> 4. Training and documentation. You have to invest in these both to
create acceptance and to create the level of competence in use that
overall productivity depends on. SAS had built this into their plan. <<

As should everyone else. Again, this is not unique to SGML. I'm sure we could
start a thread that would run all week about how short sighted training and
documentation policies have hobbled this or that activity.

>> Is anyone else working on SGML process implementation
or technology evaluation, especially for technical
documentation and training materials? I'd be interested
in swapping stories. I'm especially interested in how smaller-scale
operations manage to get started. The price of entry seems
to be quite high. <<

One case study that I didn't get into the book -- a project at Kodak -- was
quite the opposite however. It was the production of a Business Partner-type
catalog, one of those marketing devices that salespeople love to give out,
Marketing never has a budget for, and as a result is usually woefully out of
date from one release to the next. Terry Badger, the man who put the system
together, kept the budget so low that it was essentially a rounding error in
his department's budget. It was done using the Microsoft desktop dictated as
corporate standard, and turned the catalog into an Access database application
that could easily be kept up-to-date, published on demand and plugged into the
Web. And after it was set up, the catalog became even cheaper to publish than
it had been before. SGML doesn't *have* to be expensive; what's required is
that you understand your problem.

Best regards,

/chet

---
<signature>
Chet Ensign                          Office: 212-448-2466
Manager of Data Architecture         Home: 201-378-3472
Matthew Bender & Company, Inc.       Email: censign -at- bender -dot- com
New York, NY
</>

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html