Case Study Riding the wave helps
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, as Jeff Stewart recounts
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.
The alternative 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
www.researchinformation.info
platform development Understanding blips and waves
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
Research Information August/September 2010 19
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.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28