Infovark

We described how we’d apply web technology to the problem of locating a document in your organization. So how can we help you determine whether you were looking at the right version of a document?

Let’s continue the designing system we described in that earlier article. You’ve told the program which documents on your workstation have business value and it’s assigned each one of them its own URI. With addressable URIs, these documents are now available to your coworkers through a standard web browser. Now we need to implement version control to prevent conflicts and preserve document history.

Different industries use different terminology and products, but the basic principles of version control were established decades ago. In fact, most knowledge workers still rely on one of the oldest and most ubiquitous applications for lightweight version control: email. Since every incoming and outgoing email is time-stamped, it’s easy to figure out which version of a document is the newer one. The familiarity of email and its ease of use make it extremely popular, but it has its drawbacks.

First, it only works if your coworkers always respond to the latest reply in their inbox. If someone replies to or forwards an older email in the chain, it messes up the date stamps and all bets are off. You’ll usually see an exasperated email with a “PLEASE USE THIS VERSION!!!!” subject line following the mix-up. Another drawback is that it’s incredibly easy to break the chain of email. If you change the subject line or forget to always reply-to or cc the document owner, you’ll get skips in your version history. To prevent this from happening, most folks create a mailing list for their committee or project team, and all members are copied on each document revision, regardless of whether their input is needed or not. Which brings us to another problem, which is that you clutter your coworkers’ inboxes with paper-shuffling email, burying important communications amid a barrage of “Updated spreadsheet” messages. The final issue is that email attachments often get saved to the desktop during the editing process. In doing so, you lose the datestamp (and thus the version) information. You also set yourself up for that first problem, attaching an out of date copy to your next group mailing.

(For now, I’m ignoring the problem that gives your IT department fits, which is that email sends a copy of each attachment to every person that receives the email. There’s nothing like duplicated storage or wasted bandwidth to get the hardware and network guys going. Computing resources are precious, after all.)

Dedicated document management systems avoid the problems of email, but often at the cost of being harder to use. Where’d the file go? Is the document locked? Can I check it out? Whoops! I saved it but forgot to check in. Sorry about that.

So the ideal solution is one one that preserve the ease of use of email, while doing as good a job of keeping up with version history as a purpose-built source control system. Let’s roll up our sleeves…

Iterations

The most important version in our version history is the current version. This is the one that most of the folks on the project mailing list will want to see. That sounds like a great candidate to receive a URI, so that everyone can link to it or get a copy if necessary. Once we do that, co-workers can access the document through a browser, so it makes sense that we allow them to edit it or provide comments through a browser as well. The process of editing a wiki page or leaving a comment in a discussion forum or blog should be familiar to most knowledge workers. We’ll automatically save a new version each time someone does so. Now we’ve got a complete, permanently addressable record of all the changes made. So far, so good.

To match the user experience of email, we’ll ditch arcane wiki syntax. It can be tough to remember whether asterisks mean bold text or bullet points. We’ll implement a simple-to-use WYSIWYG editing engine in our wiki-like system instead. While we’re at it, we’ll also banish any of that check-in/check-out document management stuff. That just gets in the way, and we’re busy people. We can also forget about making people log in to leave comments. That’s important for the public Internet, but this is an enterprise solution. We can get your coworkers’ login info automatically.

One thing knowledge workers like about email is the ease of attaching documents. You don’t have to fool around with web-based file upload dialogs; you can simply drag-and-drop attachments on to the e-mail. For our hypothetical system, we can do better than that. Our program can watch the documents you’ve asked it to remember, saving new versions each time you make a change. It can even keep up with the document as you move or rename it. Though it might live in various different places on your hard drive, its URI will remain the same. That means that none of your coworkers’ links will break. It means you’ll have a continuous history of all changes made, whether you edited the document locally or whether your coworkers updated it through your personal wiki.

If you need to look at the previous version of a document, you type the URI that identifies it into your browser and include the date. The system will show you how the document looked at that time. It’s simple and there’s no version numbers to remember.

Notifications

Now wait a minute, you might think, email actually serves two purposes. The first is to attach date stamps to documents, but the other is to notify people that there’s work to be done. Purpose-built document management systems often have elaborate workflow engines that push notifications around (also through email, usually). How will our wiki-like system deal with that?

Email works fine to send notices; that’s what it was designed to do. There’s no reason to reinvent the wheel. Just copy the document’s URI into an email and send it. All the recipient has to do is click the link to get the document metadata or download the current version of the file. No problem.

In addition, our system has an alternate way of alerting people. Suppose I know that Tim is working on a PowerPoint presentation for an upcoming conference. I want to know when he’s done with it. I can either ask Tim to send me an email when he’s finished (I hope he remembers this time…) or I can check his personal wiki. It lists all of the documents he’s been creating and editing. As soon as I see that a new revision is ready, I can go get it.

In fact, we can do better than that. I can subscribe to Tim’s personal work feed using a feed reader. It polls his wiki automatically. I’ll know when he’s got new content ready for me to review. This works for both me and Tim. I can check periodically, when I’m ready for the next task on my list, and Tim doesn’t have to listen to my nagging. (Of course, I wouldn’t need to nag if he’d just remember for once.)

Summary

The ultimate goal is to create a system that keeps up with document revisions and notifies coworkers when changes are made. We propose a personal wiki that maintains unique addresses to each of your documents. It takes snapshots of each new version you create automatically and allows you to access prior snapshots by date. It also publishes a running list of all the changes you made.

We’ve now got a system that can help you locate important corporate information and find out when updates occur in real time. It requires a slightly different way of working, but should be at least as easy to use as email. It might even save you time and hassle if your coworkers get into the habit of checking your wiki for updates instead of asking you about them. That’s two out of the three problems we identified in our moving story solved. Stay tuned for part three.