This page contains a Flash digital edition of a book.
Case Study


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.


Usability 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.


Participation Perhaps Google Wave’s most positive contribution to our team has been its facilitation


20 Research Information August/September 2010


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.


‘Each of us spends a few


hours a week participating in waves, and it has saved us almost twice that time in editing alone’


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.


Persistent patterns 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


www.researchinformation.info


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
Produced with Yudu - www.yudu.com