Google Wave: Like Email, Only Different

Ars Technica reports: Many of the underlying standards that define modern email technology were originally developed in the 1980s. Almost 30 years after the birth of SMTP, email is still the dominant Internet communication medium despite its significant limitations and increasingly anachronistic design. Supplementary services like instant messaging and microblogging have emerged to fill in some of the gaps, but virtually no attempts have been made to build a holistic replacement for email. Our most important day-to-day messaging infrastructure remains intractably mired in antiquity.

To advance the current state of Internet communication to the next level, it will take a truly audacious vision and highly sophisticated technology. The engineers at Google seem to have both. At the Google I/O conference earlier this year, the search giant unveiled a new prototype service called Wave, which aims to deliver a unified platform for next-generation messaging. The prototype, which is currently accessible to a limited number of users and is scheduled to open up for broader testing soon, is an intriguing communication tool that also provides compelling insight into the future of the Web.

The scope of Google's Wave project is broad, which makes it difficult to define concisely. It brings together elements of instant messaging, email, collaborative rich document editing, and generic support for third-party Web services in a single seamless communication medium that is more flexible than any of those things individually. On a technical level, it is a messaging platform that consists of a protocol, a Web service, a set of standard extension APIs, and an open-source concurrency framework.

Communication within the Wave service is organized in a structure that is a bit like ad-hoc forum threads. Each top-level conversation contains groups of messages that are sort of like subthreads. The conversations are referred to as "waves" and the subthreads are called "wavelets." Individual messages, which are called "blips," are the smallest discrete conversational unit of a wave. The distinction between Wave—the service—and "wave"—the conversational unit—is significant, so keep an eye on the capitalization.

In email terms, a wave is like a group of messages tied to a specific subject line. A wavelet is like a single thread of messages that that are sent as replies to that subject, and a blip is like an individual email. It's important to note that these concepts are not totally analogous, as Wave reflects a distinctly different messaging paradigm and doesn't totally conform with the email model. We will explore some of the differences shortly.

When a user starts a wave, they can invite any number of other users to join the discussion. Participants can post individual messages, edit shared content, and insert rich media such as images or Google Map widgets. Wave is designed to facilitate real-time concurrent messaging, meaning that content appears to all users immediately and multiple users can edit and submit content at the same time.

When a user starts typing a message, the individual text characters of the message will appear to other participants as the user is typing. It will eventually be possible to selectively disable real-time transmission for individual blips by enabling a "draft" mode which is not yet available in Google's current prototype. Although messages are displayed immediately to participants who are actively viewing the wave, the messages will still be available later to nonactive participants. This means that Wave can seamlessly be used for both real-time communication like instant messaging and for delayed communication like email.

Short blips look and feel a lot like instant messages. In Google's user interface, they are displayed as a short block of text alongside the name of the sender and their account profile icon. Users can reply to individual blips to start a wavelet thread. In Google's interface, the threads are displayed inline with nesting and indentation to indicate their hierarchical structure.

The reason why I explicitly mention Google's interface is because the service will eventually support third-party client and server systems which could potentially present message content in radically different ways. Google's implementation will help define a lot of the baseline visual idioms for representing Wave concepts, but there are a lot of possible interpretations, and there is still room for improving on Google's user interface even though it's already very good.

In addition to being able to reply to blips, users can also edit blips, including ones posted by other participants. This level of mutability is one of the most profound advantages that Wave offers over conventional email. On the basis of individual blips, it makes it easy to annotate, correct, or elaborate on messages posted by other users. More significant, however, is the ability to restructure the entire conversation. This brings some wiki-like characteristics to the Wave communication model.

When consensus is reached on a topic that is under discussion, for example, you could just erase the related wavelets and replace them with a single block of text that describes the outcome of the discussion. This kind of refactoring makes it possible to streamline discussions and throw away noise that is no longer needed.

But what if someone arrives late to the thread and wants to see how the decision was reached? Or what if you have a compelling reason to want to go back and look at the decisionmaking process? Fortunately, Wave has a built-in revision history mechanism that records individual messaging operations as they are being performed.

This means that you can roll back the state of the Wave and view it as it was at any time during the discussion. Google provides a really convenient slider widget that you can drag to move forward or backward in the time line. There is also a "playback" button that will start at the beginning and show you each operation throughout the history of the wave as if you are watching it play out in real time. This revision history gives you the freedom to delete messages and move them around as needed without having to worry about losing important information.

---

Ryan Paul is the editor of Open Ended, Ars Technica's open source software journal.