Skip to main content

Author: Sarah O'Keefe


Somebody does NOT like DITA

From Jon Bosak’s closing keynote at XML 2006:

Another ancient subject that seems to be popping up again is the idea of modular document creation. This is one of those concepts that comes through about once a decade, seduces all the writing managers with the prospect of greater efficiency, takes over entire writing departments for a couple of years, and then falls out of favor as people finally realize that document reuse is not a solvable problem in document delivery but rather an intractable problem in document writing — which is, how to retain any sense of logical connection between pieces of information while writing as if your target audience consisted entirely of people afflicted with ADD.

I don’t think I agree completely, but he does have a point.

I could go on at length about this, but instead I’ll simply leave you with the observation that my personal love affair with modular documentation occurred in 1978 and that I haven’t seen a thing since then that would change the conclusions I reached about it almost thirty years ago. This is not to say that I’m trying to discourage the technical writing community whence I came from their enthusiasm for the modular authoring technology du jour, since engagement in such efforts is virtually guaranteed to buy tech writers a few years in which they can act like software engineers and present themselves as engaged in cutting-edge informational technology development rather than plain old technical writing. That strategy has worked great for some of us.

I think perhaps the arguments for and against single-source publishing are a better place to look. There is a school of thought that argues that single sourcing results in inferior deliverables, both in print and online. But the cost savings from single sourcing are so compelling that nobody really argues for hand-crafting printed and online materials separately any more. (Based on my experience, I think that the quality difference between material that is single sourced (well) and material that is hand-crafted (well) is quite small; perhaps around 10 percent. But that last ten percent is extremely expensive.)

With XML/DITA/modular documentation, there is a similar cost argument. Document reuse and especially localization workflows benefit from modular documentation. For localization teams, getting content in topics rather than monolithic books can result in incremental localization and thus the ability to “sim-ship”; to ship the product in the source language and target languages simultaneously. This, in turn, means a global product launch and a shorter wait for revenue from the markets for which localization is required.

Thus, requirement to accelerate product deliverables and save money on localization (because of more efficient reuse) are going to drive implementation of modular documentation. The argument that non-modular documentation is better documentation will become irrelevant.

Read More

Party Time!

Here at Scriptorium, the party is just getting started. 2007 is our tenth anniversary year, and since we’re always looking an excuse to celebrate, we plan to have an anniversary announcement every month. Or perhaps the first ten months.

Or when we get around to it.

Look for our January anniversary announcement later this week.

And if you have any suggestion on celebratory goodies for customers, please let us know in the comments.

Read More

Holiday slowdown…if only!

Most years, we slide into the holidays gracefully. Around Thanksgiving, we are busy, but by mid-December, we’ve delivered our end-of-year projects and are beginning to kick back for the holidays.

Not this year.

I’m not sure exactly what happened, but we have several projects due in January, and there is no slowdown in sight.

(Over the years, I’ve come to count on a slow couple of weeks around the end of the year during which I can finish up some long-term planning. This year, I will apparently be going to Plan B…when I figure out what that is.)

Read More

Life, liberty, and the pursuit of maple syrup

Wednesday evening, I detoured from XML 2006 in Boston up to Nashua, New Hampshire, for a presentation at the STC Northern New England chapter.

(Thanks to Char James-Tanny for providing transportation!)

Traditionally, presenters are given a jug of maple syrup. Yum. I love maple syrup.

But sadly, the TSA does not permit maple syrup in quantities greater than three ounces in your carry-on luggage. And I don’t check luggage except under extreme circumstances. (And transporting maple syrup doesn’t — quite — qualify.)

My thoughtful hosts, however, decided to give me maple taffy and maple cream cookies instead. Much appreciated.

Note: Cattle prods and throwing stars are permitted in checked baggage only. Good to know before my next on-site class . (And no, I am not making this up. Look under “tools” and “martial arts & self-defense items”)

Read More

XML 2006: Not the takeaway I was expecting

A conference presentation is a specialized form of technical communication — in addition to basic technical writing skills, a presenter needs the ability communicate effectively in a conference session. The presenters here are technical experts, but many of them are really terrible at the front of a room!

For example, they are making the following mistakes (some presenters are doing all of these):

  • Reading slides
  • Slides with too much text in too small a font (the vast majority of the presentations)
  • Mumbling
  • Poor microphone management (not talking into the microphone, moving back and forth so that the volume goes up and down)
  • Poor time management — spending too much time on introductory material and not enough time on the important bits of the presentation
  • Speaking in extreme monotones
  • Sentences trailing off in volume

