Basically, Google Wave is a full and natural merger of messaging, on the web. Before you say “oh, only that”, think this through. This is a pretty big deal. Put differently, this is messaging where:
- Conversations are a first-class concept, and each message is a part of a conversation.
- Each message can be presented by a different application.
Because Wave is on the web, the set of applications is come from all applications in the world (on the web).
E-mail clients can present “threads” that are something like conversations, but this requires a bit of guessing and fakery on the part of the client, and is easily confused. IM clients can present a log of messages - that looks something like a conversation - but does not work when you switch between devices. Given that email and IM servers know nothing about conversations, the clients do pretty much the best they can. If you know about conversations on the server, you can do a better job on the client.
When conversations are a first-class concept, there are lots of new possible functions.
On the flip side, the Google Wave folk have made some (common) missteps.
- Using new names for existing notions is sometimes useful, but more often not. Calling a conversation a “wave”, calling items (messages) within a conversation “blits” … I find this more confusing than useful. This reminds me more of talk from marketing folk than engineers.
- It’s Talk, on the
web. As a programmer, I get it - this is kewl! Writing a web
application that allows all participants to see each character
typed - is tricky. As a demo of tricky programming, this is sure to
impress. As a useful feature in a general use application - not so
much. Character-at-a-time message traffic is a huge load increase on
the server, and a disservice to the users. Think about:
- Locus of attention - the on-screen activity from updates to other users’ incomplete messages is sure to distract.
- Quality of expression - how often have you started writing a message, then revised what you said and how you said it, before sending? Do you really want everyone to see your missteps … always?
Note that both are a disservice to **all** participants - cool in a programming demo, not cool in a deployed application.
- It looks like Outlook. This was new and cool in 1997, but not so much now. Not at all sure this layout is efficient, especially given the changes in most-common screen layouts. In 1997 you would target 640x480, 800x600, and 1024x768 on 14” to 17” as most common screen sizes. Today you are looking 1280x800 on 14” or 15” as your minimum size, and 1920x1080 at 20” or bigger as common. Present and future screens have not so much new height, with lots of new width - in fact too much new width for text content. Seems a different presentation is in order.
- Mixed applications in one web page is cool and exciting as ActiveX was in the web browser in 1996. Viewed in terms of the good things it can do, ActiveX allows an open-ended mix of applications to present within a web page - very cool. The Microsoft folk were blindsided (as constructive, well-intentioned folk) as they did not consider all the bad things that could be done (and with ActiveX, very bad things are possible). The Google folk have lots of history to make them wary, and the scope for harm is much smaller, so likely little bad stuff get through. Still - do not underestimate the black hats. There are bound to be some exploits (though likely few and quickly suppressed).
In sum, a decent start on a great idea. I’d want to be pretty ruthless about overhead that takes height away from the conversation view. I’d drop the per-character updates. I’d drop the use of funky names for existing ideas. None are fundamental problems, and all are easy to address.