Nowadays life is somewhat simpler. I wear a jacket and carry around an iPhone and a Palm Pre, one in each pocket. My music, photos, games and internet all fit into a single device that pretty much encompasses my personal life, while the other one holds everything I need for my work. Technology is moving from devices that perform a single function to those that are multi-purpose – after all, why buy, carry and maintain several devices when one will do the job?

Yesterday Apple announced the iPad, their new tablet computer. Designed to fill the gap between a smartphone and a laptop computer, their goal was to create a new device with a small set of core strengths. These start off with web browsing and email, but head into directions such as e-books, movies and other forms of entertainment. There’s even a productivity suite in the form of iWork, providing the capability to show and edit presentations, spreadsheets and documents.

There’s also been a lot of early criticism of the device, much as there was with the launch of the original iPhone. It doesn’t handle voice calls, it doesn’t support Flash, it doesn’t have a camera and it doesn’t support multitasking. While some of those are fair, it’s worth cutting beyond the surface and looking at the strategy behind the device and how it’s likely to evolve.

The easiest one is the comparison to e-book readers like the Amazon Kindle. The latest Kindle DX is priced at $489 and is arguably designed with a primary purpose of showing books. This means that if you want to carry around your book collection, the Kindle needs to be in your bag alongside your laptop and other gadgets. The iPad starts at just ten dollars more, and yet is in full colour. Amazon are already facing competition in the marketplace from a number of competing e-ink readers like the Nook from Barnes & Noble. There’s also a huge number that were announced at CES, all competing on just that single function. From a strategic point of view, it makes more sense to bundle books with other capabilities than it does to compete directly with an established device.

It’s not designed for use as a phone. The Kindle doesn’t support it, while it remains to be seen if the upcoming Android tablets will. Besides, anyone who remembers the Nokia N-gage will recall what it feels like to hold a generously proportioned device to your head. Yes, most of us have headsets these days, but it’s the feel of the thing. Besides, wouldn’t it be annoying if you’re in mid-flow typing out a blogpost or similar, when suddenly the application minimises just because someone’s calling you? There’s already talk of VOIP applications such as Skype making their way from the iPhone to the iPad, but I see this more as a mobile internet (like the Nokia Booklet 3G) than a mobile phone.

The lack of support for Adobe Flash may well be a problem to some. There are concerns that some Flash apps can be a resource hog (Zynga’s Farmville being a typical example of an app that grabs your browser and refuses to let go), while others may represent security risks (Twitter recently disabled some Flash widgets due to a security problem). Developers also now have a range of other creative elements such as Javascript, CSS and HTML5 in order to make websites more dynamic. Don’t forget, Apple also have their own video and audio codecs, and it’s possible that the iPad and iPhone will be used to drive support of these formats.

The inclusion of iWork for just under $10 doesn’t just offer a basic productivity suite, it also doubles up as a statement of intent to developers. By showing that the iPad can be used for business related tasks, developers are encouraged to consider what other work related apps would be suitable. The demo of Brushes at yesterday’s keynote really emphasised this direction of looking at how existing tasks could be redesigned to run on a tablet. I’m hoping for a lot of interesting software to come from this, from advanced blogging software to some creative design and project management tools. Pitched properly, this could become a strong collaborative tool and replace the netbook or laptop for small client meetings. Again, it makes strategic sense – Apple have obtained a chunk of consumer apps, but really want to stimulate growth in more business oriented directions.

Probably the biggest disappointment for mass media was the absence of an out-of-the-box newspaper or magazine subscription service to sit alongside iBooks. I’ve no doubt that it’ll happen – the New York Times demonstration shows as much – but I think they’ll have to work a touch harder to get a solution that works in an integrated way. There may well be demand for subscription based services, but publishing houses may well need to rally together in order to launch a service that consumers will buy in to. The presentation mechanism is mostly there – all that remains is delivery and pricing.

Looking on, what can we expect to see in the iPad’s future? I think that sooner or later some camera management capability will arrive, either in the form of a clip-on camera or by using Bluetooth to pair with a camera and support direct image capture and manipulation. I think we’ll also see advanced collaboration tools to allow owners to cluster together and share content through simple gestures. I also think that iBooks may even open up as a self-publishing mechanism, allowing authors to produce their own books, guides and manuals for sale on the platform.

The HP Slate: Fresh interface needed?

The big losers out of this are the other tablet manufacturers. Google’s Android OS may provide great access to all of their services, but there’s still a gap when it comes to managing and providing access to a large amount of entertainment. That said, by licensing Android out to manufacturers, Google effectively minimises their own risk. Devices like the JooJoo now feel dead in the water, while the HP Slate may struggle due to the Windows 7 interface. Just like with Windows mobile phones, we may see the Slate emerge with an overlay interface to make it easy to use. Netbooks will still survive – as Steve Jobs said they’re just smaller, cheaper laptops.

The other big loser out of this is Adobe’s Flash technology. After being the mainstay of interactive and elegant applications on the Internet for a number of years and providing t he technology behind services like YouTube, it finally seems that the end may be approaching. Google are working on their own streaming video technology that will perform natively in the browser, while tools such as AJAX are encroaching on another front. Security conscious surfers and those with adblocking software routinely block Flash objects. It may well be in a few years time that Flash starts to fade from our screens in the same way that Real Media has.

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.