Infovark

We’re in the midst of prototyping the user interface for our Enterprise 2.0 application. I’d been seeking some inspiration, wandering various design and programming sites, when I ran across this phrase: “At some point during every programmer’s career, he or she becomes fascinated by typography.”

At least I think it went something like that. I can’t remember which blogger said it. That’s the curse of having one’s feed reader filled to the brim with interesting things to read.

I must have reached that point in my career, because I’ve spent the last week devouring Thinking with Type by Ellen Lupton. I found a glowing review of the book while checking out the I Love Typography blog, itself a great find during my one of my web wanderings. Now that I think of it, I must have run across the phrase while hunting for the typeface for the infovark logo at myfonts. Or was it fonts.com? Or fontshop?

Ah well, I was doomed to be a typography geek anyway. During my college years I worked on my university newspaper, The Chronicle. If you’ve got even a hint of journalism in your blood, you’re bound to spend a significant portion of your life considering the contrast between tracking and kerning, or pondering the subtle mysteries of grid layout.

If you’ve been bitten by the typography bug, there’s no better place to start than Thinking with Type. In a single slim volume, it gives you an overview of typography from the letterpress of Gutenberg to the Internet of today. Its three major sections touch on the essentials: letter forms, text blocks, and page layout. You’ll find diagrams, examples, and images throughout the entire work. I’ve found it as useful for design inspiration as for reference. The appendix is crammed full salient quotes, useful tips, and the meaning of all those editing marks that used to make my newspaper columns bleed red. To top it off, the inside cover of my paperback edition contained samples of all the major fonts described in the book. Find a place for it on your bookshelf next to Tufte’s Envisioning Information and Norman’s Design of Everyday Things.

Oh, our logo font is ITC Avant Garde Gothic, by the way. And I’ve now decided to program in Consolas, based on sound advice in the Hamstu’s typography of code. Or maybe Bitstream Vera…

Gord says: Ha! I write all my code in anonymous. (Sadly, everyone can still tell that it’s mine…)

Dan Keldsen has a great post on the Value of Enterprise 2.0, and social bookmarking in particular.

What’s the value of information locked away that nobody can ever find? (which happens all too often in ECM deployments) Tell me how you justify spending millions to manage buried content? And how the “high value” yet “work in progress” content can be completely unmanaged and flopping around in e-mail folders?

The problem with lots of the ECM stuff, as Dean and I were discussing today over pancakes, is compliance.

I suspect that, despite what folks may tell you, the “perception of compliance” is the real driver for ECM.

There always seems to be money to spend when it comes to not getting sued.

Enterprise 2.0 tools are not about compliance. In fact, they’re not really about “management” - they’re about productivity.

Here’s hoping that the prospect of success outweighs the fear of failure

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.

You know, I’m a pretty good life insurance customer. I’ve had one policy for the last 10 years, I don’t smoke, I’m young(ish), healthy, I’ve paid all my premiums on time, and so far, I haven’t died. I figure that makes me just the kind of customer that insurance companies want. You’d think my insurance company would want to take care of good customers. I’m sure that they do. And yet…

Without getting too far into the thrilling roller-coaster ride that is my finances, what happened was this. I wanted to change the way that I paid the policy from a monthly direct debit to an annual credit card payment. I rang my insurer and had a nice conversation which ended with them assuring me that it was all changed. They took my annual payment, and then later that week debited my account for the month anyway. So I rang them back, and we had a slightly less polite conversation, where they assured me that no, this was really changed, and that they were very sorry.

This process repeated itself for 5 months. Yep, Five. Each time this happened, I incurred a bank overdrawn fee of $35.00, and my conversations with customer service became increasingly less polite.

After giving up on the polite, friendly, and utterly ineffectual customer service people, I tried tracing the problem myself. It turned out that there were at least five different people involved, three from different sections of my insurance company and two from the company that had acquired my insurance company. The monthly account debit guys didn’t get the message that I’d changed my billing cycle. The collections people didn’t get the message that I’d actually paid the account in full. The guys who process the annual payments had no trouble whatsoever in charging my credit card the full annual amount, but forgot to update my account standing. Guess what? During the previous five months, none of them had ever talked to each other about me or my account.

So it became my job to coordinate the information flow internal to a company that was supposed to be providing me service.

Each one of the people involved in my story all treated my case as something different:

• a request to have a debit removed,
• a request to have a payment added,
• a generated request to take action for an overdue payment, and;
• several requests to handle a disgruntled customer.

The sad thing is that this sort of treatment didn’t surprise me. I’ve received the same treatment from the phone company, the cable company, and numerous other large organizations. In fact, the only surprising thing to me is how common this problem of disconnectedness is. I’m sure you each have your own horror stories to tell.

This “right hand not knowing what the left hand is doing” problem appears when functional barriers are imposed on the sharing of information, and an organization fractures to a point where any particular employee is unaware of the big picture.

The central cause of this problem is “Assembly Line” thinking — where it’s assumed that maximum efficiency comes from each person performing a single part of a greater task in isolation. (I think there are serious problems with treating your knowledge workers like robots. They get bored. They miss stuff. But that’s probably another post for another time.)

It’s tempting to treat this as an integration problem. The SOA process architects would see a failing of various systems to share the information between each other. But is the answer really more, bigger systems? Any one of the people involved in the process could have recognized what was going on very quickly if they had seen the whole context. People are natural pattern recognition engines. The best way to solve this problem is to increase the information available to the people. (It’s certainly not to build huge automated ‘expert’ systems that try to think. Then you just end up with no quack.)

Because Enterprise 2.0 tools capture this tacit, conversational context, hopefully they can help to solve this disconnect. Process-centric automation might work for building cars, but people function in social environments. Encouraging ad-hoc informal discussion between different sections increases the amount of context that people are exposed to.

The theory goes that more context leads to better awareness, and subsequently better decisions.