Collaboration is a Feature, not an App
When you need to know something at work, do you leave your desk to go to the "communication room"? More likely, you reach out and pick up a phone, or grab a keyboard and send some kind of message. We expect to have communication available where we are, in the moment that we need it. As we move into 2012, shouldn't collaboration be pervasive?
Today, collaboration is too often presented to a worker as the on-screen version of a separate room: an application that lives in an isolated window, opening into a parallel universe where people talk about the problems they're solving in the other windows on their screens. That's not only a bad idea, it's even already outdated.
Collaboration should be a feature of whatever application you're using to do your job, and it's far from futuristic to say so.
For example, in 2004, Autodesk Inc. introduced collaboration features embedded directly into its design and drafting tools. A threaded conversation about an issue or a change could be associated directly with that feature in a drawing, instead of being discussed in some separate chain of email messages.
In an eWEEK column inspired by that Autodesk announcement, I suggested other scenarios for the same kind of infusion of collaboration and community support – in applications ranging from food shopping to firefighting. (Putting the apostrophes back into that on-line archive entry is left as an exercise for the reader: I'm sorry, but I have no idea why they're missing.) Imagine going into the grocery store, telling a 'shopping assistant' app (via smartphone interface) that you want to make a seafood dinner for eight people, and having it suggest some recipes—based on that day's specials—and display an annotated floor plan showing where to find all the ingredients, along with recent customer contributions and related product reviews. How much more useful would this be, versus merely getting a "frequent customer" e-newsletter once a week?
In that same eWEEK column, I quoted Tim O'Reilly as saying that "the most successful killer applications are going to figure out how to have a social software aspect": he was right, not quite eight years ago, but it seems to be still news to many today.
New capabilities emerge, at first, as products, but they quickly diffuse and invade the world as ubiquitous product features. In 1918, Sears offered a "Home Motor" with a panoply of attachments: "Buffer and Grinder," "Churn and Mixer," even "Fan." You're looking at me and asking, "Why wouldn't you just buy a fan with a motor of its own?" Exactly.
By the same reasoning, why would you ever build a new application on a platform that requires you to buy a separate collaboration engine, finding tricky and brittle ways to connect it to every application? And to update those connections, piecemeal, on separate upgrade cycles in a portfolio of combinatorial explosion? Why wouldn't you just build databases in an environment that knows about user profiles and update events, or build applications in an environment that knows about "Follow"ing things – and that clearly labels your internal and your customer-facing conversations?
If someone is waiting outside your office to sell you a collaboration app, I'd like to propose that you pause a moment. Is a modern, but separate, collaboration app a lot like the quietest, most efficient, most powerful version available of a 1918 "Home Motor"? Is it merely an update of what's become a fundamentally obsolete idea?
Isn't collaboration a feature, not an app?
Licensed under Creative Commons Attribution-No Derivative Works 3.0.


