Alan Brandon

This is cool. Researchers at Columbia University have developed an augmented reality device that can provide live, hands-on guidance for maintenance and repair tasks on military or other equipment. The ARMAR system combines sensors and a head-mounted display to guide technicians through repair and maintenance procedures while they perform the procedure. This eliminates the need to flip back and forth between a manual and the task at hand.

But here’s an idea: What if instead of leafing through pages or scrolling through an online manual, you could simply see your way through a task? Just slide on a headset and work your way through a bit of customized, augmented-reality education.

Check out the full article at O’Reilly Radar.

In the last couple of months there has been some great discussion inspired by Michael Hiatt’s blog post about the “myth of single-source authoring”.  I love Michael’s summation of the nearly 20-year history of single sourcing:

Single-source publishing is a zombie idea that revives itself periodically and refuses to stay dead. Its zombie supporters chant its purported benefits as a “write once, publish to many” promise and ploddingly follow it as their ultimate goal for mechanized authoring and machine translation. As an object-oriented writing methodology, it is as human as present-day robot technology—good only for conveyor belt assembly or specialized tasks, and always very expensive to implement. Single-source publishing lacks purpose in today’s world of information turnover and the dynamic nature of the Web 2.0 moving to Web 3.0 landscape.

In my experience at companies large and small, I have never seen a successful implementation of a single-source process. Like so much else in writing (and life) one size does not fit all. Sure, single-sourcing has its place and can be a great tool for some types of information delivery. But different audiences need different communications channels, and different channels need their own approach to crafting information.

Also check out Tom Johnson’s podcast and interview with Michael at Tom’s blog, I’d rather Be Writing.

I got a lot out of Scott Abel’s book review of DITA 101: Fundamentals of DITA for Authors and Managers on The Content Wrangler — and I haven’t even read the book! I think Scott really nailed the progression of structured writing over the last decade or two.

… The personal computer, the World Wide Web, desktop publishing, … have transformed not only the way consumers interact with content, but these advances have also altered the way professional communicators work. … Technical writers and editors have been forced — like it or not — to move to a more formal method of creating content, often for a global audience. Gone are the days of the free-for-all approach to creating technical documentation products one-at-a-time … The advent of the Extensible Markup Language (XML) and rapid adoption of topic-based content standards like DITA have forced [technical communicators] to separate content from format and end our addiction to desktop publishing. Today, technical communicators must learn to write modular, topic-based, context-independent content using a new breed of authoring tools.

While Scott focusses on DITA (the subject of the book he is reviewing) I would add Information Mapping to the modular tools and techniques that are enjoying a resurgence in the write-once-publish-many boom.

The modular approach to technical writing is nothing new, although the names of the concepts have changed and shifted. I remember HP’s writing system was based on modular building blocks of information.

There’s a great post on the DMN Communications blog about a new book from O’Reilly Media called The Twitter Book. The book, by Tim O’Reilly and Sarah Milstein, was written entirely using PowerPoint.

As Scott at DMN puts it:

So what does this have to do with tech comm? A lot, believe it or not. Each page is self contained. In most cases, you don’t need to read other pages of the book in order for that page to make sense. This approach is very similar to … topic-based writing.

Now, topic-based writing is one of those concepts that ebbs and flows in technical communications. I have seen a surge of interest in it lately, in the context of XML and structured documentation. But topic-based writing — sometimes unflatteringly called “chunking” — has been around for many years. When I was at HP, the official writing guide was based the idea that each “topic” was a standalone chunk of information.

Good topic-based writing is hard. In topic-based writing you have to carefully plan the structure of your information, which drives the structure of your document (book, help, etc). You also have to write succinctly and avoid going off on tangents.

Topic-based technical writing is easiest when you have a well-designed product to write about. (OK, all technical writing is easier when you have a well-designed product.)

Tim O’Reilly blogged about writing The Twitter Book using PowerPoint, the ubiquitous presentation app (emphasis is mine):

The web has changed the nature of how we read and learn. Most books still use the old model of a sustained narrative as their organizational principle. Here, we’ve used a web-like model of standalone pages, each of which can be read alone (or at most in a group of two or three), to impart key points, highlight interesting techniques or the best applications for a given task. Because the basics are so easy, there’s no need to repeat them, as so many technical books do. Instead, we can rely on the reader to provide (much of) the implicit narrative framework, and jump right to points that they might not have thought about.

You don’t see many technical documents about how to use a hammer or a light switch, because the basics are so easy. But a lot of users (the customers!) get frustrated by product documentation because it spends too much space covering what they already know and not what they need to know. How often have you seen technical documentation in which the first few steps of every procedure are: switch the unit on, make sure the cables are connected, etc. In the reader’s implicit narrative they have already done all that. They are looking for the next bit of information. The next topic. The next chunk.

O’Reilly discusses some of the reasons tha he chose PowerPoint for the The Twitter Book including ease of updates and speed. The entire blog post is worth a read. Will I be writing my next router CLI reference manual using PowerPoint? I doubt it, unless I get a really good hourly rate. For now I’ll stick with Flare and FrameMaker. How about you?