Ever heard of the phrase “end-to-end”? It’s what service providers use when trying to test out new products that they’re looking to bring to market. They test out every step of the process, be it order fulfilment, streaming entertainment or real-time data services. Part of that process is about catching the weakpoints and improving them, but it’s also about ensuring that adequate customer support mechanisms are there in order to catch things when they go wrong. Your perfectly designed product may start to fall apart when unexpected system behaviour creeps in, especially if the interactions between systems are complex and non-trivial. It’s therefore surprising when a firm seems to have dropped on this.

It became inevitable that Google would release the Nexus One once the period of “dogfooding” was completed. I’ve heard it more eloquently put as “drinking one’s own champagne”, but the process is the same. It may have been that this was little more than a holiday gift to its employees, as there’s little time to test anything between it starting on 12th December and going on sale on 5th January, especially with Christmas in the middle.

On paper the Nexus One has all the makings of a great phone. An OLED touchscreen, noise cancelling microphone and full speech-to-text tick a fair few boxes, along with a 3D capable display and turn by turn navigation. There is the glaring omission of multitouch and the limitation of only 512MB being made available for app storage, but on the whole it’s a solid package. Where things start to come unstuck is in the overall “service wrap”, or how you’re looked after as a customer once you have it.

As Google is selling the phone directly to customers, the margin of responsibility has become blurred. Early indications are that Google, htc (the manufacturer) and T-Mobile aren’t clear on the structure of this relationship themselves, with customers being the ones losing out, both with reception issues and ordering/storefront problems. Unsurprisingly there’s been a bit of a backlash from this, with some consumers feeling bitter about forking out $530 for a device that costs $174 to make.

Google are learning the hard way just what it means to have your name on the hardware, and how having integrated support for that hardware is important.It’s for this reason, above the technical considerations, why going for an iPhone or Palm Pre may be a more sensible choice at present. The bleeding edge is exactly that, with various improvements required before that edge becomes dulled. That said, there’s no reason why this is a bad thing for Google, Apple, or the smartphone market in general.

The competition between Google, Apple, Palm and RIM is certainly a good thing for the smartphone marketplace, and for consumers in general. With it quality should go up, while the price of this advanced technology should go down. Firms like Motorola who plan to use Andriod for all their future devices may feel threatened by Google’s stance. This may provide Microsoft with an opportunity to move back into the game when it releases Windows Mobile 7 later this year.

A gap is also emerging between smartphones such as Apple, Palm and Andriod, and those made by other firms such as Nokia, Samsung and LG. While the low-tech and low end area of the market can be a legitimate place to target, it’s usually where handset margins are squeezed. Traditional phone manufacturers need to be wary about being squeezed into this space by newcomers dominating the smartphone end. Richard Scoble probably has the right idea when he says that there is more likely to be competition between the web-friendly smartphone sector and the boxed-in group in the middle of the market. These phones with Facebook and Twitter apps “built-in” are likely to be squeezed out of the market as smartphones move to the middle-range.

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.