The “key mistake” was that all of the technical parts were poorly architected and horribly buggy, and then they tried to scale up the user base using a massive amount of marketing hype before their product or infrastructure could handle the load. As a result all the hyped-up customers were confronted by a terrible user experience, felt burned, and left. Without a completely different technical implementation from top to bottom it was bound to fail irrespective of how their marketing team “positioned” it.
The UI was a GWT app written in Java and compiled to JavaScript which suffered from inexplicable UI hangs and all kinds of weird bugs in every corner case (it would e.g. get stuck in states requiring a page reload to fix).
The “communication protocol” was opaque binary blobs of GWT stuff wrapped up in Jabber/XMPP (XML) but without really using most Jabber features. Basically not a designed protocol at all, just the most ad-hoc thing slapped together overnight, with XMPP used as marketing (because that’s “open”).
The server was some closed source thing only hosted by Google.
The original marketing claim was that this was all “open” and “federated” but it was not possible to run a third-party server, and it was not possible to implement a different front-end since the whole thing was coupled tightly to the GWT front end they had.
The big innovation was supposed to be that some fancy “operational transformation” magic would merge different users’ diffs so that everything could be edited collaboratively in real time without conflicts and with minimal bandwidth, but in practice what that meant was they just sent the full content of every message on every keystroke (where “full content” here includes a massive amount of protocol overhead wrapping the messages) – maybe the fancy diff research stuff was intended for some future update that never made it.
The front end really started falling apart horribly (slowing down to the point of being unusable) under any kind of larger group, because it hadn’t been architected to keep up with the load. From what I remember it mostly worked with about 2–10 people communicating in a group, and became entirely unusable with 50+ in a group.
Disclaimer: I was never a Wave expert, just some guy who tried to read their docs and play with their technology and ended up laughing and sadly shaking my head all the way through, and it’s been a decade now. Some of my recollection could be slightly off.
Maybe the tech was bad, but the marketing was worse. I never even tried Wave, so didn’t experience the bugs and bad UI, because I could never understand what it was or what family of problems it was trying to address.
Agreed. In the modern app world, it's not enough to have great or useful tech, it has to be branded and communicated properly, not exactly Google's strong points.
Even worse, I was super excited about Wave and wanted to use it for a project - but I couldn't secure enough invites for the project team, so my trial never happened.
The operational transforms were integeated into Google Docs later for multi-person editing (the Wave team was merged into Google Docs), and it works quite well.
The UI was a GWT app written in Java and compiled to JavaScript which suffered from inexplicable UI hangs and all kinds of weird bugs in every corner case (it would e.g. get stuck in states requiring a page reload to fix).
The “communication protocol” was opaque binary blobs of GWT stuff wrapped up in Jabber/XMPP (XML) but without really using most Jabber features. Basically not a designed protocol at all, just the most ad-hoc thing slapped together overnight, with XMPP used as marketing (because that’s “open”).
The server was some closed source thing only hosted by Google.
The original marketing claim was that this was all “open” and “federated” but it was not possible to run a third-party server, and it was not possible to implement a different front-end since the whole thing was coupled tightly to the GWT front end they had.
The big innovation was supposed to be that some fancy “operational transformation” magic would merge different users’ diffs so that everything could be edited collaboratively in real time without conflicts and with minimal bandwidth, but in practice what that meant was they just sent the full content of every message on every keystroke (where “full content” here includes a massive amount of protocol overhead wrapping the messages) – maybe the fancy diff research stuff was intended for some future update that never made it.
The front end really started falling apart horribly (slowing down to the point of being unusable) under any kind of larger group, because it hadn’t been architected to keep up with the load. From what I remember it mostly worked with about 2–10 people communicating in a group, and became entirely unusable with 50+ in a group.
Disclaimer: I was never a Wave expert, just some guy who tried to read their docs and play with their technology and ended up laughing and sadly shaking my head all the way through, and it’s been a decade now. Some of my recollection could be slightly off.