RSS 
Email 
Twitter
Facebook
The podcasts I record for I'd Rather Be Writing cover the latest trends in technical communication. I interview tech writing luminaries around the world as well as record STC presentations and other audio content. You can subscribe to podcast specific feeds using the subscription information below.
Podcast page in iTunes
Podcast: Document Engineering, Interview with Robert Glushko
May 17th, 2008 | Posted in Podcasts, Technical Writing, Web Design 7 Comments »
Download MP3
Duration: 15 min.
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
In this podcast, Dr. Robert Glushko, a professor at UC Berkeley’s School of Information, explains the concept of Document Engineering — the process of developing document models to make information sharing, reuse, or syndication more efficient.
Glushko gives several examples of document engineering, such as creating a calendar event model that allows an event to by shared across numerous calendars. Or a syllabus document model, which allows students to pull specific data from syllabi across the university in unique ways.
The document models Glushko and his students create help people embrace best practices, rather than merely encoding bad habits. Even the founders of Youtube.com learned principles of information organization and retrieval from Berkeley’s School of Information.
In this podcast Glushko also talks about the notion of the transaction. He says the user experience isn’t based on how easy a website is to use, or how clear certain labels are. What matters most is the transaction — whether the merchant fulfilled a promise to the customer, and how smooth and efficient the fulfillment was.
Good transactions are enabled by a plethora of document choreography going on in the background. Information designers make the information fit together well and contribute to successful transaction experiences.
For more information on Robert Glushko, document engineering, the the School of Information at Berkeley, see Robert Glushko’s home page. You can also read Dr. Glushko’s book on Document Engineering, or follow his blog, Doc or Die.
Here’s a related post from Robert’s blog about his keynote at Doc Train.
Tags: Doc Train, Document Engineering, Robert Glushko
[...] area, but Tom Johnson does an excellent job of covering interesting and relevant topics. His latest podcast is an interview with Robert Glushko, a professor at U Cal Berkeley:"Glushko explains the [...]
[...] Johnson interviews Sarah O’Keefe, Bob Glushko, Noz Urbina, Stewart Mader, David Holmes, and Alan [...]
Thanks, Tom, for another podcast!
I have to admit this one confused me a bit, and I’m still not sure if I understand what Glushko is getting at… My main hang-up is his definition of a document. Here’s Glushko in the introduction of his book:
“Documents organize business interactions and package the information needed to carry out transactions. The notion of documents as the inputs and outputs of business processes wherever they reside in the network is a technology-independent abstraction perfectly suited for the heterogeneous technology environment of the Internet.
“The essence of Document Engineering is the analysis and design methods that yield:
- Precise specifications or models for the information that business processes require.
- Rules by which related processes are coordinated, whether between different firms to create composite services or virtual enterprises or within a firm to streamline information flow between organizations.”
Being a technical writer designing, creating and maintaining technical documentation of software (and data-delivering platforms as it were), I find this too broad a definition to be useful.
His main definition points to what I know as “data” in “records” or “files” that can be delivered as “feeds” or imported via standard “protocols”, all of which are highly typified and standardized and require human intervention only in case of glitches.
Documents (and documentation by extension) in my world are less typified, they almost always require human intervention and are usually insufficiently specified, so the recipient frequently expected something else entirely.
So as a technical writer, I’m glad to be rather far removed from designing, creating and maintaining “documents” such as calendar events and syllabi. My marketable skills in IT are quite different: They only come in when different spheres need to be negotiated, connecting developers of software and customer care personnel to its users or vendors to prospects.
I actually think I’d take offense if someone asked me to define the “document” that’s the common denominator of 24 different types of calendar events…
Just my 2 cents, Kai.
Kai, thanks for the comment here. I have to agree with you about the obscurity. It’s hard to see exactly what he’s saying, which is why I asked for two examples. As I understand it, one of Glushko’s insights is that documents are actually transactions. A document isn’t just a form someone fills out, or a memo. The document actually represents a transaction that takes place between two people. Person A promises something, and person B takes up the offer, and they transact the exchange through a document. Because of the importance of the transaction in business, technical writers should get more credit and play more integral parts in the business process — we’re “choreographing” the interchange between customer and client through the documents we write.
Even a Paypal form is a web document. The customer wants to buy an iPod, so he goes onto eBay and through a PayPal form, quickly enters the correct information, and the result is that an iPod shows up at his or her door 2 weeks later. The clarity of the PayPal form, the speed, usability, functionality, and smoothness — all of this counts toward the perceived transaction. In this case, it’s a literal financial transaction too. But in many other instances the transaction is abstract.
But as far as “document” goes, my understanding is that it’s similar to the microformat — some type of XML model that gives best practices for a business practice. The XML is encoded into some type of form that structures the information against a schema. The structured information can be shared, reused, and syndicated. He mentioned the example of the calendar. Actually, the ical or vcal microformat (can’t remember which) is supposedly an XML structuring of calendar data that numerous calendar programs can interpret.
Well, this is my understanding. But I haven’t dug into his book or thought or researched this topic more.
[...] Interview about Document Engineering and the User Experience with Tom Johnson of “I’d Rather be Writing,” Recorded 8 May 2008 at DocTrain Conference, Vancouver BC. [...]
Wow, thanks for posting this! I’m a high school junior with plans to go into information technology in college, and this was a real eye opener for me – I have never heard of “document engineering” before. Granted, a lot of this was way over my head, but is this really the kind of thing I might have to know about and deal with? Very interesting, but I have to wonder if I might be getting in over my head! Again, thanks for this article as it did expand my knowledge and awareness in this field.
- Sally
Sally, this podcast covered advanced XML design that is uncommon in regular tech comm careers. Bob works on the cutting edge of XML. Don’t worry about having to learn this to break into tech comm. But if this is the direction you want to go, definitely learn more about it.