I really wanted to like Google Wave. But after several months of attempting to use it in a variety of ways, I’ve come to the conclusion that the current incarnation of Google Wave is too fundamentally flawed to be useful. That said, Google has made it very clear that Google Wave is still in preview release, so I hold out hope that Google will radically revamp the service. I think Google is aware of these issues, since a Feedback survey link just appeared in Google Wave itself, and many of the questions seem to acknowledge that users are wildly unhappy.
Here are the things I attempted to do in Google Wave, all with some level of frustration and relatively little overall success.
Basic Communication — Google Wave is often put forth as a rethinking of Internet communication, a mashup of email, instant messaging, and more. It’s difficult to test Google Wave in this way, however, for the simple reason that it’s not email, and it’s not instant messaging. Everyone with whom you want to communicate must have a Google Wave account, and although those with Google Wave accounts are given invitations to hand out to friends and colleagues, the fact remains that most of the people you’re likely to want to communicate with are not using Google Wave now. As a result, you’ll never think of using Google Wave as a way of contacting someone.
Worse, my experience is that even tech-savvy people like those I work with seem generally dubious of Google Wave, and that’s even before they’ve gotten into the system. Getting someone signed up with Google Wave is often an exercise in hair-pulling frustration requiring multiple back-and-forth email messages as you send an invitation, request their Google Wave account information (which is a pseudo email address @googlewave.com, not any other Google account or email address), add them to a wave, and explain some of the basics of using Google Wave. And again, these frustrations occurred when working with some extremely savvy tech writers and programmers, not everyday users.
The next problem, also related to the fact that people aren’t already using Google Wave in a big way, is that essentially no one checks their Google Wave account regularly for new waves or replies. So you can’t guarantee that anyone will even notice communication happening in Google Wave. For a while, I worked around that with an extension that people could use to request email-based notifications of changes; now Google has announced that it’s building email notifications into Google Wave itself.
The other workaround is to use a program like Waveboard (see “Catch a Google Wave with Waveboard,” 30 October 2009), which adds a variety of local notification methods, including Growl, Dock icon badges, and more. But still, convincing someone to use Waveboard and keep it running all the time for Google Wave is an exercise in futility.
One last concern – although you can mark waves as being public and thus available for anyone with a Google Wave account to see and comment on, that struck me as just weird. I can’t see Google Wave as a publishing system like a blog or even Twitter; it seemed too random for that since there isn’t the context of a blog, which generally revolves around a topic or a person or an organization, or the implied personal context of Twitter, where people follow those who have interesting things to say. Neither email nor instant messaging have this concept of public posting to an entirely random audience, and without some major changes, Google Wave’s approach is inherently confusing and unsatisfying.
Group Planning — At Macworld Expo in San Francisco last month, I moderated a panel on email clients. For that, I needed to explain to all my panelists what the panel would be about, how I was planning to organize it, and what I expected of them, besides their usual scintillating conversational skills. Such discussions normally take place in email, but in my experience, they often quickly derail, such that one aspect of the discussion receives disproportionate attention, and the rest are largely ignored. Also, because the conversation happens months in advance, as the date approaches, it can be difficult to recall what was decided.
So I decided to hold the conversation in Google Wave, figuring that it would serve as a semi-permanent record of what was said, presenting all my points at all times, rather than letting my panelists focus on one thing to the exclusion of all others.
This was perhaps the most successful of my Google Wave experiments, since everyone got in there and read what I wrote, at least at first, and there was some discussion that helped me refine my approach to the session. But after the initial chatter died down, no one but me visited it again, which emphasizes Google Wave’s notification problems, and perhaps points to my desire for a semi-permanent record not being as important as I thought. And, as the date came very close, I still ended up having face-to-face discussions about the session with each panelist individually to make sure we were all on the same page.
In the end, this task could have been handled in email just as well, if not better.
Document Collaboration — This is a topic near and dear to my heart, since I do an awful lot of collaborating on TidBITS articles, both as a writer and as an editor. The basic approach was simple – I’d start a new wave, paste in the draft of an article, invite reviewers, and then respond as they made comments. At the end of the process, I’d copy the text out of Google Wave (since there’s nothing useful you can do with it otherwise).
The theoretical benefit of Google Wave for document collaboration is that everyone in the wave could either make changes directly in the text or could leave comments that could turn into discussions with other reviewers. The concept was great, but it didn’t work well in practice.
Although you can edit any part of any wave by double-clicking it and clicking the Edit button in the Reply/Edit lozenge that appears, it’s difficult for other people to see the changes you’ve made. If they’re watching in real time as you edit, it’s possible to see changes happening, and the other approach is to use Google Wave’s playback feature, which steps through the changes each person makes. But that’s horribly clumsy, since you have to take a step in the playback, scroll through the document looking for highlighted changes, and then take another step. Since the playback records replies separately from edits, when one reviewer would make some edits, then insert a reply, and then some more edits, and so on, it resulted in many different steps in the playback to consider.
As a result, Google Wave worked acceptably only when the textual changes were minor. If more significant development editing was necessary, its text-handling and author-marking tools simply weren’t up to the task. In one case I found myself pulling text out to EtherPad where it was obvious who was making what change.
The replies were troublesome too. If you double-click in the document and click the Reply button in the Reply/Edit lozenge, Google Wave sometimes inserts the reply in the middle of sentences, or between a bullet and its text. The only way to guarantee that a reply follows a paragraph or comes at a certain point is to select some text, double-click the selected text, and then click Reply. I found that I had to explain that technique to everyone I invited to a wave, or risk a significantly more confusing layout.
Another problem with replies is that it’s difficult to control whether or not they were hierarchical to one another. In general, if you reply to some text in the initial blip (an excellent name for the units of text in Google Wave, by the way), your reply is indented under that blip, unless your reply comes at the very end of the blip. Replying to a reply generally does not indent your reply, unless you selected some text in the reply first. And it’s tremendously easy to create a reply when you don’t mean to, or in an incorrect location, forcing you to delete the just-created blip.
The fact that Google Wave shows you when others are typing sounds cool, but was generally irritating, since I could tell what someone was going to say before they finished typing. I ended up responding before they finished, which I’m sure was annoying, but I just couldn’t resist. iChat’s approach of indicating that someone is typing without actually showing it works better, since then you respond to fully formed thoughts.
Switching back and forth between editing and replying is also cumbersome. There is a keyboard shortcut (Shift-Return) that lets you avoid scrolling to the bottom of a long blip to click the Done button, but even still, switching between editing and replying modes requires conscious thought that’s not necessary in most programs that allow editing and commenting, even long-standing ones like Microsoft Word.
Finally, there is no good way to mark replies as having been viewed, so you could avoid seeing them in the future, or to hide them entirely so you could look at the document without them. Once again, Microsoft Word’s change tracking and commenting features put others to shame, even if it has no collaboration capabilities at all.
One unexpected positive about using Google Wave for document collaboration was that when I selected the text of an original blip and copied it out to BBEdit, I got only the text of my now-edited draft, not all the interspersed replies. That’s what you’d want, of course, but you would have no idea that it’s possible without trying it. And, although this worked for me, one other person was completely unable to copy text out at all for reasons we never determined.
In the end, Google Wave proved far more frustrating for document collaboration than Google Docs or EtherPad (now owned by Google too, see “EtherPad Open-Sourced after Google Acquisition,” 4 December 2009), or even the venerable QuickTopic Document Review. In Google Docs, editing is much easier, but commenting and discussions are extremely clumsy, and change tracking and versioning aren’t great. In EtherPad, change tracking and versioning are generally well done, and discussions can take place outside the document in a separate chat pane. And in QuickTopic Document Review, which we rely on for Take Control ebook technical reviews, commenting is easy, but there’s no way to edit at all.
Project Management — My next attempt was to use Google Wave for project management for our forthcoming account management system. Email was working poorly because if someone disappeared on a different project for a few days, they often had trouble remembering what tasks remained for them to do, or forgot discussions that had taken place much earlier in my project. Plus, as with my group planning experiment, I wanted to create a system where discussions could become detailed on one topic without losing track of others.
To this end, I created a wave shared with Glenn Fleishman, our technical guru, and Adam Khan, our freelance ExpressionEngine developer, and I outlined all the tasks. The idea was that I could create a task and spec out its associated feature in a blip. Then, if Adam or Glenn had questions or comments, they could reply inside that task blip, and I could reply back as well, keeping all the discussion together and coherent.
By this time I had the email notification add-on working, so we could all be alerted when there were changes, which helped keep us all on track. But even with that, I found myself resorting to email to ask how things were going, since there was no way to know if the others were seeing my changes.
The real problem, though, was in overload. The wave ended up with nearly 200 messages by the time we abandoned it, and as you can imagine, there could be many replies under each item. That was fine at first, but as tasks were completed, there was no good way to hide them and their associated discussion. You can delete blips in Google Wave, and you can see the deleted ones in the playback, so they’re not lost forever, but since you would be deleting other people’s words, it felt wrong to do so. Plus, it was unclear if it would be easy to find something again, once deleted. You can also collapse a thread of replies, but Google Wave wouldn’t retain that collapsed state the next time you come in.
And more to the point, there is no real way to assign a task to a particular person (we used initials at the start of the task description), no coherent way to see what needed attention, and no real way to mark a task as completed (we used a checkmark in front of the initials). In other words, it worked, but proved only slightly better than a straight text document in Google Docs. (We’ve done that too; it’s also awkward and painful.)
In the end, we moved the project to a project collaboration site called Manymoon, which has features roughly similar to the popular Basecamp project collaboration site, but which can be used for small stuff like this for free. Manymoon makes it easy to create tasks, assign them to particular people, leave comments on the task (the most important feature, in my experience), notify all members of the project of changes and comments via email, view tasks by user and status, and mark them as done once completed. If you’re looking for a project collaboration site, Manymoon is definitely worth a look.
During this process, I tried using Google Wave to manage several other projects where I thought there might be a fair amount of discussion, but in each case, it basically became a roach motel where I stored information and everyone else took one look and ignored it afterwards. Those projects will also be moving to Manymoon at some point; I’m not worried about losing what I did in Google Wave, but I simply can’t (and don’t want to) force all the parties involved to use it.
Anti-Network Effect — All things considered, the main problem with Google Wave was that it wasn’t compelling enough to create a network effect, where the fact that some people were using it was enough to lure others to use it. In nearly all the cases where I invited someone to a wave, I got some level of pushback, whether or not the person already had a Google Wave account. Since TidBITS relies largely on persuasion rather than commands from on high, the consistent (and considerable) lack of enthusiasm was an insurmountable obstacle.
It seems as though Google may be aware of this problem from the way in which they introduced Google Buzz as part of Gmail, which ensured that Buzz would have vast numbers of users from the beginning. Unfortunately, Google went too far in that direction, since lots of people didn’t want Buzz turned on, and vastly more had no idea what it was.
Google should listen to the developers of the recently acquired EtherPad, which did a good job of eliminating the need for accounts, making for a very lightweight system (in EtherPad, the creator of a pad simply shares a URL to the pad via email or instant messaging or any other medium). The ideal middle ground for any system like Google Wave or Google Buzz is to make it dead simple to join without doing anything special or signing up for anything else (just because I might want to use Buzz doesn’t mean I want a full Google account) while at the same time making the service sufficiently compelling and viral that people want to sign up in droves. That has worked for Twitter and Facebook, and countless other systems that rely on the network effect. I realize Google Wave is a slightly special case, since it’s designed as a protocol and server that could be run by any organization, but even still, it has to be lightweight for adoption to occur.
I’m almost hesitant to make concrete recommendations for Google Wave, since it has seen so few significant changes since its introduction that I wonder if Google isn’t working on a major revision behind the scenes. But I think my criticisms above should lend some insight into the kind of changes that would help. Other thoughts:
- Invitations to a wave should be by URL, sent via email or instant messaging or any other means, and if Google wants to make it easier, invitations should tie into your existing contact list.
- Google Wave shouldn’t require an account for those invited to join a wave, and if someone wants to create an account, it should for now be associated with existing Google accounts, and not be entirely separate.
- For those who already use Gmail, Google should think about non-intrusive ways of integrating Google Wave into Gmail to eliminate the notification problem and create a bit more of a network effect. For those not using Gmail, email notification is a must.
- Though seeing people typing in real time can be useful, the feature should be optional, to allow people to finish a thought before others reply or comment on it.
- The interface for switching between editing and replying needs to be both more obvious and faster, and the constant creation of inadvertent replies should be eliminated.
- Google Wave should remember if you have collapsed a blip and not show it again unless it gets new traffic, or even collapse replies after they’re read, just like an email conversation in Gmail. There should also be a way of hiding all replies completely, so an edited document can be read without interruption.
- If Google Wave is to be useful for document collaboration, it has to be able to publish a wave to other formats and mediums, such as email, straight text, RTF, HTML, to a blog post, or to a content management system. Copy-and-paste is not an interface.
- Blips should be allowed to have user-defined metadata like completion status, task assignment, and due dates so Google Wave could become useful for task and project management.
These are relatively minor conceptual changes, though I freely acknowledge that they could require significant architectural and interface modifications. As such, I can’t say that I’d be happy to use Google Wave even if Google were to implement all of them, but I’d certainly return with fresh enthusiasm replacing the frustration Google Wave has caused me thus far.