Travis Bradshaw

Steph Hannon, the project manager for Google Wave, recently tweeted:

Tweet me the feature or use case you think we should focus on for Wave in 2010! Need some ideas? http://bit.ly/6LMXRr

Executive Summary

The unsupported use-case that I’m starting to see the most is the Wave collaboration situation where the wave participants are working on a “thing” embedded in the wave and chatting at the same time.  This is an extension of the existing wonderfully executed use-case of “working on a thing collaboratively just like in email”, but changed in two ways: (1) the thing they are working on is actually embedded into—or is just part of—the wave, (2) the collaboration is real-time or very close to real time.

With those changes, it becomes difficult to keep the all of the “action” in the view pane.

Frequency

In collaborative works, the frequency of this use-case increases in direct proportion to the number of direct manipulation gadgets and the crowding out effect of wave vs instant messaging and other chat.  That is to say, the more people use sweet embedded gadgets to do their work, and the more people use wave to communicate during that process instead of instant messaging, the more often this use-case happens.  Considering the target use of Wave, this use-case may become a prerequisite to some growth projections (but likely isn’t yet).

Preconditions

The preconditions for this use-case are (1) the existence of a “stationary” collaborative object and (2) real-time collaboration.  A “stationary” collaborative object could be a “document” blip but most likely will be a rich gadget that provides a direct manipulation interface.  (Like some of the cool business process gadgets demonstrated already.)

Postconditions

The users have made a thing.

User Story (Unhappy)

The development team has decided to meet in a wave to work on designing their new thing.  The entire agile team of six developers is present and after a bit of wave-chat it becomes clear that illustrations are in order.  The project manager tosses a whiteboard gadget into the wave and doodling commences.  Soon, conversation and doodling becomes disjointed, as team members are unable to keep the discussion and the whiteboard on the screen at the same time.

But persevering, the team nails down a collaborative understanding of the vision of the thing.  Saving the whiteboard for later replay, the project manager then embeds the wicked-cool-whizz-bang design gadget.  With this gadget, the team can take the understanding gained from the conversation and whiteboard and actually start to design the implementation of their thing.

Unlike the quick whiteboard process, this wicked-cool-whizz-bang gadget is going to usher in a collaborative process that lasts several meetings and quite a few hours.  The conversation, additional whiteboard doodles, and the design gadget evolve over time, but become more disjointed as the physical space requirements increase.  No one can actually watch the modifications to the design gadget, the whiteboard, and the conversation all the same time.  Even playback is “jumpy”, as six collaborators are editing the wave in different places in the, now quite long, wave.  At this point, the measure of productivity is the wave is limited to the user proficiency in managing the wave interface rather than the domain knowledge in question.

Possible Happy Path Implementations

1. Split windows allow multiple real-time views of the same wave.  When a “static” element of collaboration appears (like a whiteboard), users are encourage to make a horizontal split window and dedicate the top window to the whiteboard.
2. “Sticky Blips” hold both a location in the hierarchical document structure, but are also “floated” by the renderer to remain on screen and slide with the view pane as it is scrolled.
3. “Wave containers” allow multiple “waves/branches/documents/need-new-word” to share the same metadata like members and the same playback history tree.  The project manager then creates a wave container with conversation, whiteboard, and whizzbang branches that can be opened in separate panes by participants.  Importantly, playback renders the coevolution of all three documents.

Conclusion

A mechanism to allow multiple “branches” of a collaborative wave to be viewed simultaneously would greatly increase the usability and productivity of collaborative environments in wave.  Wave is a convergence technology that brings many capabilities together, it’s important for collaborative groups to have an easy way to use many of those capabilities at the same time.