It’s a strange word, wherein the context of it’s use imparts as much information as the word itself. For example, “I’ll e-mail you the latest product specs soon” has an entirely different meaning to “You’ll soon be able to try out this new product for yourselves”. One implies a response later that day, while another could mean later the week or even later in the year. It takes on a variable quality of it’s own, as if it denotes a reference in time that refuses to be tied down and instead leaps carefree, giving program managers and marketeers alike a headache. And yet for some, the mention of Soon starts the Long Wait, that period of time when product fans around the world gather themselves together like some massively extended family awaiting the arrival of a newborn.
The Soon I’m referring to in this case is about the imminent release of Google Wave into public beta, following several months of developer-only sandbox access. If you’re interested in more detail about it and one and a half hours spare, you might want to watch the initial developer conference presentation here. In brief, it’s a new communication method that Google hopes will eventually replace email as the protocol of choice. Instead of an email essentially being a file that’s sent from one person to another, a wave is a conversation stored on a central server that you invite people to edit. You can embed media into a wave like photos, video and applets in the same way that you can embed them in an email, but again a single copy is held centrally. Changes are tracked much like a wiki, and several people can edit or add to a wave at the same time. Updates can even be displayed character by character in real-time.
All this sounds pretty reasonable when you’re sitting at your PC at home or at work. We have solid, reliable Internet connections that we tend to rely on. They’re perfect for apps that completely exist on the Internet, where you go to a website with your browser and know that by and large, what you’re doing will work. It’s why there’s been this huge resurgence of thin client computing, where whole teams have a very basic PC with a browser installed, accessing every system and application through the browser. All the storage is done on a collection of servers, with modern networks and infrastructure taking the load. Google have even designed Wave so that different businesses and organisations can have their own installation, with Wave servers across the world talking to each other when information needs to be shared between them. To achieve this, all the protocols and the majority of the software will be open sourced.
Look ma, no wires!
Web apps are fine when you have a solid, stable Internet connection.But what happens when you want to access your Waves while away from the office or travelling on vacation? The MaxTatton Blog poses this type of question by pondering why Google haven’t sought to integrate Wave into their Android mobile operating system and making it a unique selling point of the device.The difficulty is, it’s not as simple as simply providing a mobile-tailored version of the Wave website. There are people who like to access their email offline, like the Blackberry user who clicks out replies to messages on the Tube or the road warrior who checks his email archive for key items. These are people who understand that the Internet is not always there for them, and who need communications mechanisms that understand and support this.
While it’s likely that there are engineers working away in the background on this, it becomes a bit of a chicken and egg situation. Do you rush out and support a protocol that has little early adoption in the hope to foster growth further, or do you hold back on development until you have more certainty that the investment is worthwhile? Where would the tipping point be if development was held back, and what would it look like? Should it be Google’s place to develop a mobile interface, or should it be left to other developers? Do you start building Wave to Email or Wave to IM bridges first, or do you look to run access to each technology in parallel? All these questions start brimming to the surface as soon as you look at integrating it with your existing organisation, and there’s no easy answer to any of them. That said, Google shot itself in the foot when it announced that it wouldn’t directly support Internet Explorer.
Catering for the client
Any kind of mobile wave client would need to evolve some kind of push and sync capability in order to work for most heavy email users. Products like BlackBerry, GoodMail and so on cater for instances where a handset wanders out of coverage, catching up when it reappears and re-establishes a connection. They involve a datastore of communications that’s held on the device and allows the user to browse messages whenever it’s convenient. Apple do a similar thing with the Visual Voicemail service on iPhone – messages are downloaded as audio files and saved on the handset to play back whenever they’re needed. Looking at the Wave architecture though, all of this sync-federate-journal work is performed by the central server, in concert with other Wave servers hosted by other organisations. As a result, any Wave for Mobile capability is going to involve running what looks like a mini Wave server in it’s own right, playing sync and catch-up when it can.
Syncing email in itself is a relatively straightforward task – you push out an alert to the handset that tells it there are emails to pick up, the handset connects and downloads the waiting messages. Comparing that to a journaled XML document where the user may only have visibility of small chunks, and things start to get slightly more complicated. Start allowing editing to happen in real-time, with updates being broadcast character by character, and the complexity grows even further. Part of the job of any mobile Wave service is to cut down the data sync to only what’s needed to maintain cohesive communication. This is partly to ensure that the average handset owner doesn’t get bombarded with update alerts continually, but also to make sure that the data connection doesn’t get saturated with updates that don’t really add value to the message. Saturating the connection may be more of a struggle with a 3G or WiFi connection, but many current email devices only use 2G for communication in order to extend battery life. In addition, WiFi hotspots are limited and 3G coverage focuses on urban areas, forcing 2G as the network capability to design for.
It’s clear to see that the mobile client is already becoming a complex beat in it’s own right, just in order to be able to update and sync itself with the central Wave server. Throw in the additional controls that most enterprise IT managers require, such as password management, remote lock & wipe and so on, and it becomes a substantial project. Even then, the developer will need to work out if his client can interface directly with the Wave server, or if some form of middleware or bridge will be needed in order to provide a suitable level of service.
If not soon, then when?
It’s clear that Google needs to get an overall solution together for Wave that involves not just the server and desktop, but the Mobile user as well. This solution needs to be able to cater for situations where data connectivity is a scarce and intermittent resource but can still deliver a good user experience. That’s a big challenge, particularly for an engineering team that’s currently working at full tilt on either developing the mobile OS further or refining the Wave server infrastructure. As Lars Rasmussen mentioned during the Developer presentation, Google are looking to the developer community to fill in the gaps and as far as gaps go, this one’s huge. Once the server code becomes open sourced, there may be an increase in development from other third parties.
One thing is clear though, if Google wants to make this technology a success, it’s going to need to do more than give away Android phones to get other big players interested.