Wireless Wonders

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

Friday, July 01, 2005

Podcasting and don't say 'um' (or is it 'uh'?)

Rob Griffiths at Macworld, in his assessment of podcasting, is also disturbed by those what-do-I-say-next "um", or is it "uh", sounds?

My friend and fellow Macworld author Kirk McElhearn has put together Kirk’s Seven Rules of Effective Podcasting, which is a great place to start. It’s probably not all-inclusive (I would have included “Don’t say ‘uh’ even once” as Rule No. 1), but it’s a good list of things to consider if you’re thinking about podcasting.

Another application for my umm-filter!
Perhaps they could be replaced with croaks instead...

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

Your nearest WiFi zone is...

Russell Buckley and his new Mobhappy blog posts about recent conclusions as to why location based services (LBS) haven't been successful. I posted my comments here...

Accuracy! That's what we need. We don't all congregate in Oxford Street (London) where there are more base stations than McDonalds and we can see the nearest cash machine anyway (and who needs cash?)

Most of us move in areas where we try to use LBS on the operator portal and the "nearest" whatever is always strangely near a cellular mast, somewhere past umpteen of the things you're actually looking for. I still recall attending an operator "developer forum" where the LBS "manager" said "we've done tests" and "users don't need the accuracy of GPS"....

Perhaps they're worried we might actually find the nearest WiFi hotspot...

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

Thursday, June 30, 2005

There's a frog on the line...idea #68/100...

In the emerging all-IP world of converged wireless networks, courtesy of IMS, it's a cinch to add new services to the mix.

IMS allows services to be plugged in to the call pathway. In legacy networks that are circuit-switched, any processing of the audio pathway is usually a function of the switch, or some adjunct to it. This is switch-centric or switch-bound processing. For various reasons, it is not easy to add a new service to a switch. One reason might be that only the switch supplier can do it. This vendor lock-in means it will be expensive and slow to realise new services that are switch-centric. Consequently, telecoms operators are not abound with services.

IMS uses a method of call processing called SIP. It doesn't matter if you don't know what SIP is. What matters is that it is an open standard and it is easy to implement a piece of software that can "talk" SIP. With SIP-centric networks, there is no vendor lock-in. Potentially, anyone in a garage can develop a SIP-based service. Whether operators will allow this or not is another matter.

You can think of IMS as a router (as well as other things). If a user tries to make a call, their phone starts sending SIP signals through the IMS network. What the network can do is to say "Ah, this call is from Bob and as Bob is a subscriber to the 'insane toad' service, so I should route his call via the 'insane toad' server in case it wants to do something 'insane' for Bob".

Now that you understand the essence of IMS, I can introduce the "insane toad" idea. It is relatively simple with SIP to introduce audio into the call. This is needed in any case for things like announcements, such as "please wait while we divert your call..." etc.

Think of being able to introduce our own announcements. A SIP server can be hosted on the Web and have a web (or WAP) interface. We could upload our own announcements. However, "insane toad" goes a step further...

When the IMS network detects a call is being made by an "insane toad" service subscriber (all subscription information like this is stored in a big database called an HSS), the "insane toad" server can cause a screen to pop-up on the user's terminal.

What this screen does in this idea is to allow the user to select audio clips that they want to play during the call. If, for some unfathomable reason, they might like to hear a bizarre animated creature croaking or laughing, they could hit the "toad laugh" button and insert such a sound into the call.

Think of it as an audio version of smilie icons used in IM. In fact, this is how the service might work. The caller would select the icon for the sound and the callee would hear it and also receive the icon on the phone at the same time.

Using a Web-based front-end, users could upload their own clips, although I suspect that the operators would want control over the clips. I can't think why!

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

Wednesday, June 29, 2005

Gataga, tagging, feedback - very cool!

Earlier, I mentioned Gataga, the "social exploration" engine. Go check it out, if you haven't already.

In the post, I suggested that the mobile interface was inefficient. Now, I could have posted my feedback to Gataga, which ordinarily I would have done, but instead I just added the tag "Gataga" to my posting and waited....

....sure enough, the "codemonkeys" at Gataga eventually picked it up in the feeds and - even better and totally cool - they went and fixed the mobile interface and then told me in a comment to the original post.

That's customer service, that's tagging, that's speed, that's cool!
Thanks Gataga.

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

Tuesday, June 28, 2005

Food-Oriented Lunch...

In the world of massively complicated and expensive-to-run mobile operator networks, it is difficult to develop and deliver new services. An operator network, just like any other, is lots of computers and databases. These might be configured as switches, as text messaging centres (passing your message from your phone to another), as radio controllers, and all kinds of disparate functions. Most of these computers and databases have their own way of describing the information they contain and their own way of conveying it (i.e. protocols).

Most interesting services, such as some of the ones I have blogged about here in my 100-ideas series of postings, require a bit of this and a bit of that from the various disparate systems in the mobile network. This problem is not unique to mobile networks. Many networks in all kinds of businesses have similar problems.

Now it is inconceivable to write a software program that is going to run "across" the network on the various systems in order to achieve the service being sought, such as a push-to-taxi-air-tagging-cellular-socks service with cream on it!

However, what if we could write a "program" sitting somewhere in a network that asks all these disparate systems to do a bit of this (service A) and a bit of that (service B) and pass me back the results to co-ordinate (Orchestrate) a meaningful user service on behalf of a user. This "new" approach is called Service Orientated Architecture (SOA).

"Ah-ha!" I hear you say. "Isn't that obvious?".....
"Hasn't that been done already?"..."Surely, that's been done before!"....
"Wait a minute...isn't that what happens already?"

The answer is......

"YES!"

However, the way it is now being done is new and there is also a very important and strategic move within the operator world to develop the "platform" bit that glues all the services (bit of this, bit of that) together. These are called Service Delivery Platforms (SDP). They are important because it means there's potentially a single unified approach to developing and delivering new services, with greater speed and lower cost.

However, as with all these things, we have to cut through the usual barrage of buzzwords and separate out the chaff from the wheat, or the reality from the marketing hype. I found this comment on this blog about SOA very amusing...

I've decided that saying "Service-Oriented Architecture" is like saying "Food-Oriented Lunch" -- it sure sounds good when you're hungry, but you still have to decide how much you can afford to spend on it, which restaurant you're going to, and what you're going to order. And you still have to wonder whether or not you're going to have a massive case of food-poisoning afterwards. Show me an actual menu -- then I'll tell you if I'm impressed.

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