I don’t know exactly how conference proposals were evaluated, but it looks very much as though content is king (sounds good, right?) Proposals were evaluated on technical merit and little or no consideration was given to presentation skills.

Unfortunately, this doesn’t work. If you have great knowledge, but are unable to communicate that verbally, then putting you at the front of a room full of people is not helpful.

And worst of all, there are NO EVALUATIONS! That means that there’s little or no chance that the situation will be addressed next year. (There is an overall conference evaluation form, but you have to remember to go get it at the registration desk.)

Joe Welinske of WritersUA does the best of job of speaker assessment I’ve seen:

  • He asks participants to fill out evaluations for each speaker. There are just a few questions, and each evaluation is an entry for a door prize. In other words, he bribes participants to fill out the evaluations.
  • Speakers who suck with poor evaluations aren’t invited back the next year.
  • He rarely allows panels or group presentations (too much diffusion of responsibility).
  • Speakers who were rated highly in the past get stars on their bios, so attendees have some additional information to help them choose a session.
  • Joe attends many conferences each year to evaluate prospective speakers and to gauge which topics are getting the most interest from attendees. He builds his program based on this research.

The contrast between the presentation quality here and at WritersUA is really quite stunning.

Read More

XML 2006: Content Management APIs

How Google and wireless access have changed the world: I’m sitting in this session, and the presenter’s approach isn’t working for me. So, I google jsr 170 and I find this article at CMS Watch that explains it quite nicely.

Having skimmed that, I return my attention to the presenter, and find that he’s making a lot more sense.

The CMS Watch article has an excellent definition of JSR 170:

JSR-170 promises the Java world, and possibly beyond, a unified API that allows accessing any compliant repository in a vendor- or implementation-neutral fashion, leading to the kind of clean separation of concerns that characterizes modern IT architectures. Some people call JSR-170 the “JDBC [Java Database Connectivity] of Content Repositories.”

Now, we have Michael Wechner presenting on what is theoretically the same topic. Only not. He leads with this: “Today, every CMS is producing its own user interface, which is just kind of silly.” And then this analogy: mail servers are standardized, but you’re free to use your own client/front end. Similarly, CMSes need a common backend and you can do whatever on the front end.

I feel smarter already.

Wechner’s company, Wyona, is an integrator for open source CMS.

He points out that the ability to work offline is important because people aren’t always online. He uses the example of a train ride in Europe — the obvious equivalent in the United States is airplanes. (Side note: If people are permitted to yap on their cell phones in-flight, I’m probably going to stop traveling altogether. It’s bad enough on the ground at the gate.)

OK, and I think he’s proposing that you use existing protocols, such as Atom and WebDAV, to do CMS connections.

Read More

XML 2006: XML in Legislation

Timothy Arnold-Moore of SAIC (I think). Good presenter with a sense of humor.

Magna CartaHe points out again that legislation has a shelf life of hundreds of years and so a typical word processing format, which lasts about 10 years, is really not an option. Look! A picture of the Magna Carta to illustrate his point. Bonus points for use of graphics. Even if he did (as I just did) pull it from Wikipedia.

Best practices for legislation:

  • Updates are made to bills from the floor of the legislative chamber and are thus near-instant.
  • Provide information about bill status, proposed amendments, consolidated form of amendments
  • Provide the “as made” versions as soon as enacted
  • Consolidate amendments unofficially. Side note: The US Code takes more than two years for official updates. (ed: That is pathetic.)

Working with legislative XML requires some heavy lifting in revision tracking. Interesting. They have the proposed act in one document and a separate Change Description Document. They integrate the two to produce the amended version(s).

Nice demo of the Tasmanian EnAct system. This presenter is familiar with the concept of “show, don’t tell.” They use an SAIC product, TeraText, as the foundation.

Read More

XML 2006: Vendor PechaKucha

At its best, the PechaKucha was highly entertaining. At its worst, it was painful, but at least the bad presentations were short.

After about an hour, though, the entertainment value started to wear off and tiredness set in. Perhaps, in the future, these mini-presentations could be interleaved among the other stuff.


  • Ken Holman of Crane Softwrights instructed the audience to yell “bing” as the slides changed behind him.
  • Carlo Minollo (sp?) of DataDirect got up, talked very fast, and was perfectly synchronized with his slides without any apparent effort. (This means, by the way, that he practiced. A lot.)


  • A series of dreary presentations from Oracle. One presenter said, “Don’t look at me.”
  • Binary XML? Ugh.

Read More