Wireless Wonders

No news, just comment about mobile phones and services, from a veteran practitioner...3G, GPRS, WAP, Bluetooth, WiFi, etc...

Friday, April 22, 2005

Push to taxi...idea # 51/100...

In the Blockbuster DVD chart, Taxi is the number one film, so perhaps the topic was lingering in my head and led me to the very interesting Google Ride Finder which I recommend playing around with.

Now, the idea is good, but the interface, despite its cleverness, is lacking. Why? Because it needs to be mobile. Perhaps catching a cab is a different process in the US, but here in the UK, it would be common to be away from a PC when trying to locate a cab.

This problem has been solved, to an extent, by a service like Zingo Taxi, which uses GPS-located cabs and location-based services to co-locate the caller and the nearest available Zingo-enabled cab. A charge of 1.60 GBP is added to the meter for this service. The cabs are specially equipped.

I had a similar example in the opening to my book, with an added feature of displaying the caller's name on the top of the cab (LED display) to make the final convergence easier.

However, in the new world of IMS, this service will be "easy" to implement on any network and won't need specially equipped cabs. Furthermore, the service can be made even more user-friendly. Zingo Taxi will probably be out of business.

One possibility is that in my active contact book, with presence capabilities, there is a permanent buddy entry called "Taxi" or "Cabbie", or whatever you like to call your driver. Simply clicking on the buddy icon is enough to instantly connect with the cabbie via a push-to-talk session. If need be, the caller could see where the cab is on a map and chart its progress, or even maintain voice contact with the driver.

