In all three generations of the Web ("pre-", 1.0 and 2.0) collaboration has been hard to do and even harder to explain. Take it from me, I was part of the birth of Lotus Notes. It's no secret that for years, despite Notes' spectacular success, Lotus was hobbled by its inability to clearly define the "groupware" collaboration category it was pioneering.
Today's technologists are in much better shape as far as understanding collaboration and the requirements it imposes on applications, systems and Web services, including social media. But that doesn't mean that businesses and individuals understand it--or have already baked that knowledge into their evaluation and procurement processes. Far from it.
Wait a minute, you say, what about Microsoft SharePoint? True, SharePoint's on a bit of tear, but I submit that it has been held back by the same brick wall of collaboration that Notes was. Had SharePoint conquered the collaboration bogeyman, it would have been truly ubiquitous by now--10x or 20x its current installed base and would have been embedded in Windows 7 as a result. No, I think the main conclusion to drawn from the fact that Notes/Domino and SharePoint are the only collaboration solutions to be successful on a massive scale in the last two decades is that this collaboration stuff really is hard.
Google Wave will focus a LOT of attention on collaboration and learning about all its aspects. Three researchers at McKinsey & Company have got a running start at this. They've put together a primer brief on collaboration on their What Matters site that seeks to define it starting from the vantage point of what types of software and Web apps support the specific tasks of people performing different kinds of work. This is a really good idea and something social media vendors rarely do--present their services based on problems and utility rather than feature punch lists. They've listed 12 job types, and even created a handy (if not visually gorgeous) flash animation that allows you to quickly traverse the roles and see the task lists they've created for each.
McKinsey's tutorial can be helpful background for anyone trying to get their arms around online collaboration in general and Google Wave in particular. The first step to "getting" Wave should be understanding the sets of problems it can solve and what applications it has. (If you start with the solution, you're peering down the wrong end of the telescope.)
A lot of really smart people are testing Google Wave and reporting, fairly universally, that they feel a bit adrift. They don't know what to expect, or how to tell when THEY or WAVE are performing as expected. There's a lack of user context. A certain amount of this comes with any new app or Web service, but when the service involves functionality with no clear offline metaphor, adoption is going to be a struggle.
Translation? Steep. Learning. Curve.
While Google Wave is a logical successor to Lotus Notes--it's also its opposite. Where Notes, despite all its enhancements over the years, pretty much dictates to you that you must learn the system and adapt to it, Google Wave, as near as I can tell from the reports, is the opposite in the sense that it provides a lot of choice and flexibility to the user. From an ease-of-learning standpoint, if a system is difficult to learn, one wants it to suggest the easiest and best ways to interact with it--if not impose the best ways. Given too much choice, coupled with a lack of offline metaphor, many people quickly get overwhelmed and frustrated.
Since collaboration by definition means two or more people are communicating, it introduces another element. You and the person you're working with both have to agree on how to interact with the system, in order for the system to facilitate your collaboration. In a system with many possible choices and ambiguous pathways, there are more chances for mismatch. The old way around this problem was simply to make a design decision and dictate to the users to work X way. That approach, though it still may be valid if you have an elegant UI that tests well as being user-friendly, is out of favor.
Now the default design view assumes we're all tinkerers and bit twiddlers, who won't stand still for any rigid, inflexible rules to be imposed on us. I don't know if we really are all tinkerers, I suspect not. But I do know it's easier in many ways for developers to provide services that are small and loosely-coupled than it is to make assumptions--which might prove wrong--and then hardwire them. Hardwired mistakes are expensive to fix. But the other side of that coin is that apps with ambiguous pathways and high flexibility can be harder to learn.
At the heart of Google's biggest successes has been the ability to make extraordinarily complex things simple. Like the original Google search bar itself. But the farther they stray from that formula, the tougher the sledding. You can't blaze new trails in online collaboration, and invent entirely new ways of working together lacking in prior metaphor while simultaneously keeping things simple. It can't be done. Collaboration is hard, complex and rooted in interpersonal communication preferences involving things like style, habits and these quirky things called human beings.
Google Wave just might turn out to be a first for Google. But not the one they intend. It might turn out to be their own Vista. I mean that in one sense only: it just might prove really hard to get tens of millions of users to use it--even for Google.
Recent Comments