Google Wave - Victim of HCI's "Uncanny Valley" or Just Another Failed Software Project?

It seems that Google's decision to discontinue Wave has been has been making the waves (excuse the pun). Why did this happen to a product that was promoted as potentially being "the next big thing"? A product whose tech demo wowed the world, and had people clambering to get their hands on an "exclusive" invite to give it a test run themselves?

Here are some of my thoughts about some of the factors that contributed to it...

Firstly, let's perform some taxonomy, and examine the class of software Wave fell under. Wave was an example of a Computer-Supported Cooperative Work (CSCW) system, particularly of the synchronous+distributed variety (we'll get back to that last part later). However, if we look back a bit in history, we soon see that this very sector has been fraught with many trainwrecks: software that didn't live up to expectations, were seen as annoying, or just downright hated. Just like in CG, where there is the notorious "uncanny valley", where increasingly lifelike humanoid forms induce violent expressions of disgust, this type of software often has rather negative responses. There have been numerous books written about this topic. However, perhaps one of the most frequently used explanations for this phenomenon also explains some of the challenges that Wave experienced.

Earlier, I said that Wave was an example of a synchronous+distributed class of such programs. What this means is that users are (usually) not in the same room, but the software aims to facilitate realtime communication between these users and act as a platform from which they can collaborate on a shared "artifact" (i.e. a document). The current theories explain though, that the reason that such assistive systems break down is due to a lack of normal "other" forms of communication between participants (i.e. verbal/chatter discussing issues and/or issuing directives, deixis or gesticating at the artifact to aid common understanding) are missing from the interaction. Also, there is the problem of whether users are all looking in the same places, or whether they're restricted to only viewing a shared view thus reducing their ability to independently navigate to other parts of the artifact to examine it.

So, how does this all apply to Wave? Well, think back to the original Wave tech demo at Google HQ a few years ago. If you don't remember what happened there, go back and view the video. What happened there was, the tech demo had the demonstrators ON THE SAME STAGE (i.e. in the same room) using Wave to communicate with each other. Let's look at that again; although they were using separate machines on opposite sides of the stage, they were still in the same room, and communicating with each other directly as well as while playing with Wave. So really, we saw Wave being demonstrated as a synchronous+co-located system. When most of us try to use Wave though, we're really doing it in the synchronous+distributed way (barring those that did so at computer user-group meetings, etc.). As the theory would suggest, the loss of the "extra" communication channels really makes the experience "less fun".

Also, let's not forget another thing: it was a tech demo. Having done developed software for a few years now, created a few tech demos myself (see earlier posts on Bullet SoC Videos), and seen countless demos, I believe that there is such a thing as the "tech demo effect". What is this? The tech demo effect occurs whenever a novelty item (i.e. a piece of software you've never seen anything like or haven't touched before) is presented to you, often emphasizing its endearing aspects and "amazing" new features while smoothing over (if not really artfully skirting around) its Archilles Heel. Typically, the audience would (and rightfully should be, if sales depended on it) be amazed by the demonstration, and be biting at the bit to go out and get their hands on it. Inevitably though, the "amazing" new tool will turn out to be just as flawed as the next thing. It won't have half the appeal of the tech demo. And you know what, it's probably because you aren't doing a tech demo of it! ;)

However, the demonstration vs reality only contributes to some of the disappointment and dissatisfaction faced by many users who trialled the system. Where else did it go wrong then?

For many, the first time they used Wave, it probably had terrible performance. Terribly as in laggy - especially fairly standard operations such as scrolling. In these modern times where such actions are near instantaneous, this would be a fairly big turnoff for many people. Some of these problems were server-side: either the system was not really production ready yet for the numbers that flocked on at any given time, or some other flaws not known about yet. However, some of these were client side too, as the responsiveness varied greatly between different browsers (in my experience, Chrome was miles faster than Firefox, and still is, though I cannot say exactly if there were code differences for Wave between the two browsers which may have exploited certain slow-points of one browser). Referring to the demo again: it was fast and responsive there, as there were just 2 users, probably running on a dedicated server for just the two of them, and plugged in not very far away. The illusion of the infinitely fast machine (with tech demo aspirations) bites again.

Now, we turn out attention to the actual functionality of Wave. As Eric Schmidt has said, it appears nobody really figured out any good way to use it, or society hadn't caught up with the technology yet.

One such area was the: anybody can edit anything and/or add content anywhere in a wave. In a session I had with a friend (and also seen in a larger session with multiple participants, not all active at the same time), this actually turned out to be a bit of a nightmare, especially in terms of trying to keep track of when there was new stuff to take into account. Perhaps I just overlooked some option/tools which would have made this a breeze. But one thing was clear: it was not such a great substitute for traditional text-chat systems.

But perhaps the issues stemmed from us trying to treat it like systems we knew already. It's realtime capabilities really makes it feel too up-and-running for email-like usage (typically longer chunks of text). Meanwhile, as mentioned earlier, it wasn't that great for chat either. While writing this, I've just thought of using it for actual collaborative document writing - i.e. setting out some headings and trying to dump some ideas under each - but I haven't really tried doing that yet. If anybody has, it'd be interesting to hear what you thought, as IIRC I saw that they introduced such templates later on.

If we continue this line of thinking, we really get back to a question that should have been asked from the start: What problem(s) does this software try to solve? In a way, it seems that we once again have a solution to problems that weren't really problems. Or maybe it wasn't the solution for the problem at all. Typical of many new technologies (case in point: nanotechnology. Nano-fibres, Nano-particles, etc. Nobody can find a use for them yet, though we know how to make them!)

With these unanswered questions, it's probably best that we regard Wave as being yet another experiment on the road to understanding successful CSCW systems for synchronous+distributed computing. From Wave, we can perhaps see the types of things that didn't work, things that might've worked, and hopefully better define the domains within which such systems can truly find uses. So, while it could be considered a statistic of the embarrassingly high percentage of software projects that "fail" for various reasons, I'd say that it was more of a valiant attempt at performing a large-scale field study of a such systems built using our current knowledge of the problem domain. But as they say, for every success, there were many failures along the way.