MW-photo
April 13-17, 2010
Denver, Colorado, USA

Uses and Abuses of Google Wave for Collaboration

Jes A. Koepfler, University of Maryland and Joseph Maki, Software Engineer / Independent Consultant, USA

Abstract

In this mini-workshop the authors will showcase their experiment using Google Wave as a tool for 1) low-fidelity rapid prototyping, 2) record keeping, 3) establishing a consistent language, and 4) enabling both synchronous and asynchronous communication between an evaluator and a programmer. They will discuss the pros and cons of Google Wave, and then open the floor for questions and a brainstorming session on the possibilities of using Google Wave for work in the cultural heritage sector.

Keywords: low-fidelity, rapid prototyping, evaluation, collaboration tools, usability

The Situation

Right about the time Koepfler and Maki met at ASTC 2009 in Ft. Worth, TX, they each received their long-awaited Google Wave invites. Call it fate, call it Google evangelism, but they immediately found a use for it. It turns out that the two of them had been working on a large, multi-institutional project together for nearly a year, and although it was Koepfler’s job to evaluate the thing that Maki was building, forces beyond their control kept them from getting work done in the way they had envisioned. Further, the timeline for the project had become compressed and they needed to get work done quickly.

The task before them was rapid prototyping of the user interface for STEPS (Science Theater Education Programming System), an authoring tool for museum professionals to create theater-based multimedia shows. This task needed to happen without layers of management and bureaucracy, without slowing down the development process, and without involving too many people. Neither one of them had time nor patience for scheduling teleconferences and working within the constraints of the old “9 to 5”.

Enter Wave.

Without hesitation they saw Google Wave as an opportunity to conduct rapid prototypes of the visual components of the interface. Do the icons make sense? Do these tool tips help? Does the juxtaposition of this thing with that thing cause confusion? Can you tell what this is supposed to do just by looking at it?

Figure 1

Fig 1: Screenshot of the prototyping wave

Maki would post a screenshot and timeframe for when he needed feedback. Koepfler would review the interface; make visual interpretations of what the components seemed likely to  do; and request additional context if needed. When a second or third opinion was needed, or if that specific piece of the interface was already too familiar for Koepfler to provide a blind review, other individuals could be called in very quickly by adding them to the wave or by quickly copying the components of the wave into an e-mail.

Figure 2

Fig 2: Bringing additional reviewers quickly into the process, reviewer #2

 

Figure 3

Fig 3: Bringing additional reviewers quickly into the process, reviewer #3

This strategy for testing visual intuitiveness allowed Maki to share versions of the interface quickly without debugging and to push out full builds of the tool. This was crucial for a couple of reasons. First of all, it met the number one requirement of doing testing without slowing down the development process. From experience, both Koepfler and Maki knew that any testing that interfered with the programming timeline simply would not get done, regardless of good intentions. Second, it allowed Maki to continue to code and design in the medium of the future software while working at low-fidelity in the visual prototypes. That meant he was not designing a paper prototype of something that he would then have to convert into a programmed tool, for example.

Maki could also do A/B testing of two versions of the same thing at once.

Figure 4

Fig 4: A/B Testing

Some might say that there is no way usability testing can be done with just one other user, but others in the field would argue that testing with one person is always better than the alternative – testing with none (Krug, 2006 & 2010; Nielsen & Norman, 2000; among others). Further, this was just the first quick and dirty layer of user testing, based solely on visual intuitiveness, more like having someone proofread the graphic design of something. Cycles of task-based testing, debugging, and remedial beta testing are intended for the final year of product development.

The Joys of Wave in Beta

Not surprisingly, in the process of prototyping, other uses for Google Wave evolved.

Figure 5

Fig 5: Wave devoted to craft beers

