MetaPress has recently launched a beta version of a new content management and hosting system, Mozaic. To help share ideas about this major project, the company's R&D team turned to Google Wave but since this article was first published Google announced it will stop this tool. Jeff Stewart describes the benefits of using Google Wave in development and invites readers to discuss the impacts of Google's new decision
Google Wave has garnered a substantial amount of speculation and scepticism since its modest preview release in September 2009. Early adopters have been eager to liken it to instant messaging, wikis, and even email. But despite big ideas about its potential as a game-changer, it has suffered an undercurrent of doubt regarding its practicality in today’s ecosystem of socially-connected tools.
MetaPress Research & Development began using Google Wave in November 2009 as a supplement to the team collaboration tools that were already in heavy use. We were attracted by its novelty and motivated by shortcomings in our wiki, to which Google Wave has proven a compelling supplement.
Our software development team began using Google Wave to help in our development of a major new content management and hosting system. Our team comprises one project manager, a business analyst, a quality assurance engineer, and five software engineers. It is a particularly ‘flat’ organisation that depends on frequent transfers of knowledge between members. We also believe strongly in capturing design decisions as they are made.
When we started the project in 2008 we initially turned to tools that were familiar and had proven fruitful in the past for keeping a chronology of the project’s development. The project’s scale was our most pressing concern, as it constituted the largest system by far that our team had ever been charged with building. We decided that a wiki would be the most effective way to organise our research phase.
We tailored our use of the wiki with an eye toward the future, imagining that the body of content we captured would evolve over time into a thorough, vetted knowledge base for the project. Our foresight seemed to pay off in the beginning: the wiki was a good vehicle for capturing early designs and rationales. It also proved useful for disseminating information, and was an oft-referenced primer for people new to the project.
However, since the early days of the project, use of the wiki has declined significantly. It facilitates collaboration to a much lesser degree than we had hoped for. When this problem became apparent, we tried to salvage the wiki’s utility by changing our use patterns or applying ad hoc layers of organisation on top of a growing mountain of captured knowledge. Meanwhile, the team found it increasingly difficult to remember why certain decisions were made (despite many being documented in the wiki). Discussions and work were needlessly repeated.
Google Wave has offered an interesting alternative (see panel, right). Although we were hesitant to use a product that had been described in media reports as a radical departure from existing tools, our team has endeavoured to learn whether Google Wave could address two of our biggest pain points regarding the wiki: usability and participation.
We began using Google Wave as a discussion tool – a forum in which team members could capture long (typically technical) discussions. We are slowly adopting it for more formalised documentation, but that practice probably has a long way to go before really catching on.
A typical discussion held in Google Wave involves brainstorming and evaluation of low-level design decisions. It resembles a transcribed meeting, with clear indications of who said what and in what order they said it. Perhaps most importantly, it allows us to review the reasoning that led up to important decisions.
This model was a dramatic departure from our experience with our wiki. But its similarity to email and its reliance on direct interaction contributed to soothing one of the pain points of our wiki: the mechanism for editing content.
One of the biggest advantages of Google Wave that we have found is in the editing time. As our wiki has grown, so too has the amount of effort required to edit it in meaningful ways. For example, curation – keeping the wiki’s content ‘fresh’ – is an ongoing exercise that has become increasingly difficult as pages have grown in size. Edits must be performed without the aid of the WYSIWYG experience available in some of the more recent wiki products available today. Wikis exist to be edited, but doing so now seems to require more time than our small team can expend. We attribute this mainly to the amount of effort required to make changes to the wiki’s underlying markup language, which is both difficult to interpret and error-prone.
We have found Google Wave to be more usable than the wiki for this reason alone, demanding far less time and concentration to enact changes that may only be several words long. Google Wave allows us to change and format text directly using familiar word-processing idioms that are less disruptive to our thought process. Each of us spends a few hours a week participating in waves, and it has saved us almost twice that time in editing alone.
When contributing to a wave, deciding where to add content requires some decision-making. We find that our waves assume different ‘postures’ that span the formality spectrum from ‘document’ to ‘chat’. Waves may start anywhere on that spectrum, with our larger discussions usually beginning with verbose ‘main blips’ that are intended for review and comment. On the other extreme are the waves that begin life as a series of short questions and solicit discussion. In both of these cases, choices made by contributors affect the growth of the wave and cause it to transition among these extremes. Intuition has so far served us well in producing meaningful waves.
Perhaps Google Wave’s most positive contribution to our team has been its facilitation of ‘virtual meetings’ that both capture important decisions and are schedule-free. These aspects made Google Wave inviting. They also address a substantial pain point of our wiki: the team wasn’t engaged in it.
Many months into our project, it became clear that only key decision makers were authoring the bulk of the wiki’s content, albeit prolifically. These authors observed that other team members tended to regard wiki content as ‘final’, rarely offering contributions of their own. When asked why, the would-be contributors intimated that they didn’t feel ‘qualified’ to alter any of the content or felt further discussion was not being solicited. Even when the authors encouraged more review, comment, and questions from the team, participation remained low.
Our wiki also lacks any built-in mechanism for presenting ‘dialogues’ between authors. Any attempts to represent such dialogues through formatting (e.g. through indentation or text colour) were clumsy and quickly abandoned. The authors would often try to verbalise the discussion instead, but this invariably resulted in important decisions going uncaptured.
We view the other obvious option, email, as inadequate for long-term knowledge capture. It cannot be easily referenced from outside the email client, is unavailable for hyperlinking, is notoriously difficult to search, and tends to impose linear thinking on what are typically non-linear discussions.
The wave structure unites these alternatives. We retain concepts of identity and chronology familiar to us from using email and we are unconstrained in creating long-form, context-rich content that may be subsequently refined and improved. Google Wave has been conducive to participation mainly by facilitating long conversations between team members.
We are also able to search these discussions far more effectively than we could before too, because Google’s search engine is far superior to the one built into our wiki.
However, not everything about the way we work has changed with the introduction of Google Wave. Our team continues to prefer not editing others’ words, even though most or all barriers to doing so have been removed. Instead, people are happy to add conversational comments and annotations that weren’t practical before.
Deleting content is another activity that we continue to avoid for fear of irrevocably losing important information. Meanwhile, just like our wiki pages did, our waves are rapidly growing in size and number. There is a palpable sense of impending overload that is familiar from our early days with the wiki. It remains to be seen whether the increased capability of Google’s search engine is a match for the increased rate at which content is produced. But while we have always been beset by a need to organise the wiki’s content, there is less urgency to do so in Google Wave. Each participant is free to view the ‘big picture’, via folders and saved searches. Just as we don’t see the need to impose organisational schemes on each others’ email, we don’t see the need to enforce an overarching organisational schema in our wave activity.
Positive, but not a panacea
Still classified as a ‘preview,’ however, Google Wave is not a complete substitute for all our documentation needs. We still need to use the wiki, although mostly to expose captured information to development partners who do not yet have access to Google Wave. We also use it as a reference for older design decisions that we have not yet taken the time to ‘move’ to Google Wave. Our wiki also has an issue management and tracking system integrated into it. Developers use this part of the system to manage their workloads and managers use it to get at-a-glance assessments of projects. Google Wave cannot yet replicate this blended component. In addition, stability remains an issue, although this should be expected considering Google Wave’s release status; under heavy use Google Wave crashes often, although we have encountered no data loss as a result.
Our team has enjoyed significant time savings using Google Wave to share knowledge. Reliance upon it should be guarded until it matures, but we recommend it as an approachable tool that deserves review by groups seeking to enhance collaboration among their members.
Jeff Stewart is development manager for MetaPress R&D
Shortly after this article went to press, Google announced that it would cease development of Wave.
Google's senior vice president of operations, Urs Holzle, said that while much of the technology that powered wave would be carried forth into other Google products, the Wave product proper with which so many users have become familiar may not be available beyond the end of this year.
The impact of this announcement on my team is substantial. Since writing this article, we have grown even more accustomed to Wave as a superior alternative to our wiki, email, and the "all-hands" meetings that previously consumed so much of our time. Furthermore, Google's incremental enhancements to Wave-some released as recently as two weeks ago-streamlined the integration of Wave into our workflow and made it easier for colleagues to adopt it. Now, as we face an unwelcome return to the other tools I described in my case study, Wave's merits become even much more apparent as we recall the time and effort required to disseminate knowledge using the old tools. Perhaps Google won't realise what we had until it's gone.
Having used Google Wave to great effect to capture specifications, customer feedback, and group discussions, I now have to find an alternative that suits my team. (After reviewing some candidate solutions, I'm not optimistic that one exists.) Meanwhile, the substantial body of content my team has captured so far must be extracted from Wave before Google deactivates the system entirely. Google's announcement suggested that tools would be made available to "liberate" data from Wave prior to its closure, but no further details were given, leaving users such as myself with an unpleasant feeling as we contemplate a grueling copy and paste effort.
The screenshot shown here (prepared with the assistance of Gary Coker, director of MetaPress R&D) illustrates most of Google Wave’s key constructs.
‘Waves’ resemble email discussions. Participants are able to continue the discussion by replying to the wave. Unique to Google Wave, however, is the ability to insert those replies almost anywhere in the wave’s space.
‘Blips’ are individual contributions made by participants in the wave. Replies are executed with respect to a specific blip whose characteristics affect the position and indentation of the reply.