We think of our mobile phones as mobile phones. This is the overwhelming experience for most users. With the iPhone, we are on the cusp of entering a new phase in mobile device evolution, just one of many mobile futures distinct from a single mobile past.

I tried to cover this kind of development when I wrote a story in the first edition of Next Generation Wireless Applications (revised, but not much, for the 2nd edition) about someone’s lunch-break during which she used her mobile for various tasks, only one of which was talking. The tasks were things like: invite friends to lunch, find a suitable eatery, pick up previous reviews (via spatial messages), check book prices, check book reviews, re-arrange personal fitness appointment, hail a taxi, find a nearby person with a common interest, and many more.

The point was to show the types of end-user experience that I felt was indicative of the ‘next generation’ in mobiles, which is a problematic term that I was stuck with for the 2nd edition (despite trying to change it). However, today it might be apt to say ‘Mobile 2.0,’ except that I also find that term problematic because I don’t think that the current mobile experience reflects the same magnitude of change that we saw with Web 2.0 from ‘Web 1.0.’

I would sum up the change as a shift in mobile habits from a predominantly ‘dial to talk’ experience (or ‘tap to text’) to a ‘click to do’ experience. In other words, mobile users rely on their mobiles as very much devices for carrying out tasks more than just devices for exchanging words (spoken or texted).

Thus my suggestion to Rudy in his Mobile Europe 2.0 twitter competition to summarise ‘Mobile 2.0′ in 140 characters or less:

Mobile 1.0 = Dial to Talk
Mobile 2.0 = Click to do

It is more of a user-centric view rather than getting into talk of how the technology will be more open, collaborative, social and all those other things that take many web pages, blogs, and even books, to describe - and we’re still describing and inventing them!

In other words, in the not-to-distant future, users will be picking up their mobiles and clicking buttons to do things rather than communicate, which will just be one mode of doing.

This isn’t a particularly insightful point, although it was when I was making it a long while back. Don’t forget, I’ve been designing mobile apps ever since there was a mobile app to be built, which, working with embedded software in early GSM handsets, means since the early 90s.

Although not insightful, the point is still useful, if only because it forces us to think about how the ‘doing’ will work and to ask the question as to how far the doing of tasks on a mobile is, or should be, related to the current primary task of communicating via calls and texts.

This is an important question because, as we’ve sort of found out with early (and possibly current) attempts to put Java on mobile phones, the idea has, in many ways, failed. Not wanting to get into a detailed analysis, a big part of the problem has been the fallacy of thinking that a mobile phone makes a good mobile computer, which clearly it doesn’t. There was a natural assumption that these two functions were related. Perhaps this was because we thought that the tasks that a user would want to carry out would mostly be related to telephony.

This is not an unreasonable assumption. It also explains the thinking behind some mobile operating systems, like Symbian, although the other influence here was obviously the PDA. It is no easy task to run software tasks related to telephony on a single processor. Add in other stuff that might be needed for PDA functions and then the ability to create programs around all these core functions, all within the mix of real-time telephony events, and things start to get quite hairy. Unfortunately for Symbian, all these difficult problems, which they’ve solved exceptionally well, don’t really address the single biggest challenge in our mobile future, which is how to ‘run’ Web 2.0 on mobile devices. (I say ‘run’ because it is a lot more involved in my opinion than just supporting a browser.)

Given the complexities of programming a mobile phone just to do telephony and a few bits besides, no wonder that the Java approach was sand-boxed from the start. However, what we end up with is something that’s not quite a computing environment and not quite a ‘phone-programming’ environment either. Add this ‘capability’ to a consumer device that doesn’t really want to play ball with the economics of general purpose computing and we get what we’ve got today - a broken platform.

The ‘mobile device’ is really a set of key functions that need to be thought about separately before deciding how they should come together, which, if we approach each with the right level of open technologies, will converge in meaningful ways all by themselves (i.e. the market), certainly not by any committee-based approach.

Mobile devices have, or can have, these parts:

Mobile phone = speaking to people
Mobile messaging = asynchronous text/media exchange
Mobile computing = native ‘custom’ applications
Mobile internet = accessing existing Web applications in either native or design-for-mobile mode
Media Player = listening and watching stuff
Camera = still/video capture (and sharing, as this is now almost inherent in the idea of digital photography)
And soon…
Mobile navigator (finding things, not just places, in space)
Mobile games ‘console’

I will not do the analysis here, especially as I am planning a new book about it (that I’m going to be giving away for free), but each of these parts have different user and technology requirements that within the economics of consumer devices cannot be met with a single device. Again, this is not rocket science and no great insight, except that the mobile (phone) industry has wasted billions and will, in some places, hang itself, by not understanding this point with enough clarity.

The latest example is IMS. When all is said and done about IMS, it is, first and foremost, just an IP-telephony framework. I know that will annoy lots of IMS pundits. Don’t write to me about the 1001 uses of IMS and SIP - I already wrote about them in my book

IMS can be used to improve the mobile telephony experience. This applies to the mobile device = mobile phone part. If we focus on just this aspect, it will work. However, when it comes to IMS applied to media players, games and other modes of use (there are plenty of use cases besides telephony), then it rapidly runs into problems. This is because we are now talking about mobile computing and we don’t have mobile computers. We mostly have phones with Java bolted on them. Working with a major vendor in this field - and with various operators keen to exploit IMS - I have seen how difficult it is to work in this direction - from a telephony-centric idea to a more general purpose apps environment.

I would much rather we had some credible devices first that are good at mobile computing - possibly the iPhone 2.0 - and allow this space to mature a little more so that the clever minds in this space can look towards IMS and figure out ways to exploit it from a mobile computing perspective. In other words, IMS as a general purpose session-based framework cannot be shoe-horned into mobile devices that are predominantly phones. Mobile computing geeks have to figure out how to exploit IMS within their world. If operators want to see this happen, then they have to make IMS networks open, which has all kinds of implications that operators will struggle with.

The same applies to mobile internet. This is often seen as a solution to device fragmentation. If we’re talking about how can I run the same ‘mobile application’ on a billion devices, then the question to be answered first is what type of application are we talking about. Amazingly, in so many discussions that I’m invited to take part in, such questions are seldom asked. These are not dumb questions. It seems that the pressure mounting today is from Web 2.0 companies who want to push their wares out to mobiles. This is never going to happen, nor should it, on devices called mobile phones. We clearly need devices that are internet-centric, like the iPhone, and we should focus our efforts in the Web 2.0 world on supporting the best possible experiences on these devices, even though the holy grail is to ‘get my app on 1 billion devices [phones]’ etc.

You simply cannot run a Web 2.0 app on a mobile phone. You can only run it properly on a ‘made for web 2.0′ mobile internet device. Let’s not fool ourselves that a mobile phone with a browser is a mobile internet device. This is the same category mistake - the same partial product (i.e. not a whole product per Moore’s advice on crossing the chasm) - made by plonking a POP3 client on a mobile phone and calling it mobile email (I have some slides on this topic somewhere that I will try to post).

In summary, moving to an age of doing things on mobiles rather than mostly making calls/texts requires delineating the key functions of a mobile device and mobile user experience (as per the suggested list above) and being convinced that each of these functions is really a separate strand of the mobile story from hereon out. Each category needs its own user-experience, technology and economic locus. The key to convergence between these loci is open technologies, systems and networks, obviously heavily underpinned by Web 2.0. Current attempts to design devices and software systems (e.g. MIDP) that support all these things is doomed to failure.