iSommelier - Extreme Single Sourcing

There's a lot of talk in technical communication about single sourcing, to put it mildly, but how does single sourcing actually manifest itself?

If we focus on online outputs, we're typically talking about one help file designed for use on a large-screen device like a desktop or laptop PC. Occasionally, someone will output in multiple formats, such as WebHelp and HTML Help, but still for a desktop or laptop PC. Rarely, someone might have to output for handhelds or, rarer still, to voice, ink, or other unusual systems.

One common denominator behind all of these outputs is individual interactions and standard units of content - one person at a time using one topic at a time. But a recent article in Business Week (The iSommelier Will Take Your Order, Feb. 25, 2008, page 72) introduced a new and unusual type of output.

iSommelier is a wine bar with a touch-sensitive surface, like an iPhone and on the same lines as Microsoft's Surface (see http://www.microsoft.com/surface/). The idea behind iSommelier is that guests can review a restaurant's wine selections, read tasting notes, and place orders using their fingers as navigation tools on the device's surface. As the writer describes it:

"... a list of countries materializes. I choose Spain. Then a menu of regions appears, and beneath that, a selection of wines. I drill down some more, and a graphic displays details about the producer and grapes, along with tasting notes arranged in a rosette pattern..."

Touch-screen computers aren't new. ATMs have been around for years. But interfaces like iSommelier offer more interesting displays and group interactivity. It's also an excellent illustration of how unexpected technical and marketing forces may affect how we create and structure content for display in unexpected venues. Imagine that you're the content developer for a wine reference web site and are told by the sales manager that the company just won a bid to provide information for some weird new product called iSommelier... Some possible effects:

- In order to avoid writing content multiple times, you'll have to be able to repurpose your existing content for iSommelier and whatever comes after that.

- The need to manipulate the content means it'll have to be coded using proper syntax. This could drive your move toward XML, since you'll need clean code in order to be able to repurpose the content quickly and automatically.

- The need to manipulate the content also means it must be structured consistently. The obvious answer is structured authoring, but according to what standard? DITA is often presented as the answer to all structured authoring needs but, from what I've seen of it, it lacks the flexibility to handle something this unusual. (I'm open to correction from other DITA users here...)

One argument against worrying about products like iSommelier or technologies like touch-surface driven interfaces is scarcity and price. iSommelier costs $250,000 and Microsoft's Surface is expected to cost $5,000 to $10,000 per unit, limiting their market penetration. True, but notice that Surface is already over 95% cheaper than iSommelier and costs will continue to fall if there proves to be a market for this kind of technology. (The first laser printer I ever saw was the size of a desk and cost about $250,000. My latest is a color laser with automatic two-sided printing that cost $399.)

Without trying to read too much into one interesting but niche product, iSommelier is a harbinger of the types of uses for our content that may show up out of the blue, and that we can only be prepared for by following standards.

Return of RoboSource?

If you used RoboHelp in the X5 days, you may have noticed RoboSource Control - the free version control system that shipped with RoboHelp. It was so simple that many people who saw it had the same initial reaction - "a toy version control system." But that reaction was wrong. RoboSource made version control simple enough that it didn't take your focus away from the actual project work.

Unfortunately, RoboSource 1 had problems. One bug corrupted a RoboHelp project if you added it to version control through RoboSource, but you could add the same project to version control just fine through RoboHelp. There was also a limit to how many files RoboSource could handle. A rule of thumb was to expect problems if a project neared the 2,000 file mark and to be surprised if you didn't get problems above 2,000 files. (2,000 seems like a lot, but consider a 1,000 topic project plus screen shots and you'll see that files add up quickly.) Finally, the documentation wasn't clear, so many people never tried it because they didn't understand how it worked in the first place. And RoboSource just dropped out of sight during RoboHelp's time in limbo under MacroMedia.

When Adobe released RoboHelp 6, one feature that was lost in the uproar was a new version 3 of RoboSource. (Adobe kept RoboSource 3 when it released RoboHelp 7.) I ignored it until three client calls in the space of a month made me go back and look at it again. And helping one client implement it exposed me to some of the internals of the new version and some of its peculiarities.

At a high level, RoboSource 3 works the same way as v. 1. Create the RoboHelp project, then add it to version control. Once you do, there's one other step that has to be performed once. The first time you open a project after adding it to version control, you do so by opening it specifically from the version control system. This creates a local copy of the project on your C drive. From then on, you open the project locally, like you would if the project wasn't in version control. When you do, RoboSource compares the versions of each file in the version control system on the server to the corresponding file on your C drive. If the local version is newer, RoboHelp uses that version. If the server version is newer, RoboSource copies it to the C drive and opens it in RoboHelp. In other words, you're always working on the local version which is being kept up-to-date by RoboSource.

Once the project is in version control, you get the expected check-in and check-out features, along with rollbacks and "diffing" - e.g. "differencing" or comparison of two versions of the same file.

RoboSource 3 still has peculiarities, the biggest apparently still being its file capacity. According to tech support, RoboSource 3 is based on SQL Express so, in theory, its capacity should essentially be unlimited. In practice, however, a client in Florida tried to load a 4,000 topic RoboHelp project (closer to 5,000 files when you count the graphics and control files) only to have RoboSource hang, apparently. This happened late enough in the afternoon that he decided to go home and clean off the server in the morning. But when he arrived the next morning, he found that the project had been added to version control. RoboSource had just gotten tied up with some function the previous afternoon and didn't provide any status messages to that effect, so we thought it had crashed.

In summary, RoboSource 3 is worth a look if you need a cheap and simple version control system. (Do not use the original version, even though it's still available in the RoboHelp 7 toolbox pod.) Try a few small and simple test projects first to see if it's working correctly and, if it is, give it a shot. And let me know what happens...