In fact, the application itself continued to evolve, with new features being released and new extensions and gadgets being developed. Some potentially useful project management tools were collected into a gadgets wave. Below are examples of Napkin (http://my-wave-gadgets.appspot.com/wave/NapkinGadget.xml) and Planny (http://code.google.com/p/google-wave-gadget-planny/l). There are and will be many, many more to come.

Figure 6

Fig 6: Screen capture of Napkin gadget used in a wave. Illustration courtesy of Maki

 

Figure 7

Fig 7: Screen capture of Planny gadget used in a wave

Now that some practical and professional case uses for Google Wave have been made clear, here is the background story and how it works. Google Wave was developed by the same brothers who developed Google Maps: Lars and Jens Rasmussen. (That should be the first clue that it is an incredibly useful tool.) As the story goes, Jens pointed out to his brother that

’two of the most spectacular successes in digital communication, email and instant messaging, were originally designed in the '60s to imitate analog formats – email mimicked snail mail, and IM mimicked phone calls. Since then, so many different forms of communication have been invented – blogs, wikis, collaborative documents, etc. – and computers and networks have dramatically improved.’ So Jens proposed a new communications model that presumed all these advances as a starting point… (Rasmussen 2009)

The brothers asked themselves the following questions:

  • Why do we have to live with divides between different types of communication — email versus chat, or conversations versus documents?
  • Could a single communications model span all or most of the systems in use on the web today, in one smooth continuum? How simple could we make it?
  • What if we tried designing a communications system that took advantage of computers' current abilities, rather than imitating non-electronic forms? (Rasmussen, 2009)

After expanding on these ideas and testing prototypes, two years later Google Wave Beta emerged, first for developers on May 28, 2009, and then slowly for the ‘common’ people in the same way that Gmail was rolled out – through a painfully slow snowball invite process.

In Google Wave, someone initiates the wave and adds people to it. From there anyone can add images, documents, gadgets, downloaded extensions, etc. into the wave at whatever point in the wave that makes the most sense. Thoughts within conversations are easily collapsible, and there is a playback feature that shows how the wave evolved – particularly useful for project collaboration.

The Good, the Bad, and the Ugly

Koepfler and Maki have been using Google Wave for three months (November 2009-January 2010) at the time of this paper. They have formed some initial opinions on what Google Wave might be good for and what situations it seems clear it will not be as effective for (at least not in the foreseeable future). Wave may not be the “be-all, end-all” of text-based communication; not yet, anyway. However, it has already proven incredibly useful for a number of collaboration solutions.

Wave allows for real-time, persistent conversation. All contributions to a wave are live, and any contributions throughout the history of the wave can be reviewed at any time. Wave uses a system of threading which allows conversations to move forward on many fronts: replying to the top level of the wave is good for bringing up a new but related idea that should be explored. One can also reply to a reply, and start a sub-thread or conversation. Blips can be inserted into a reply in order to start a discussion on a particular sentence or idea.

Figure 8

Fig 8: Invented terminology for identifying parts of a wave

External to any individual wave is an inbox full of waves. The first level of organization that was addressed when Koepfler and Maki were creating their collaboration solution was creating a separate wave for testing and evaluation, apart from the general project talk. Once the evaluation wave was created, the two quickly realized that they needed to be somewhat consistent in the structure for replying to ideas within a wave so that the threading and flow of the conversation would stay clean and easily navigable. If a comment could be inserted directly into a sub-thread, this was the optimal choice, because these can be temporarily collapsed.

At times, interface review was only needed from one person as a check to confirm that a small change made sense. Bigger questions necessitated feedback and evaluation from at least one or two additional sets of eyes. In order to make these items stand out Maki began highlighting the requested timeframe for feedback in bright purple, so while scrolling through the wave any user tester could see the outstanding items. Once all of the evaluation was done, the highlighting was removed.

Figure 9

Fig. 9: Screen capture of highlighted timeframe for ease of wave navigation and outstanding tasks

In addition to its flexibility in terms of organization, Koepfler and Maki also found Google Wave useful for establishing a shared language. Various terms needed to be clarified from both the evaluation and programming perspective to create a common language (cf. Figure 2 above). Also, the goals of the evaluation and user testing were easily identified so that everyone could participate in the effort with an understanding of the underlying strategy and purpose.

 Wave supported remarkable turnaround times for the user testing (less than 36 hours for review from 3 individuals spread across the country): remarkable considering that at some points, there were participants ranging from Massachusetts and Maryland to California and Hawaii. Mashing up Wave with a quick e-mail to an additional user tester allowed the team to maximize its efforts.

Below is a list of just a few more “pros” the authors have identified in the past three months:

  • Fewer teleconferences. The small team did not have to plan or schedule their interactions/communications. This allowed for a more natural way of working together and administrative time saved. 
  • When multiple people were on a wave, it was possible to have a group conversation; however, it was also possible to throw something on the wave and get a well-thought-out response from someone the next day.
  • There was no requirement for responding to ideas in order. There could be multiple threads within a conversation, each evolving at its own pace, rather than forcing conversation about something that might not be ready, as sometimes occurs on teleconferences. 
  • Wave is a wonderful tool for record keeping. One only needs to explain him or herself once and the thought is recorded in context of a full conversation. This was particularly helpful during prototype testing when testers tried to remember the difference from one interface variation to another. Wave records the evolution of the conversation, so that everyone knows – even newcomers - how the product progressed from point A to point B.
  • Although some protocols were established within the evaluation wave, Google Wave allowed for easy enough clean-up of rogue blips and replies so that the team could have semi-structured conversations that allowed the process to be organic. Conversations naturally stray, and sometimes the resulting tangents can yield helpful ideas. On the other hand, unlike e-mail, true tangents and non-sequiturs could be cleaned up without ruining the conversation.
  • There was also a component of Wave that seemed to allow for more humanity in the text-based communication. Unlike the burden of having to proofread an e-mail before sending it, and the inherent danger of something in an e-mail being taken out of context, Wave was a more relaxed space for work (since society has not yet ruined it). Typos could be dealt with later (if ever) and any misunderstandings could be broached in real time. Indeed ,the notion of self-editing while typing would reduce the flow of conversation, because the other person would have to endure the backspaces even though he or she clearly knew what the intent of the statement was.
  • Because Wave is cloud based, conversations can be accessed from anywhere that has a browser, just like other Google services. Further, because it is HTML 5 and Javascript driven, it does not require plugins. Enough said. 

Maki summed up the use of Wave perfectly: Wave is for getting work done; not making everyone else see that you are getting work done. It is not a tool for micromanagement or layered bureaucracies.

Figure 10

Fig 10: Maki’s proclamation

And now for the list of “cons” or things that would make Wave a less likely solution for a given problem: 

  • People without the Google Chrome browser, or with considerably slow Internet, will find Wave very frustrating to use until it is out of Beta. In the same way that Microsoft builds its tools to work best on Internet Explorer, Google Wave was built to work on Google Chrome. Accessing it through Firefox, IE, or other browsers reduces its functionality and makes the application grind to a near halt.
  • People who are overly obsessed with heavy editing and proofreading of their own content should stick with asynchronous communications until they can train themselves out of it. Watching people type can be bad enough if the correspondent is a poor typist, but add to that frequent backspacing, and the experience can become dizzying. 
  • Micromanagers may panic at the use of Wave, because they are not privy to every detail of every conversation.
  • As mentioned above, Wave keeps a record of the evolution of a conversation, which means nothing is ever truly deleted. This could be a problem for some people, especially if it is ever used against them in the court of law. (Consider this the Surgeon General’s warning for just about everything on the Internet.)
  • Like other popular and well-developed tools on the Web, Wave can be addictive for the same types of people who are unable to discipline themselves away from things like Facebook and Twitter.
  • Although Wave is a better tool for the things that need to happen on the ground, users will probably still want to access a word processing tool to fancy up a memo report.
  • Due to the conversational nature of Wave, future users need to be prepared to blur the lines between personal life and work life. However, one strategy against this is to have a distinct work vs. personal wave, so that nonsense conversations can occur alongside deliverables-based efforts. 
  • One word – Beta. Currently, many features are not yet optimal, such as copying and pasting (it does not allow for specific selections within waves to be easily copied into a new wave), privacy settings (there is no way to kick someone out of a wave), scrolling and navigating (it is still pretty clunky), and backups (if someone decides to paste 300 lines of source code into a wave it can crash; not that anyone ever would…). Patience and open-mindedness are virtues of a happy Beta Waver.

Figure 11

Fig 11: Maki killing the first prototyping wave with 300 lines of source code

One of Wave’s greatest assets can also be one of its biggest challenges. Ideas and conversations in waves can move extremely quickly, becoming full-blown conversations or debates in a matter of minutes. Although they are much easier to catch up with than e-mail alternatives, the prospect of hopping into mid-wave for someone who was in a different time zone and still waking up while the wave conversation was happening, can be daunting.

Live typing has the potential to bring with it new issues of communication. One should be as careful and thoughtful when using synchronous chat as when speaking to a person directly, throwing aside old notions of self-editing in text formats.

Riding the Wave into the Future

So, should one use Google Wave to collaborate with friends and colleagues? Yes, most definitely. Should one try to convert everyone in his or her organization to using Google Wave for primary communications? Maybe not, not yet. Check back in another year. Should one give up on all other forms of Web-based communication – down with e-mail, down with Skype and gchat? No, probably not, although it is a lovely thought. In the end, like all other applications and new technologies, the key is to pick the right tool for the right job, and having Google Wave in one’s toolbox will only support the many collaboration and communication projects  facing users today.

For a few other views and perspectives on Google Wave (as of the writing of this paper), check out some of the links below:

References

Krug, S. (2010). Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems. Berkeley: New Riders Publishing.

Krug, S. (2006). Don’t Make Me Think: A Common Sense Approach to Web Usability. 2nd Edition. Berkeley: New Riders Publishing.

Nielsen, J. & D. Norman (2000). Usability on the Web Isn’t a Luxury. InformationWeek Online. Accessed January 29, 2010, at http://www.informationweek.com/773 /web.htm;jsessionid=3EOH41QEUGBBFQE1GHPSKH4ATMY32JVN.

Rasmussen, L. (May 28, 2009). Went Walkabout. Brought back Google Wave. The Official Google blog. Accessed January 14, 2009, at http://googleblog.blogspot.com/2009/05/went-walkabout-brought-back-google-wave.html

Cite as:

Koepfler, J. and J. Maki, Uses and Abuses of Google Wave for Collaboration . In J. Trant and D. Bearman (eds). Museums and the Web 2010: Proceedings. Toronto: Archives & Museum Informatics. Published March 31, 2010. Consulted http://www.archimuse.com/mw2010/papers/koepfler-maki/koepfler-maki.html