What's going on to make this happen? Both phones have location-finding capabilities accurate enough to make the proximity search useful. Both phones are push-to-talk enabled. All this is standard stuff in 3G networks, albeit we don't necessarily have PTT and GPS-assisted location finding enabled on all networks just now (nor optimised for that matter - but let's give it time).

The only requirement is for a cabbie-arbitration service. This masquerades as the cabbie buddy in the buddy list application (that will be standard on all IMS client devices). It is this buddy that is invited to the PTT call by the caller. What happens is that this (SIP) session is trapped by the Taxi Server which acts like a proxy (or strictly speaking a Back-To-Back-User-Agent) and forwards the invite to the nearest available cabbie.

The Taxi Server simply looks up the nearest available cabbie using location-finding queries. It also only looks up cabbies that are "online" (i.e. available) and then forwards the invite accordingly. Hey presto! The cabbie receives the audio stream from the caller.

It is also relatively straightforward to receive an image to show where the cabbie is. The cabbie can have a URI associated with the buddy icon and this is dynamically updated from a mapping server.

Finally, the payment option is billed through the operator network using online or offline charging, via any mechanism that might be in place and convenient (e.g. reverse-billed SMS).

Push to talk becomes push to taxi!

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Drag and drop from a mobile...idea #50/100...

Half-way through the 100 ideas! I hope that they are proving useful in a variety of ways to the readership. I am not claiming originality, although I think some of them certainly are novel. The idea is to open up a landscape of possibilities, so that you - the reader - might find stimulation in your own thoughts about mobile.

I have a variety of ideas about PC-mobile connectivity and one of my hopes is that an innovative player (perhaps Apple) will soon set the "standard" for fluid media and data between desktop and device. I was hoping for something in the latest Mac OS X release, but I didn't see anything interesting in the Jobs demo.

I have often written about using mobiles as pointing devices (see idea #4) and I played around with such concepts a couple of years back, which led me to buy a gyration mouse to try things out.

Is it possible to select content on a mobile device (in my hand) and simply drag and drop it onto my desktop?

The transfer via Bluetooth is easy, but what about the actual dragging operation. Imagine placing your mobile over the appropriate window on the screen and just dropping the content into the window.

What I was playing around with this morning was waving my mobile over the screen and looking through its camera. Using the principles of an optical mouse, it seems possible to enable at least a crude position sensing mechanism, crude being all that is required in order to drop into a relatively large screen space (i.e. a window).

The challenge is with absolute positioning. In other words, how does the mobile/PC link know where the mobile is, not just its movement?

I think there are a variety of solutions to that problem. An obvious one is to start at a fixed location and move from there. I don't like that solution, because it's clunky.

Another possible solution is to differentiate the windows on the screen in a way that the camera-link can sense areas on the screen, or known location points or areas. For example, each window could have its own background pattern (or some other key) that is uniquely identifiable via pattern recognition. This would seem unattractive as it means a departure from the usual display. However, this pattern could just appear as an "overlay" (or "underlay") on the screen only visible during the drag and drop process, during which the user would be holding a key on the phone.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Thursday, April 21, 2005

Merged web interfaces...idea #49/100...

I often imagine a phone interface that is simply a search-box, as bare and stripped down as the Google front page.

Most of the time I would be entering search strings based on names. However, unlike a search engine, there would be no need to hit "search" or "return". I imagine that the search "results" would appear below the box in real-time as I typed the search term, just like some devices do already (6600, Blackberry etc.)

However, the names would actually be stored on the web, not on the phone. I would have a personal address book and I could also belong to shared address books. Of course, data would have to be cached, otherwise delays would be too great compared to a locally stored book. [Updated books (via the web) would have already been downloaded pre-emptively.]

Why isn't this available? Or is it? Why do I have to bother with the idea of "synchronisation"? And why isn't it possible to have the search box for contacts as my home page on the phone? After all, the most common action done with a mobile phone must be contacting someone (text or call).

What else could I do with a search box? I could type in a command, or something related. For example, I type "ring" and I start to get entries in the results area to do with ringing, ring tones etc. Some of these "links" would be local, like "adjust ring volume", "change ring tone". However, when I select "change ring tone", the options are web-based. The search box would enable me to find tones quickly, but there would be a mix of local (installed) and remote (uninstalled) tones.

As operators released new services, they would appear in my results, like "ring back tones" (if this isn't already supported).

In the coming all-IP world of 3G, once IMS has arrived, increasingly mobile services will all be web-driven. Changing call-forwarding or rings-till-diverted settings won't be driven be some obscure dialing string ("1124" or whatever), it will be an option on a web (WAP) page.

With many features, the user won't be cognisant (nor need to be) of whether it's a phone-based function, or a server (network) based function, or some mixture.

I like the idea of a search-box interface. One of the problems with mobile phones and services in the evolving 3G era is increased complexity. There will be so many possibilities.

Perhaps with careful design of a search interface and results ranking, both service discovery and usage will become not only more manageable for users, but more profitable for operators. Even now, there are perhaps lots of mobile services that we simply don't know about, unless one dares to hunt around on the operator's website. I'm a great believer in the "bump into effect" which says that you are more likely to use something if you bump into it, than if it is tidied away in some corner, real or virtual.





Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Tuesday, April 19, 2005

Why is the Blackberry so damn ugly?

I have lots of friends and associates who ask "how do I get email on my phone?" A good question and, I guess, I'm a good person to answer it. Not only have I spent what seems like a lifetime designing, implementing, analysing, assessing and breaking mobile email systems, but I run a UK-centric forum for Blackberry Users. I think it's the only club of its kind, by which I mean it is aimed as users, not techies.

As you might expect (or perhaps you might not!) invariably I suggest "get a Blackberry". And I'm not even on a commission! "You need email push" I exclaim, although that is available on other devices these days.

However, almost without exception...
...actually, entirely without exception, I am told something like "that thing's too ugly".

It doesn't matter how hard I try to take a function-driven approach, my detractors pull me back, usually swiftly, to a design-biased approach.

"Ah, but it's easy to use..." I say.

"Maybe, but it's ugly!"
"...and it's got no goodies!"

Recently I sat in a seminar where an operator representative puzzled over why more people don't buy Blackberries. "I just don't get it" he said. I've gone into this topic before and I can offer various explanations, but I'm beginning to think that design has a lot to do with it.

It's not chic, it's not sexy, it's not pretty...and it's not playable!

I don't mean games (although something more interesting than break-out would be nice), but you just don't want to pick it up and play with it, like a Rubiks cube lying on the coffee table (I dare you not to pick it up).

Of course, some will argue the opposite..."it does the job" blah blah. I'm telling you that I've been there. It doesn't work!

One thought about device design. Has anyone thought to ask the likes of George Lucas and his visual artists to come up with some concept designs for a PDA? Whatever you say about Star Wars, some of those set designs are just incredible.

A Star Wars Blackberry? Umm....maybe.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book

Sunday, April 17, 2005

A data-only world...

In a recent discussion I participated in, the importance of the mobile as the focal point of device convergence was debated. There can be no doubt that an increasing number of features will gravitate towards the mobile phone in our pockets. However, this should not be the only model...

One question I have is whether there is a business model that separates voice from data. Could an operator sell voice connections separately from data connections and essentially see the latter as a way of attracting customers with data-centric needs who don't want telephony. In other words, I have a phone that I'm happy with on one network, but I want to connect my PDA, or other data-centric device, through another network.

I have made some assumptions. One is that this data-only network provider will give me a compelling data package, which probably means two things. First is an attractive price, probably flat-rate. Second is very little restrictions on traffic (i.e. an open network), although I recognise that there probably needs to be some restrictions (afterall, wireless is still a relatively precious resource).

The second assumption is that this offering makes sense to the provider because of the amount of business they can attract to their network, which I believe could be greater than imagined. Or, sufficient enough to make a profitable business out of connectivity packages without too much slicing into the value chains associated with the traffic going over the connections.

The third assumption is that users will want data-only packages because they have data-only devices. This contradicts the current model that I opened with, which is that everything must converge on the voice device (the phone).

We can probably debate the "user device preference" argument until the cows come home. Some users will argue until they're blue in the face that what they really want is a PDA/MP3/phone/WiFi/kitchen-sink device. Others will argue that they prefer a separate phone to PDA and don't want to give up their iPOD, etc.

I don't want to get into that argument, because it is somewhat misleading. What I am interested in is challenging assumptions, mine included. Let's look at one recent example of integration, namely the camera. The number of camera-phones sold now outstrips the number of digital cameras. Some commentators have argued that this is further evidence of the trend towards the phone as the convergence focal point.

However, what does this really mean? Are camera-phones replacing digital cameras? Well, market analysis might yield certain answers to that question, but camera-phones and digital cameras are not the same thing. Any useful digital camera has a decent lens and sensor not found on camera-phones. And don't get confused by mega-pixels. This is really about how big, or fine resolution, an image can be, not about its quality.

I'm not denying that some people will be happy to snap pics on their mega-pixel (or less) camera-phone, but generally speaking, in terms of our current photo habits, including sharing and printing and so on, a camera-phone does not replace a digital camera.

Two issues arise from this consideration. Firstly, phone-centric convergence has limitations. In this case, adding a proper lens (with zoom) and sensor to a phone is problematic, not to say costly, which is another general limitation of course. Silicon integration does have cost implications, as well as power consumption ones.

The second issue is would digital camera phone users still want the wide-area connectivity of a camera-phone if it were possible and affordable? In other words, if a camera could connect to the 3G network, would users want this? The real issue is what would they pay for it? However, before answering that question, what if a camera supplier knew that such a model were possible within which they controlled the value chain and not an operator. That is, their devices are connected through the open data-centric network provider mentioned earlier. Would such a possibility allow innovative new business models to emerge for selling digital cameras, probably based on some kind of service model rather than a pure equipment sale model.

[One might ask the same question about other devices, such as music players, video players, portable games machines and so on.]

Would then, this create a virtuous circle for the network provider? By allowing value chains to emerge and thrive unhindered by operator intervention, facilitated by affordable and flexible connectivity, would the provider see a gold rush on connectivity?

I have probably just proposed more questions than I have answered, but that's the nature of this blog entry: thinking aloud in "print".

I shall return to this theme in further postings, because I've a lot more to say about it and it probably deserves a much more detailed treatment than a typically pithy blog entry.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book