Telepocalypse

Stream me up, Scotty

I’m trying to watch the spectacular launch videos of the Shuttle on the Nasa website. Seven crazy folk sat in the space-going equivalent of a 1978 Chevy Malibu strapped to a bomb with a wee nozzle at the bottom. (Yeah, they added a CD player and a iTrip, but it’s still a flying ‘78 Malibu.) It’s always going to make for a spectacle.

Unfortunately, NASA went for a “streaming” video experience. Indeed, a Windows Optimized one. Which means I can’t just download the launch video and watch it. No, I have to sit through a thousand “buffering” messages and herky-jerky broken video. It’s totally crap. Rewind and watch without the gaps? Nah, buffer, buffer, buffer.

Streaming is a totally cretinous concept for anything other than live events.

PS — And people think MS is going to deliver a great IPTV experience? Pfffsst haw haw! All the codec experts in the world aren’t going to help you if you don’t focus on the basic user experience issues.

I promise to pay the bearer

Here’s an idea.

Part of the purpose of municipal networks is to aggregate demand and overcome a co-ordination problem. Since most communications are local, and to have value a network needs to connect you to someone, the natural unit of purchase would seem to be a “neighbourhood”. This could be anything from 100 to 100,000 people, I guess.

However, the big ‘ol telco methodology is to dole out small bits of connectivity to top-payers one-by-one with massive marketing effort, and slowly drop the price to gather up a mass market. Yes, you want to convert a large proportion of the homes you pass into subscribers. But that doesn’t mean you want to pass a large proportion of homes. Furthermore, those homes you do pass may want to communicate with people who aren’t in the affluent areas. Why get a videophone if your student kids live in a cheap part of town?

I firmly believe that the route to future success in telecom is via innovate financing and ownership models. So here’s one.

You may have heard of PledgeBank. It allows people to co-ordinate on a promise where you’re only willing to proceed if enough other people agree not to free-ride. This is being used, for example, to co-ordinate refusal to acquire ID cards in the UK. (Hmmm - how long until the site is closed down for supporting incitement to break the law…)

You can pass all the anti-municipal broadband bills you like, but there’s nothing stopping a private entity like iTown Communications coming along and conducting a PledgeBank-like exercise. They can even “red line”, and get people in poorer areas to pledge lower amounts than in affluent ones.

There are issues, of course. You need to make these pledges binding. It may be hard to collect on those who default on their pledge. Perhaps you need to get people to put some money where their mouth is up front, into an escrow account.

But ultimately, it can be done.

PS For non-British readers, the title refers to this hollow pledge.

A passage to India

Here’s the scenario. Lady calls bank. Bank routes call to India. Nice chap in Indian call centre talks to lady. Lady can’t understand half of what he says because call quality is a bit duff. (The IVR system sounded great, so it’s not at her end.)

Here’s the business opportunity. You’re a VoIP “virtual network” operator. Deliver high quality encrypted speech over the Internet to Indian call centres. Indeed, when I use a service like SkypeOut and enter my bank’s number, you just look up first if you have a non-PSTN route to them. (Be it ENUM or proprietary technology, I don’t care.) Doesn’t need anything new in the customer’s eyes.

Customer satisfaction goes up. You take a tiny slice of revenue from your bank partner for delivering a wideband audio experience to a large public user base, many of whom are the bank’s customers. Let’s call them “origination fees” to make the analysts happy. Everyone walks away contented.

(And if you’re an old-fashioned 1st-gen VoIP operator who just cloned vanilla PSTN service, you’re out of luck. Again. The point of IP is new features and functionality, not arbitrage.)

No doubt some of the SIP-heads out there are wondering why anybody would pay someone like Skype to deliver customers when it can be done for free. Just remember, bottled water is big business, even though tap water is free. Same reason.

Now can you see why Skype might start to have a significant market value? And that some of the partners might be folks like Avaya, who stand to gain a ton of dosh upgrading call centres to new techology? How long until you can IM with the call centre agent you’re talking to, and they can just cut’n’paste stuff into their forms? Just lift stuff straight from your Skype profile? Would you use Skype or the PSTN if the former relieved you of ever waiting in a queue, and simply IM’d you back when your turn was up?

The business model is out there. You just have to look.

Wickedpedia

As an educational aid, Telepocalypse is pleased to offer its readers this essential glossary of industry terms. Simply print it out, fold it up, and stick it under your keyboard for your wife to discover and clean away next spring.

SIP. Abbrev. Standard Initiation Protocol. A meta-technology designed to inspire people to create new, proprietary and competing standards and implementations containing subtle incompatibilities.

VoIP. Very Old Idea Phone. A revolutionary way of extending Bell’s original vision for the telephone, allowing you to dial with a mouse click as well a touchtone keypad and rotary dial.

IMS. Internet Monetisation System. A minor adjustment to Internet Protocol to add a “price” field to packet headers. Earlier versions referred to Innovation Minimisation System. This usage is now deprecated. (Expected release Q2 2012, not available in all markets, check with your service provider in case of sudden loss of unmediated connectivity.)

E911. Slang. Emergency! 911. Whenever an incumbent telco feels chest pain, hot flushes, and sudden loss of wealth, they should call their local political office and declare an “Emergency 911”. (A tax-deductible campaign donation of the usual $911,000 is also expected in return for rescue service.)

ATA. Auntie’s Telephone Adapter. Gives your desk phone a thicker, less flexible “Ethernet” cord and and weighted anchor to stop your clumsy aunt knocking it onto the floor again.

SBC. Archaic. Session Border Confuser. System designed to prevent Skype users in different corporations from being able to talk to one another. No longer in common use.

And a crate of bottles

Just a follow-up thought or two…

This morning I was watching my friend and old Sprint colleague’s David Anderson doing his video blog with Robert Scoble for the Channel9 Microsoft Developer Network.

It reminded me of some of the basic tenets underpinning David’s application of lean manufacturing to software engineering. For those who care, I think David’s work will have a lasting impact on the software industry long after Longhorn/Vista has been forgotten. Watch the video — yes, it’s quite long — and then think: what’s the impact of an order of magnitude increase in average software development productivity on the economy?

My contention is that thinking along similar lines might improve our human ability to manage multiple relationships and messages. You shouldn’t need to have a nervous breakdown when your tribe size exceeds 150 people or when you get 200 mail messages a day. You should never have to declare email bankruptcy and have to start again afresh.

Just like David’s epiphany that if the developer is overworked and stressed, the problem might be the system that assigns work to developers and accepts work from clients, not the lazy developer. If your message inbox is overflowing, you aren’t lazy. You just don’t have the right tools yet.

Thankfully, us hairless chimps are good at fashioning new tools.

The Feature-Driven Development (FDD) methodology agrees with the Theory of Constraints (TOC) by focusing on delivery of client-valued functionality. FDD does it by making the customer-valued feature the atomic unit for planning and tracking software development. Outputs, not inputs, are what are measured. Unlike function points, or lines of code, it isn’t an arbitrary intermediate product. Housekeeping code doesn’t count. TOC focuses on maximising the velocity that client-valued output emerges from a system by paying close attention to bottlenecks within the system. It also eliminates waste — particularly that of excess inventory. TOC also teaches us of the high real costs of “rush orders”, set-up time, and errors.

There’s a good reason I’m telling you all this; our processing of messages is also like an “action factory”. We accept “attention orders” from incoming messages. These have to be correlated, sorted, actioned, followed-up, filed, reviewed and archived. Some of these processes are complex.

Suddenly, it all starts to look familiar. Cars through a Toyota facory. Features through a software factory. Messages through an action factory.

Of course, you need to apply the metaphors where they work and know when to stop.

So what we want is an “agile messaging system”. We want small batch sizes. I should’t be presented with too many messages at once. My “getting things done” system tends to limit my daily to-do list to less than a dozen items.

We want small batch sizes — but not so small as the set-up costs start to outweigh the benefits of processing alike items. I’ve found it very beneficial to use the email subscription service of Bloglines. I forward certain mailing list subscriptions to special Bloglines addresses using a mail delivery script on my server. I can then peruse these as RSS feeds at my leisure. Two dozen emails from Gordon Cook once a week in a single sitting is better than twenty-four interruptions with “you’ve got mail”.

Speaking of which, the new mail flag is a productivity disaster. It flags every arriving attention request as a potential “rush job” that needs urgent attention. Somehow we need to fight against these machines and re-learn how to concentrate on one task for more than 3 minutes. Sometimes at the end of the day my head spins like a concussed cartoon character from attention atomisation.

When you come back from vacation, your inbox shouldn’t say “1273 new messages”. It should be “102 new batches”. It should have grouped and sorted them for you, ready for processing in what it sees as a reasonable order. Yes, you might miss an important one at first — but it can’t be worse than what we have now, can it? Small batches, frequent action.

We want to eliminate all waste. What is waste in email? It’s messages that you aren’t interested in, won’t action, etc. It’s also messages for authorisation of routine business transactions that you click “accept” without even reading. Much of the waste has to be eliminated by fixing the processes outside of the email system. But some of it can be fixed internally. Just apply a bit of filtering and collaborative intelligence to weed them out automatically.

The bottleneck of the system is the working memory of a human. That’s the constraint, the resource we’re trying to protect. The unique ability of a human brain is to perform associative memory actions across large and fuzzy data sets. Everything in a messaging client should be based around those limits. Martin’s getting tired now, I’ll hold that message back for a few minutes. Why not buffer messages out of sight until the right batch size is reached or until my working memory isn’t too tired?

In a way, this is what my RSS reader does. It holds messages back and batches them for me. I can now process a thousand messages a day where I might previously only handled a hundred.

A final parting thought. The theory of constraints introduces the concept of “drum, buffer, rope”. I won’t go into detail of where the terms come from. But part of the route to success is not accepting orders into the factory faster than the bottleneck can process them. A next-generation email system might ever write back to senders “Martin’s busy now — is this mail important”. “Your email wasn’t read while Martin was away, is this message still relevant?”.

Might give people some pause before hitting the send key in the first place.

UPDATE: Oops, forgot my key point. The client valued functionality of email isn’t messages received. That’s an intermediate by-product. There are a number of outcomes — actions, FYIs, social contacts, etc. I send David a cartoon joke about Glaswegians last week; ideally I’d preferred to submit it into a different queue than his email inbox, but I can’t. You build a better messaging tool by creating better outcomes (doh!). The only way of doing this, like with RSS, may be the gradual abandonment of email in favour of domain-specific messaging tools.

UPDATE: Benoit has been thinking along similar lines.

OPINION://Message in a bottle

It was amusing to see Vodafone’s advert in the airport the other day. There they are, blasting out how they now offer Blackberry service on their network. Busy as usual taking credit for other people’s inventions and acting as gatekeeper. Who can blame them?

Except that Vodafone have done next to nothing to make this happen beyond supply connectivity. Not that running a vast cellular network is a trivial thing — it’s just the pretense that Vodafone are doing you a favour by permitting Blackberry devices onto their sacred network that riles.

I remember the many arguments inside Sprint’s Business Solutions division as to whom we should partner with to offer enterprise email service. We visited Seven out in the Valley, and RIM came to talk (down) to us. IBM gave their pitch many times over. But all these people — and the real customers — really wanted from us was a bit pipe and a sales force who could sell and provision the devices to go on it.

So Vodafone and Sprint haven’t done anything to improve the state of the art in messaging. But the funny thing is, despite all the plaudits and fans, neither has RIM. Or Microsoft. Or anyone else for that matter.

The problem is that there is a narrow focus on “messaging” rather than productivity — just like VoIP results in a narrow focus on “calling” rather than successful conversations and relationships.

I believe that even humble email can be transformed in how it is used and managed.

I recently discovered the 43 Folders blog, which is dedicated to personal productivity and self-improvement. It in turn is inspired by the book Getting Things Done, which I’m too mean to buy (and too lazy to read), but have enjoyed reading this summary.

In a nutshell, it’s a system for turning your life goals into manageable itty bitty chunks that you have some hope of tackling on a dreary Monday morning in the office when you could easily be goofed off reading telecom blogs.

The “43 folders” moniker comes from the Getting Things Done (GTD) system itself. Part of the system involves consciously deferring things into the next 31 days, or 12 months (and 31+12=?). Move things out of your inbox — where they cause you stress and decision fright — into your system. Relieve your short-term memory of unfinished items. Give yourself a daily dopamine shot by clearing your to do list.

I’ve begun to re-organise my email system along these lines. Since I run my own email server, I’ve got a lot of control. As you can see to the left, I’ve created appropriately named folders in my inbox. Actions I choose to actively defer are slotted away into the appropriate folder. Today is Sunday, so if I don’t think it deserves my attention again before Thursday, I put it into the “+Day.04” folder.

Every night I have a script that runs and moves things down. Stuff in “+Day.01” moves back into my Inbox. Stuff in the following days moves down one folder. Stuff in my “+Month.xx” folders that has appropriately aged also cascades on down.

I also maintain a +ToDo folder. (In case you haven’t worked it out, the “+” symbol simply forces these all to the top when sorted alphabetically.) In this folder I can expect to see the half dozen or so things I expect to do today. By keeping this separate from my inbox, I’m not forced to treat incoming mail as “to do” items. If necessary I can consolidate a whole bunch into one “to do” message, and file them away.

Having a separate ToDo folder also forces me to separately consider emails that re-emerge into my inbox after a period in purdah. These appear as read items, whereas truly new emails are, naturally, unread. Old “to do” items don’t just silently slip back into my to do list.

Every time I think of a new “to do” item in my life, I send myself an email, and file it an appropriate time into the future. Of course, I also maintain a traditional calendar for events that are truly fixed in time.

Now, I would hardly claim to be the world’s most effective action-oriented person. The three minute morning blog and email fix has been known to take three hours and more. But this system definitely helps a serial procrastinator such as myself to make a start on even the most unpleasant jobs.

It isn’t perfect. For example, the GTD system suggests the use of project folders to group to do items. The limits of my email client just don’t make that very practical. It’s too hard to manage. I can’t, for example, take a virtual view of all my current to do/next step items across multiple projects.

There is an honourable exception to the statis of email technology. IBM’s research labs have been busy creating new means of visualising email. Yes, we want better ways of viewing large data sets. Yes, we want to seeing the connections between messages and senders. But still they’re creating innovative solutions to the wrong problem. People need to be more productive.

That means respecting their finite cognitive ability, as well as understanding their complicated social relationships. If your boss sends you an email with a sentence ending in a question mark, perhaps your PDA needs to make this swell in importance?

(Hmm - the Personal Digital Assistant only ever delivered on 2 of those 3 words. Assistance was sadly lacking. If Palm make the handheld computer, I’m looking forward to a company called Brain making the mindfelt computer.)

This could spell good news for a few players. If they cracked it, Microsoft and IBM would be extremely well placed. They can add proprietary extensions to their dominant messaging server products and email clients to support the advanced slicing, dicing and workflow that true productivity demands. Your old fashioned open source IETF-standard compliant messaging engine won’t be competing in the same market any more.

Device makers could also benefit. The beauty of the Blackberry is just the responsiveness of its actions, and the speed of the scroll wheel. But it’s incomplete. How can you quickly categorise and file actions? How does it fit into your project workflow? Why doesn’t it automatically highlight client messages versus internal chatter?

The UIs of some of RIM’s competitors don’t lend themselves well to “productive messaging” paradigm. Consider a Pocket PC with a touch-screen and a stylus. You’re trying to associate each incoming message with an action and/or destination. But drag-and-drop just doesn’t work that well.

I kind of imagine taking the touchpad technology from my laptop and putting a “touch strip” along the edges of the screen. Scroll and tap in multiple dimensions. Left and right scroll strips might even do different things.

So whilst there’s plenty of room for improvement, don’t hold your breath for any cellular carrier to help things out. Even IBM would turn blue in the face waiting.

Sneaky

Am currently doing my thing in Vilnius, Lithuania. Have slapped a local pre-paid SIM card into my unlocked phone.

What’s really cunning about their price plan is that they charge you LTL 0.25 (about 7 eucocents) just to check your balance. So presumably people will top-up unnecessarily often and maintain a higher balance that they otherwise would.

Free cash float, dontcha just love it.

Just a game

I can recommend this short but thought-provoking article over at The Mobile Technology weblog.

In essence, it critiques mobile J2ME and BREW because they’re denied access to the communications-centric functions of the mobile handset.

I’ve long thought the same thing. What I’d like to see is these environments deploy “opaque objects”. This means that they would be able to query and manipulate things like your address book, but without actually seeing the data. Only the phone OS would see the data itself; the program would just hold an object handle. Functions like iteration through the address book, comparison, and set operations, would all be offerred. A number of user interface components would be offered native to the device to perform standard operations like the selection of one or more contacts, or the addition of new entries.

This would help to reduce the danger of privacy and security lapses. A progam that can’t see your actual address book data can do less harm to your privacy.

I also believe that the provisioning of access permissions of applications could be substantially improved. When I download a J2ME application, and it wants to access the network, I’m forced to go through a handset-mediated screen asking every session if I want to accept once, repeatedly (but just for the session — not forever), or not at all. This is a gross inconvenience. We don’t pop up a “do you really want to make this phone call” confirmation when you press the green button.

What I’d rather see is the permissions get set at install or purchase time. The install-time part is fairly self-explanatory — you set the access parameters to resources like profile, address book and network. The purchase-time one is more subtle, and really refers to the wired Web. The download app would come with a digitally signed set of permissions from the retail environment, where you have provisioned your access preferences. When you buy a certain networked game, you just tick a box saying “I understand that this game will be given access to my address book, and may access the network incurring packet charges.” The appropriate permissions are then tagged on, and you are never asked again on the handset.

Some of these could be parameter-driven. For example, my email application may be allowed to transfer up to 1Mb a day without asking, but above that I should be asked to give my consent. Waiting until the app is on the phone is too late to start provisioning this kind of thing.

This would possibly give network operators’ in-house mobile portals a large advantage, as third party sites may not have access to this signing facility and their user experience will suffer. Users downloading from third party sites would have to deal with more intrusive access screens on the handset.

Naturally, a balance is to be struck between privacy and convenience. You can ask too many authorisation questions and put people off. But today’s model of simply not allowing some highly valuable functions to be accessed by handset applications is decidedly not convenient, either. There are many low-level functions in the phone which could contribute to an enhanced application experience, if only the operators and handset makers weren’t so scared of exposing then.

This model also extends to Windows applications. We won’t see it, because Microsoft has gotten lost in the wilderness, but here’s what I’d like Windows to do when I install a new app. I should be presented with a human-digestible list of the key permissions it is requesting: “Access the web site ‘foo.com’”, “Modify files in the ‘My Documents’ folder”, etc. (By default, it should only have access to its own preferences directory. And I should be able to increase or decrease permissions — not just ‘take it or leave it’.)

Just because an app gets a buffer overflow or has a control logic bug shouldn’t mean it gets to trash my whole hard drive and access the whole Net. All those worms that download via browser bugs would have a hard time, because being able to execute arbitraty code wouldn’t automatically enable access to all OS functions. If you go to hax0rs.com by accident, and get a pup-up from the Windows OS asking if you want to authorise access to your address book, you should be deeply suspicious.

(As an aside, the security model of Windows is very broken, and will stay that way, because actions are done on behalf of users, and not applications. Just because I downloaded and installed an application doesn’t mean it should be trusted as if it were me. The user model doesn’t match the trust model. Unix/Linux is barely any better, but at least you can fake it by creating a different user for each app and constraining its actions accordingly. Ideally you’d have a file system where any haywire application could be terminated and the changes it had made simply undone. Windows also doesn’t make it easy to distinguish pop-ups that have come from the OS itself from those generated by the application. Another security headache.)

I hope you’ve managed to follow this rather abstract stuff, but really it’s very simple. If you’re going to give applications access to data and facilities that could harm the user, you need to put in appropriate controls, and make the provisioning of them simple. It may be just my ignorance of current developments in 3GPP standards etc., but it seems we are lacking on all three fronts.

Ignominious

Om and Aswath pass comment on the latest generation of VoIP telephone adapter, called PhoneGnome.

On the downside, this product can’t be saving many potential users much money as they still need a POTS line. The self-provisioning of this device’s long-distance supplier details looks like a problem for the mass market; potentially lots of support costs. (Assuming I understand correctly how the product works.) It only improves the calling experience marginally.

That said, I’d give it quite a warm reception, particularly for a V1.0 product. If marketed well it’ll find a ready SoHo, small biz and heavy home user market, particularly outside the USA where call costs are often higher, choice is sometimes lower, and international calls more frequent. By focusing on ease-of-adoption rather than featuritis, it certainly stands out from the crowd.

It unclear how much benefit you get if your correspondents don’t have a similar box. The number of people using Internet-open SIP-addressable phones is infinitesimal. Given a choice of telling your buddies to speculatively buy a $119 box, or download Skype for free, it’s not difficult to see which route most price-conscious technically-savvy users might go. If PhoneGnome was able to tap into Skype users from the outset as its ‘free calling’ base, the network effect would be stronger. But that would require Skype to allocate all users a number from some ITU-blessed VoIP range, and get sucked further into the interconnect and regulatory tar pit.

There seems to be an obvious ‘service’ opportunity that is missing — dynamic carrier pre-select, where every call is sent over a least-cost provider using appropriate prefix codes. (I’m thinking there’s a market here in the UK to stand on the street with a laptop and SIM reader, and offer to reprogram people’s address books on their mobile SIM cards by prefixing numbers with lower-cost prerouting codes…)

Incidentally, PC-based VoIP is a very different animal partly because you do PC-based things like exchange URLs, share desktops, swap files, and forward emails during the call. If offers a fundamentally different experience and addresses different needs. So it has a totally different market demographic and economic drivers. It isn’t totally fair to compare this to Skype, except as a learning experience. PhoneGnome is aimed at a specific market of people whose communications lives may be phone-centric without being PC-centric. So overall, a thumbs up for extending the footprint of VoIP to new markets and users.

Objection, your Honour!

In an otherwise excellent article at El Reg on Vodafone and VoIP, I just had to comment on this one:

The plan is to exploit the superior spectral efficiency of the 3G networks to bring voice prices crashing down and remove the main advantage of VoIP.

Bzzzzt. Nul points. Please re-read your Stupid Network primer. The point of a Stupid Network (as implemented imperfectly by IP) is unbounded option value. In this case, the ability to do new things with voice calling.

Remember, not a single Vodafone customer, not one living soul out of over 100m people, can tell if the person they’re calling is already on a call before they press the green button.

Until they start “innovating” (you call that innovation?) and creating a better communications experience, they deserve all the price pressure they get.

OPINION://Twist in the tail

I’m really unhappy with the information architectures we adopt to display presence information. Many of you will be familiar with the work of Edward Tufte and his innovative displays of multi-dimensinal and fluid data on 2-dimensional static paper.

We need to do better with presence data, because that data is going be become a lot richer. So inspired by Tufte, let’s see what we can do. I’d like to introduce to you my little pet Tod the Tadpole. As you’ll see, I was diagnosed with disgraphia horiffica and have the drawing age of a 3 year old. Never mind.

(A friendly wag suggested this should be Simon the Sperm, but as a family blog I’ll demur…)

What this does is adds some more dimensions to our presence display. The most obvious one is a temporal history of our availability. In the example, when the tadpole tail is high, you’re available, when it’s low you’re not. The time scale is squeezed up as a log scale; the last minute and last hour might have the same pixel-width; the far end of the tail might be summarising whether you where around at all last week in just a few pixels.

This history is useful. If someone has just got back from vacation, you want to see that. If someone’s online all the time, there’s no rush to grab them; conversely, if they’re rarely online and you see them come on, call them now!

The up-down movement of the tail is smoothed by adding some inertia; coming online doesn’t make it zoom straight to the top, but applies a point force that accellerates it in that direction. (I guess some user testing would tell us whether “y”, “dy/dx”, or “d2y/dx2” is the right vertical scale.)

Day and night are shown too. This is important when buddies might be spread around the world and very mobile. I’ve drawn it really badly, but twilight and dawn would be light grey, whereas the middle of the night would be a jet black background. Tod is approaching sleepy time. Naturally, the lengths of the day and night phases would reflect your actual daylight at your current latitude.

You might even choose to colour the daytimes with weather-related information from the locale of the person, such as temperature hues or a pattern of raindrops.

The tail might also encode data about the nature of the presence, beyond being online or offline. For example, the red parts could indicate “busy” — i.e. typing, talking or dragging. (Just clicking in a browser might be regarded as the equivalent of being idle!).

Episodes of mobility, where such data is available from the user device or a network operator, could also be displayed, such as by using a dotted line.

Looking into the future, the background might indicate someone’s predicted presence status. If their calendar has a meeting shown, add a border for “busy”. If they’re due to catch a plane, add a border for “away”.

The “head” of the tadpole is also presence-enriched. If you’re listening to music, a set of headphone appear on your head. Hey, the little sound-marks coming out of your ears could even beat to the music! Roll the mouse over, see what they’re listening to. If you’re on a phone call, it looks like you’re wearing a headset. And so on.

Of course, the head icons would be personalisable for more immediate recognition. After all, they’re your avatar. A great service would be one where you could feed in a normal digital photo of yourself, and it would do all the pattern and colour recognition to churn out a race, age and facially structure look-alike (assuming that’s what you want!)

Facial expression could also come into it. A huge chunk of our brain is given over to watching faces, and it’s not used much in today’s presence and telephony. Don’t show a clock icon when someone is away — make them look like they’re dozing!

Ideally the head would have a contextually appropriate background, such as a stylised version of “home”, “office”, “car”, “out and about” and “abroad”. Tricky with a small icon, but possible if you allow a little more screen real estate.

Which brings me to my last point. Take a look at this miniaturised screenshot of Skype.

Yes, it’s weeny. This protects the privacy of those careless enough to become my buddies. But more importantly, it lets you see the overall structure rather than the detail.

What do you see? A ton of whitespace! Is this vertical scrolled list the best possible information architecture for presence data? I think not. Now, I’m not sure what the right one is. You need predictability of location so you can find folks. You need to properly group and sort according to current presence status as well as tribal affilication (different work, family and friend groups). There’s a lot of variables, and an unconstrained space on which to display them. Other people get PhDs doing this stuff.

Why is better presentation of presence data so important? Because the toughest part of a phone call is the rendezvous. We often miss each other, play phone tag, have hurried “can I call you backs” (and don’t). We often simply don’t make some social calls for fear of calling at a bad time, and eventually relationships with old friends dissolve. Anyone who thinks telephony is just about creating a duplex audio stream isn’t looking at the whole problem.

Anyhow, I eagerly await for someone to rise to the challenge. In the meantime, remember Tod the Tadpole next time you accidentally call someone at 4am — who isn’t there anyway.

Navel fluff

This is pure indulgence, so I do apologise in advance for such abuse of your attention. Since I’ve already harped on about my life story, I’m going to extend my personal introspection.

In about 10 weeks, this blog will be a two year old. It’s time to grow up a bit.

It started off as a hobby and an outlet for boredom and frustration. Now, indirectly, it’s my living; my “marketing department” for my brain services.

But how do you build a business model around a blog such as this? At the moment I do consulting and strategic advice. It does well enough, but I’d like to do better. The cost of sale is too high to make the business scale well.

Yet there’s a catch to blogging as a means of promoting yourself as a consultant. I have to keep back all my best ideas and arguments behind the consulting pay-wall. They then don’t get as wide an audience as they deserve (in my humble estimation). And they don’t benefit by being beaten about in the blogosphere. Word documents don’t autonomously improve overnight whilst sat on my laptop hard drive.

I was kind of sad that Nokia recently closed down their sponsored public wireless think-site, The Feature [don’t click, it’s gone 404]. OK, they didn’t market it well and get the brand goodwill they deserved from it. But the site was filled with good ideas. I don’t know if the contributors were getting paid. It certainly points away from trying to get sponsorship to write useful stuff that a broad audience will enjoy. I’m under no illusions that anyone is going to pay me just to write.

It would be interesting to find some allies in the big strategic consulting firms, such as McKinsey or Booz Allen. Having been on the receiving end of their work, I’m sure mine is every bit as good — if not better, when it comes to “stupid network” stuff. There are some good boutique advice shops like Analysys, too. I think I could help them deliver better advice. But I lack inroads to any of these; thoughts anyone?

I guess I could pursue an academic job where you can just think, talk and write, but I find that world rather closed. I’ve no aspirations to follow an academic career path. And the pay doesn’t match my tastes for the good life!

I’m getting tempted to break up all my (publicly reproducible) consulting work and start posting it up here. But to do that I’d need some quid pro quo. One route is to take the Google dollar. Slashdot today points to someone offering good advice on how to make a very comfortable living off AdSense. At my current traffic volumes, it’s probably more than coffee money, but nowhere near a viable living. I’d have to get a lot more into the down and dirty of product reviews and company profiles to generate better ad fodder, and increase pageviews. I’m not sure if that’s what I or you want.

I hope you’ve enjoyed reading my essays and ideas. I think it’s a unique site, and one of only half a dozen in the subject area. I’d now like your feedback on what you like and don’t like; what you’d like to see more of; and any thoughts you have as to how I can put more time and energy into it without having to worry about how the next Caribbean holiday will be paid for! Feel free to post comments, or if you’d like to protect my ego or send something confidential, just email me at feedback@telepocalypse.net.

OPINION://Phoney teleconomics

Presence data is important. So important, it’s the central economic driver of any future telephony service.

In the old world of telephony, you were forced to rent connectivity and service in a tightly coupled bundle. Economic activity begins when the phone call begins, and continues at a steady rate until the call ends.

In the new world, this model in inverted. As a result of technological progress, connectivity becomes very cheap to the point of being supplied on an all-you-can-eat basis at low prices. Its supply is highly fragmented (i.e. you will roam across multiple cellular, Wi-Fi and fixed networks during the day). Once a phone call is initiated, there is no “service” being delivered at the application layer that cannot be done in the peers themselves. The marginal cost of data transport for a thin audio stream is (effectively) zero. Thus when the call starts, economic activity ends.

But here’s the kicker. There is a great deal of economic activity before, during and after the call. In particular, the immediate period before the initiation of the call requires the exchange of presence data so that the caller and callee rendezvous at a mutually convenient time via an appropriate medium or channel. Most of the economic value in any future “telephony service” will come from the brokering of presence data between multiple sources and sinks.

Customers have voted with their wallets — they like to talk. The quickest way to create more value is to enable more successful conversations. Presence helps curtail playing phone-tag and voicemail ping-pong. Vendors and operators who fail to align their products with what the customers value are less likely to prosper. Unfortunately, that appears to count in most of the industry.

Here’s a picture of the new world, as I see it:

Don’t take the scaling on this diagram too seriously — it’s just a brain-fart done in public. Here’s a guide to what I’m thinking:

• In the “before” diagram, we see money changing hands mostly during the phone call. Some of that money is used to subsidise the handset handware and software.
• In the “after” diagram we see three very different profiles for the connectivity, application services and hardware platform.
• The hardware one I’m least certain of; in the diagram it becomes more of a one-off purchase and cross-subsidy is weakened. This is because third parties claim an increasing proportion of the application revenue, or the application revenue just evaporates. I’m willing to accept that new forms of cross-subsidy may emerge here (e.g. think of Tivo as an example, where the hardware and service are coupled, but the connectivity isn’t).
• The connectivity may involve some up-front expenditure by the user, either in hardware purchase (e.g. Wi-Fi access point at home; membership fee). There is then a steady trickle of all-you-can-eat money, augmented by occasional bursts of premium metered connectivity revenue (e.g. roaming abroad, on an airplane).
• The service revenue model is completely disrupted. Most of the money comes in the operation phase before the actual call; connecting people via social networking, directory services and presence. There is no service revenue from the phone call per se. (There are important exceptions, another essay.)
• There may be transactions during the call that are mediated via third parties, particularly on multi-modal devices. (Again, I’ll elaborate in another essay, maybe perhaps.)
• There’s some follow-up phase which I struggle to find a name for where successful phone calls feed back into future successful conversations and relationships. For example, if we talk for an hour, that says a lot about our social relationship. If we only talk during business hours, that tells us something new. There’s gold in ‘dem ‘dar CDRs!

Ultimately, as I have previously argued, people demand successful conversations and relationships, not just reliable phone calls. Presence is a vital enabler. Deliver that, and you’re onto a winner.

Battered by batteries

A client recently made a comment that’s set me thinking. He noted that low bit-rate always-on data — such as that from presence feeds — tends to drain mobile handset batteries very quickly.

This is not news. But the significance is slowly dawning on me.

Firstly, a lof of wireless data technology roadmaps focus on increasing speeds. But the industry is likely to be taking a wrong fork in the road here. As Flarion discovered, and Andrew Odlyzko has long espoused, low latency is where it’s at. Andrew’s long-standing quip is that if you don’t care about latency, the postal system and a DVD burner is a great broadband solution available everywhere today. Flarion’s wireless technology is capable of sending a single bit in an efficient manner. This is a by-product of their innovative and efficient MAC (media access control) algorithm, which negotiates who gets to shout when. Flarion doesn’t assume the purpose of the network is constant bitrate applications over long session.

(Another reason to be suspicious of NGNs, which are also session-centric via expensive centralised proxies, and not presence-centric via P2P connection. Relaying tiddly presence messages is going to consume a lot of expensive CPU time — one or two orders of magnitude more than call data.)

Presence data is likely to be highly asymmetric. If you have N buddies, and you’re all producing the same bit-rate of presence data, you’ll have to download N times as much as you send. On the other hand, general network traffic is becoming more symmetric — think 2-way video, P2P file distribution.

For battery-constrained devices, this suggests an opportunity for vertical integration of the radio access network, handsets and telephony software. You design handsets with some dual-form radio. Part of the radio is in an “always listening” mode, accepting presence data and other low-bitrate trickle feeds. Rather than activating the transmitter to say “sorry, I missed that bit — could you say it again please”, data could be re-transmitted over and over by the mains-powered cell tower. This helps preserve battery life. At some expense, it could even be done at a lower frequency that conserves more power and had wider reach. Kind of a Microsoft SPOT watch blended into a cell phone.

Most presence data is not so vital that a few lost bytes or a minute’s delay is critical. And some form of sequence numbering can give the handset an idea it’s missing a lot of data, wake up and directly request re-transmission.

This is bad news for companies like Skype who may hope to piggy-back on fast cellular networks. Yes, I’ve received calls from people using EV-DO and laptops; or airborne Wi-Fi and a Pocket PC. But that’s not a mass-market proposition. I suspect that the limiting factor on deploying mobile Skype-like applications isn’t network and handset lockdown, but battery life.

It is widely assumed that the future of telephony is purely “mobile”. I’m less sure, at least in the medium term. I think that the “nomadic” or “portable” aspect will be very important — and even fixed telephony isn’t yet ready for its coup de grace. What does this mean? Well, your wired desk phone doesn’t lack for electrical power. It can offering a richer presence experience — even always-on webcam images of your cat’s basket or whatever you desire. Phones which have a power dock, like your traditional cordless handset, become relatively more attractive. The device offering the worst telephony experience may indeed be your traditional mobile handset. Battery technology is somewhat stagnated as a matter of physics (you’re trying to make safe, reliable things with bomb-like energy densities). Perhaps it’s time for handset makers to concentrate on improving the recharging experience?

In summary, the IP abstraction is a purely functional one; it takes no account of non-functional requirements. Some of them, like QoS, turn out to be mostly bogus. But some are critital, and pure Internet VoIP solutions may not deliver. If you’re a telco looking to fight disintermediation, this is one rock to look under very thoroughly.

Is anybody there?

Based on seeing many comments like this on “meta-presence”. Time to make a prediction.

This meta-presence phenomenon is where we annotate our presence with customer names or away messages. Various stories are emerging of innovative uses of these facilities. At a very mundane level, I currently have my location appended to my Skype user name.

I’m sure I’m not the first to think of this, but “presence” looks like it’s going to evolve into a stream of XML documents that describe a whole slice of what is going on — and changing — in someone’s online and offline life. Call it “context”, if you will. The rudimentary presence we have today is but a tiny step. Much of the data in your “presence feed” may be encrypted and only those who you have armed with a decryption key will be able to access it. Your communications client will extract from the presence document the bits that are of most interest.

What’s important here is the de-coupling of the publication from the display. It is presumtious of the source of presence to decide in advance how the receiver will use it. A weakness of closed systems like Yahoo! IM, Skype, etc. is that they don’t make it easy to export and augment your presence. Your meta-message is hidden under a few layers of menu, not brought to the fore. It’s damned hard to put your Skype presence into a dynamic web page, although Yahoo make it easy.

The IM/talk networks have yet to fully embrace the idea of competing on the basis of richness of presence. We’re seeing some interesting pointers, though, such as MSN v7 showing what you’re listening to in your media player.

We’re also still waiting for an economic model emerge. It wouldn’t surprise me to see the concept of origination and termination fees for presence data start to emerge. This applies when there’s clear value being exchanged based on the direction of presence flow, and a means of constraining the path of that value exchange to force it through a toll booth. I don’t expect the presence data to be directly paid for by the end user. But a (premium content) dating site may import presence data to make dating into more of a real-time experience, for example. “Click here to call lovely Laura in London.” In this case, the presence networks pay the IM networks.

The potential for augmenting the calling experience per se is relatively constrained. But the richness of presence is almost unbounded, as is the value creation. I expect the economics of real-time communications to come to reflect that over time.

UPDATE: Here’s the story on workers using presence to flag their work availability.

Free!*

Thought for the day: what if Skype innovated in their charging mechanism for new services, such as video? What if a video call required at least one of the participants to have a positive SkypeOut balance?

This would be a case of “free (except when it isn’t)”. It reflects the zero marginal cost of service, but also reflects the non-zero cost of creating the software. But it also makes the spread of the software easier. You don’t need two people to commit to purchasing the software speculatively, in the hope that friends will also get the same software.

Syype makes its money from an increasingly large free float of cash, as well as breakage from SkypeOut balances expiring. If they’ve got an ounce of business sense, they’ll share some of the gains with the plugin providers.

For loyal Skypers who take the paid services, that serves to keep them happy. For others, it might just tip the balance into signing up for paid service. After all, it’s free, isn’t it ;)

Now, webcam video has plenty of “free” competition from other IM clients. But if your solution genuinely advances the state of the art (e.g. video conference calling, better compression, etc.), you want to see an economic return. You can still give away a basic service for no charge.

PS — How long is it until your SkypeOut credit simply becomes your Skype credit?

UPDATE: Don’t forget that billing innovation has an illustrious history of success, e.g. AT&T Digital One Rate, MCI Friends & Family.

Balkan Broadcasting Corporation

The BBC is currently experimenting with multicast video distribution. To do this, they’ve made agreements with a select number of ISPs who peer at London’s Telehouse mega-exchange in Docklands.

If the Internet is not a thing, but a network of peering agreements then we’re seeing something interesting here. On what terms will ISPs get to peer/interconnect for multicast traffic? In effect we’re seeing a parallel internet emerge, dedicated to a particular traffic type.

Rather than trying to collar exclusive content agreements, perhaps ISPs now need to get competing on who they can get multicast peering Will we see a “top-down” approach with only a few large media sources of data allowed? Will anyone be able to access any mediamegacorp content, or will it be fragmented, with different users only seeing subsets of what’s out there? The BBC suggest the latter:

If you have non UK users we have started work on an international service, content will be different and more limited due to content rights restrictions.

Or will be see a more “end-to-end” flat-world outcome where anyone can multicast to anyone else?

Definitely one to watch — the economics, not the TV.

Sad but true

I have to echo Jeff Pulver’s comments about emergency response, in the light of today’s mass murders in London, near where I grew up. [I’m up late, ignore the post dateline.]

When you can’t get hold of your friends and family, it’s seriously not funny — apologies for my resorting to British understatement. The legacy smart network is incapable of degrading gracefully under load. You can’t readily descend from wideband audio to narrowband, to push to talk, to IM and then down to store-and-forward email. The possibilities of IP in emergency service have gone from being an intellectual curiosity to a matter of real urgency.

Oh, and anyone who thinks the British will be their ideological slaves under threat of violence hasn’t read their history books very thoroughly. Too many of our ancestors have crawled out of lice-filled trenches to emerge into freedom for you to stand any hope of victory.

If I was down in London tomorrow I’d be buying a travelcard and spending my day occupying tube trains and buses to enjoy the ride.

OPINION://WAM, bam - thank you, Ma'am!

This essay is rather unlike anything I’ve written before on this site. Don’t worry, it’s very much about the separation of service from connectivity, and its effect on the telco industry.

But this time, it’s personal.

This is the story of Sprint’s pioneering, and failed, effort to become the first telco to turn itself into an open application and business platform.

The story starts in 1999 in Dublin, Ireland during a warm and pleasant summer.

At the time I was still a consultant at Oracle Corp., based then — as now — in Edinburgh, Scotland. I was working on a project for a somewhat fly-by-night supplier to Eircell. We were creating a custom Web-based bill-any-pay solution. Oracle was building the back-end, and as a database expert I was overseeing the custom code that imported all the millions of call detail records every night. The supplier was building the front-end, but somewhat lacking in in-house management skills had brought in a contractor, David Anderson. David hails from the area southwest of Glasgow in Scotland, and his towering presence and Scottish brogue are unmistakeable. David managed the team building the Web UI.

I have an enduring memory of watching the solar eclipse standing outside the office that summer, and still have the burn-marks on my retina to prove it.

We got to be good friends on the project, having a common interest in software development process. (I was churning out working Pro*C at several times the same rate a team of 2 had previously been churning out nonworking PL/SQL, until they got kicked out…)

Soon I’d wrapped up my work and moved on. I unexpectedly got a note from David in the early autumn in 2000. How interested would I be in going to work in Kansas City to change the world?

This could only mean one thing.

Time to get the atlas down and find out where the hell Kansas City is.

Since leaving Dublin, David had moved off to Dallas, TX to work (indirectly) for Nokia, soon to move on in the Internet frenzy to Sprint. Sprint was at that time divided fiscally and culturally into Sprint PCS — the wireless business — as well as Sprint Local and Sprint Long Distance. David had gone to work for a maverick VP, John Yuzdepski, running a classic dotcom era outfit, SprintPCS.com. This was constituted as its own independent business unit, set up in an overcrowded and uninspiring low-rise in the middle of a so-so neighbourhood just over the state line on the Missouri side of Kansas City. The BU had sole responsibility for construction, marketing, finance and operation of all wired and wireless Web offerings — and the boss was one of only four people empowered in the company to bring products to market.

That December I took a Friday off work to fly out and meet David and John for the weekend. Travel wise, it was a disaster: the flight from Glasgow to Toronto got diverted to Ottawa because of heavy snow. Our subsequent attempt to land in Toronto took two attempts. My direct connection to KC was long-gone, so I was re-routed via Chicago, only to stand on the taxi-way for 45 minutes to get de-iced. Missed my connection in Chicago, and ended up arriving the next morning.

Perhaps I should have taken the signals from the gods more seriously, but after a few good meals in an equally freezing KC, I’d been talked into it. By the end of April 2001, H1B visa in hand, we were resident in deepest suburban Overland Park, KS.

The release of an upgraded data network was prompting some hard questions from John’s boss, the SVP of Marketing, Scott Relf. Sprint’s main “data” revenue was from 40¢/minute overage from casual use of the 2G wireless web product. Scott’s challenge was this: as minute buckets got bigger, and as data pricing went from minutes to bytes (or flat-rate), where does the money come from?

Probably a question you want answered before you commit to a billion-dollar network upgrade, not after. But never mind.

The result was an effort to create a crack skunkworks inside SprintPCS.com to map out a vision for data services at Sprint. This is where the fun and fireworks start, because you’ve already got network, IT and marketing teams who believe this is their dominion.

The core staff team comprised four people: David as leader, myself, Dan Vacanti — a rare MBA who can write EJBs, and Wenqi Shen — a usability PhD. We had the support of a few developers to help build demos.

Somewhat bizarrely, David was not fully relieved of his day job of running a team of 20-odd developers building critical software to support the “3G” (i.e. CDMA 1xRTT, i.e. not really 3G) launch. (This service was later to be called “PCS Vision” — itself a brilliant marketing conflation of connectivity and service.) The only way this ever functioned was (i) David putting in an inhuman amount of work, (ii) having some kick-ass developers on the team, and (iii) establishing a development process that allowed him to leave most of the management of the group on auto-pilot.

This left him with a semi-formal reporting structure to the Senior Director in charge of software development, and a semi-dotted (or is that dashed?) line to John, the VP&GM. Being the same pay grade, I couldn’t report to David, so had a non-functioning report to the same director; we barely spoke in the time I was there. Even more bizarrely, the wife of the Senior Director was employed as a Director of Architecture. This, to say the very least, was against HR rules.

And since David’s team were outperforming other teams under our Director, and outgunning the over-confident and under-experienced architects, this created an atmosphere of intense rivalry and tension. We had no support base inside our own business unit as we were all too often making our formal boss look incapable, and his wife look incompetent.

It all added up to a serious HR mess.

Nonetheless, we approached our challenge with gusto. I’ve never worked so hard in my life, and Oracle and previous employers haven’t exactly gone lightly with the whip. But it was fun. Our remit was only to design a unique wireless web experience. We were moderately familiar with iMode — remember, this was before iMode really hit its stride. The lesson we had already taken on board was that it was better to take a small slice of a big pie than a big slice of a small pie.

Yet our approach differed dramatically from DoCoMo in several ways.

Firstly, we had put the whole user experience front and centre. Not only a portal and a payment mechanism, but also addressing the usability barriers. Smart systems for automatically selecting the portal content most likely to be of interest; personal data and profile sharing, to eliminate triple-tapping; a central address book, with an API into it; APIs into our messaging functionality; and so on to calendars, preferences, events, etc. In other words, a broad-based set services application platform that opened up both network elements and business processes.

We had also put a lot of effort into privacy and anonymity. We planned to insert a unique token into the HTTP request header of every page. The application could interact with our platform to request data on the user, or send a message. The token could be used as an identifier for the API call. This means users compromise as little of their privacy as possible. They couldn’t easily be tracked or identified without their consent.

Technically, our approach was very different to iMode, too. Some of you will no doubt wince reading me describe my earlier advocacy of “smart network” approaches. Boy, do I cringe too. But there was a logic to it all. We had to face the “tyranny of the installed base” — on day 1, 100% of the users were legacy 2G phones. Java in the handset was unproven, and any other software burdens on the handset unimplementable. So the only way out was to make the smarts sit in the network edge.

This means that if you tried to access a premium content site, and hadn’t paid, or your subscription or access rights had expired, then you would instead be presented by a network-generated payment authorisation page instead. All the content provider had to do was create an ordinary web site, and tell us what URL patterns to intercept, and what payment to associate them with. They then restricted access to only requests coming from our proxy. No need to install any special code or comply with complex protocols.

This wasn’t a unique approach, as we later learned — Firstgate were doing the same thing in Europe, unbeknownst to us. None of the suppliers we issued an RFP to knew of any ready-made solution.

Our vision was broader than this, though. Need some profile data on the user? Tell us what you want, using a URL pattern. We’ll pop up the authorisation screen if the data is already in the user profile; or a data entry screen if not. The result is then posted into the HTTP header of the request to the web site provider. In this way, we would have cracked the silos between different application providers.

The large amounts of stateful profile and preference data accumulated by Sprint don’t exactly do you any harm either when it comes to retaining customers. Indeed, by making the portal experience an adaptive, learning one we intended making this idea of leaving Sprint about as painful as getting a divorce. You’d have to train a new partner in all your quirks and dislikes.

(If there are any evil telcos out there to whom this sounds like sweet music, consultancy rates available on request…)

The barrier to entry to the two-guys-in-a-garage type developer would have been very, very low. Rather than just gun for big-name content, we’d have opened up the field. iMode was partly propelled by simply putting the most popular sites to the top, and letting the system auto-discover what was compelling. We wanted to go one step further and use cutting-edge collaborative filtering to suggest the most relevant content to you personally. If this came from Gus and Dawn in Lincoln, NE rather than Disney Corp, so be it.

A long-term hope had been to engineer every Sprint handset to have an illuminated Sprint logo, not just a printed one. Then any interstitial screens shown by Sprint would be re-inforcing Sprint as a trust-mark. Sprint is what protects your privacy, security and anonymity. (Stop giggling down the back, please.)

This effort was not synchronised in any way with the parallel — and better supported — effort to deploy Java in the handsets in Sprint. The conflicting and uncoordinated efforts of the Network, handset and .com groups showed that Sprint had no effective CTO leader, even if one (inside the network group) formally bore that title. Not helping matters was our VP’s tendency to make big promises of innovation while the basics of running the web site and developing the PCS Vision support infrastructure needed urgent management attention.

By October of 2001 we were ready to announce our platform plans to the world. Sprint laid on a developer conference at Caesar’s Palace in Las Vegas. In anticipation, we got the marketing communications people to pick a name for our baby. Dumbstruck by inspiration, they chose “WAM” — “Wireless Application Manager”.

We got a good turnout, despite the telecom meltdown being well underway. David did the heavy lifting announcement work; I just blathered about some of the background and speculated about where this might run to. It was exhilarating — up until 2am preparing, back up at 5am for rehearsals. But it all came together.

In the background, things were unravelling. The network division hated us with a passion. They had a group devoted to SIP and IP technology that would have been happy to see the earth open and swallow us up. They were also over budget in the 3G rollout, starving us of potential funds. The mainstream marketing folks only cared about getting content deals for ring tones and Java games. The IT groups were having a meltdown under a failing zillion-dollar program to in-source billing. Big plans for application platforms didn’t count for much — even if the SVP of Marketing was in theory the sponsor.

The SVP of strategy got some external consultants in to review our activities. Their recommendation was an “Innovator’s Dilemma” type approach, and that our platform should be spun out as a technology start-up. However, divorced from a guaranteed network to distribute its services, it had no chance of survival. Another round lost.

Personal relationships between the team and management were under a lot of pressure. We’d been working out guts out, our wives were tired of the politics and stress. The urgency of getting a working PCS Vision launch completed was erasing all other activity in the division. We found ourselves sucked into it, David chairing task forces, me writing the 3G download requirements spec, our developers reabsorbed into delivery tasks. In the end, even basic stuff like an instant messaging app failed to make the launch; the new wireless web — outside our control — was slow and bloated. The back-end was broken in a dozen ways, creating huge customer service issues and dissatisfaction. WAM never had a chance of making it as part of the 3G PCS Vision launch.

The company’s appetite for “doing an iMode” was wilting.

By the spring, it was all over. Our VP left the company in, um, rather a hurry. (The Telepocalypse legal department says: “say no more”.) So did his secretary. (Martin, be quiet.) So did his boss. David quit the company to become a director of development at 4thpass (now a Motorola subsidiary) making content download solutions. (He has subsequently written a groundbreaking book on applying lean manufacturing principles to software development, and is working at Microsoft guiding the development of the future of Visual Studio and MS development processes. You can check ou his blog here.) The business unit was handed over to an interim VP who carefully guided it through to the launch of PCS Vision. The business unit was then dissolved, the team dispersed. It was all over.

There were some executives who really saw how important our platform could be, and saw the option value of it — the negotiating power it gave them with suppliers like Sun, IBM and Microsoft. Some were curious, and at least gave encouragement even if overt political support wasn’t forthcoming. But the overall feeling was one of battle weariness and short-termism in the fallout from the failed Worldcom merger, ION network decommissioning and difficult PCS Vision birth.

That August in 2002 I shamefully had to pretend at the second — and final — Sprint developer conference that the plans for an application platform were still in place. Formally, the RFPs were still alive. I didn’t enjoy telling 600 people WAM was still alive when in my heart I knew this not to be true. Sprint is lucky the vendors bidding all still wanted a functioning relationship; otherwise they’d be looking to sue Sprint to recover their bid costs.

I hung around for another 2 years through the slump in a succession of non-jobs until it was time to strike out on my own. The grim job reaper failed to call as tens of thousands of Sprint staff went through separation therapy. It was a great time to travel cheaply in the USA, and I and my wife made the most of it at weekends and vacations. Although dispiriting not having anything real to do from 9.30 to 4.30, we found other ways of making up for it.

In retrospect, we were naive in many ways. From a purely technical viewpoint, I was only dimly aware of the “stupid network” principles. We failed to start with a business case, and get some real facts on how much a 1% reduction of churn might be worth, and to demonstrate how we might really deliver that. The Japanese culture could accept a strategic initiative on the basis of hunch and logic; an American business culture was too conservative for that.

Critically, we failed to make the right internal alliances and get the broad political support we needed. CEO sponsorship would have been a big plus. I’d now choose a few small things most people could agree on, and just get those done to establish credibility. Build on small successes, no big vision; companies like Sprint can’t execute on projects with high technical and market risk, as the culture isn’t there to support it. I’d now also put voice calling at the front. Can we up-sell people from a wireless web page to a voice call? How much is that worth? Can we revenue share with the content partner? What’s the effect of automatically building address books, and making sync really easy?

Hindsight is a wonderful thing.

But it was a great ride, I don’t regret it for a minute despite the personal stress, and learnt a lot. For a boring old centenarian phone company from Kansas, Sprint is quite a storybook, and WAM is a fascinating page in it.

[Footnote: David helped review this for historical accuracy, but mistakes and libel are all my own responsibility.]

UPDATE: Dan Vacanti adds:

“One other stumbling block that I thought of: Remember that [Sprint was] trying to replace the billing system at the same time that they were launching 3G. That meant that even if we finished the RFP process and actually picked a vendor, we would have never gotten into production as all of the IT release cycles were filled up by the biller.

The story was good, though (even if you didn’t mention me enough).”

Cheers, Dan — glad to give you the exposure ;)

So folks, Sprint happily stumbled along with a failing billing project, writing off $300m at the end; but it couldn’t find a few million to become a viable platform player.

The sincerest form of flattery

Well, I tried downloading Skype-clone Gizmo and making a call.

But it doesn’t work. Just hangs after trying to connect to the login server post-registration. I’ve got a bog-standard HP Windows XP laptop.

Remember, it’s not just free Internet telephony that counts. It’s free Internet telephony that just works.

Data, data everywhere – but not a drop to drink

You can get a cellular signal even in the remotest places you go on holiday. However, progress is a patchy thing, and some of my experiences getting mobile data to work were so spectacularly, splendidly and unrelentingly dismal, I thought I’d share them with you. It’s quite long, so maybe get yourself a coffee first. If you’re an investor in telcos, I’d make that an Irish coffee. A stiff one.

My objective was simple: be able to access my e-mail while I’m away without my laptop, so I know there are no fires in my little consulting business needing my urgent attention.

Firstly, you need some connectivity.

The only mobile phone we have — I got one for my wife as she’s out and about more than me — is a Motorola V525 with a Vodafone pre-paid SIM. (Why Vodafiend? Purely professional interest, not value for money.) It was bought from box-shifter Phones4u in the local shopping mall. Nothing remarkable. Later, it was sent into a friend’s secret back-room for unlocking from satanic mind-control forces, but otherwise appears normal.

First wrinkle. Vodafone’s flagship data offering didn’t work out of the box. Press the Vodafone Live! soft button, get an error. The SIM card didn’t seem to be provisioned for GRPS — a call to Vodafone customer services to fix. Oh, and each call to fix their screw-ups costs me 25p. The GPRS settings also didn’t match those on the Vodafone web site — and those on the Vodafone web site differed depending on how you searched for them. Another call. 45 minutes on hold. Abandon to bath baby. Another call. (“Does this gateway give me full Internet access so I can use my phone as a modem with my laptop using Bluetooth, or is this gateway just going to give me access to Vodafone Live! and/or web sites?” I might was well ask if Vogons like ice cream.) The Motorola website is also supposed to help you provision your phone, but didn’t have any option for my phone, plan and network combination.

GPRS is a notoriously awful system to provision. It just doesn’t seem to be able to bootstrap itself into discovery of the right gateways. Why couldn’t everyone have agreed to have the same default gateway for Internet access, and have whacko settings for anything else? Just so you know, I got the phone unlocked after having the GPRS problems, so it’s not my fault!

Eventually it all springs into life, and I can access their portal.

Next stop, get the email client set up. Whoopee — there’s one built-in, and it even does IMAP. It has a separate set of GPRS settings, just to make things easy. Tap, tap, tap. I run my own email server to have total control, so I can see it connecting fine through the firewall. It works! Err. Once. And never again. I subsequently discover this is because it can’t cope with more than about a dozen messages in your inbox. Of course, why would anyone want such a crazy thing? But I’ve got better things to do than debug Moto phone software, so time to try something else.

Do a Google search on “J2ME IMAP” and follow some links.

Download the Sirius email client. Errr? Ummm? Where is it? Not in the applications folder. Eventually find that all J2ME downloads end up under the “Games” sub-folder of “My Items”. Naturally. Install, configure, more triple-tapping. Run. Bzzzt. Crashes on sync. No error message, just dies.

Next candidate, please.

EmailViewer from Reqwireless steps up to the plate. More download, configure, tap tap tap. Try it and SUCCESS! It works, I can read my mail.

So off we go on holiday, and it works like a dream. I go for a few days using the trial version. I hit the daily usage limit and am impressed enough that I’d like to buy it. Click the registration link. Follow the pages of e-commerce crap, eight thousand taps later we get to a drop-down box for your platform type that simply doesn’t work. Does nothing. But you can’t submit the form without it. Give up.

Ooh! My accountant wants to know if I want to run a payroll. Absolutely! I send a reply. “We must verify your email address before accepting replies.” OK. I do it. The outbound message is lost in the process, but I have no way of knowing until I get home and no payroll was run. Thanks.

Get to the end of the trial period — last day. Cripes! Let’s have another go at registering. For some reason this time it refuses to deep-link into the Handango m-commerce site. I’m forced to start from the home page. OK, whatever it takes to get an activation code. I’m getting good at this triple-tap stuff.

I only started taking notes about half way through this harrowing odyssey, so my apologies if some things aren’t 100% right or are out of order — the gist is all true. Here’s the lowlights:

• Start off by searching for the application I want to buy from the full catalogue.
• “Low memory - page truncated”. Cool. Nice to know the Moto browser works so well. Not.
• I’m paying data charges to download banner marketing stuff at the top of every page. And I mean every page. I don’t care if they’ve got 75,000 or 75,000,000 apps to download. I don’t want to scroll past the same slow-loading image logo. Just give me my search results. Scroll, scroll, scroll. Search results are many screens off the bottom.
• This is a really splendid one. I mean so stunningly crap you have to stop and wonder if this is a big joke. Have The Onion and The Register got together in a joint production to build a spoof m-commerce site? All the search results have several big, boring image-based ads for unrelated products like Amex cards. Yep, show me a 15Kb image, charge me 20 cents to see it, make we wait another 10 seconds for the page to load. Cool or what!
• Everything is an image. Even basic stuff like “continue” and “checkout”. Slow, expensive.
• Lots of “chrome” — wiggly arty lines as separators made up from multiple sub-images. Except they don’t render right. Looks a total mess. Costs a fortune. More clickety scrolling.
• Ooh, time to enter my country. Ah. A list of all 250 counties and territories in the world. And I’m in one beginning with “U”. (Hey, maybe they should read my article!) I’m starting to get repetitive scroll injury. Perhaps most mobile data users are in Armenia and Albania?
• Select your phone model. (Isn’t this in the UAProf headers?) Despite having earlier established I’m shopping for Motorola J2ME apps, offer me options like a dozen Blackberry devices. And a long, long list of every Moto device. I’m starting to wonder what the MTBF of the down-click microswitch might be. Not to mention my thumb.
• Lots of data entry. And most of them default to the wrong text entry mode.
• Everything is one vast long form, a perfect mirror of their PC web site checkout form. So if anything fails to validate (and it will), you’re back into marketing spiel, ads, and scroll, scroll, scroll. Nothing tailored for mobile (and this is the #1 vendor of mobile apps, folks.) Not broken into bite-sized chunks.
• And when it fails to validate, only some of the fields will be filled in for you automatically. Tap, tap, tap. Re-enter data. Sing praises for Moto auto-complete learning new words and phrases.
• Opt the user back into accepting email offers when re-displaying the form. Why not? They’re just so riveting to read on the email client you’re still trying to download and activate…
• Make the user enter their email address and password twice. It’s a good luck thing in Japan, apparently.
• Star-out the password characters after they’re entered. You never know who might be spying on you from, err, outer space.
• Don’t do anything intelligent at all with things like address data entry. If it’s a UK address, make sure you ask for everything. Even if a postal code and house name/number is enough to do a database lookup to fetch the rest for all UK addresses.
• Zero tolerance. Only accept phone numbers in your favourite, secret format.
• Really screw up the layout, and make things like radio buttons and text for credit card selection randomly splatter around the page.
• Blow up. Fail. Just display a black screen after the user finally enters everything right. Show an error when the user clicks “back”. No escape. Finito.

This glorious experience took 45 minutes of my time. I make a note of the before-and-after balances of my pre-pay account, and just the failed purchase cost me £2.17, or about $3.82.

Vodafone already have all my personal and payment details registered. They could have offered a payment platform, or a set of web services to access this data. They haven’t, because they think it’s far more urgent to sell TV to mobile users. Standard cellco wannabe media company envy complex. The people are cooler, the parties are better. Who wouldn’t? Making money by enabling easy transactions is just too dull.

While I’m having a go at Vodafone, here’s a few more ways their portal is broken:

• Choices of multiple news or weather providers, but no reason to choose between them. Just a brand name. At least give me a tagline!
• Premium content by surprise: triple tap in your custom weather requirements, several layers of menu, and bingo! Now we’ll tell you that’s a premium service only available for a monthly fee. Cheers.
• 3G up-sell at all costs. Yeah, I really want 3 screens of 3G up-sell to watch a 1.3Mb video before seeing the rest of the news article text. (That 1-minute jerky video would cost you almost $5 to download over a GPRS connection, if you lived long enough to survive the wait.)
• Lack of integration. Vodafone portal down, get a 502 error. Vodafone portal up, get a cached 502 error. I guessed from the timing it was cached and did a reload; many would initiate a care call. Cust sat down, OPEX up.
• Content above communication. Boring premium content stuff first. Not everyone wants to browse for tones and babes…
• Stale content. Home deck headlines way behind reality or even headlines in their own news service.
• Unnecessary confirmations to exit. The web is stateless by default. Just exit, and take me back to the same page when I restart.
• Lack on control over customisation (I want small fonts) and personalisation (I don’t care about ringtones and pics).
• Just a lot of clicks - 4 to scroll down one menu entry. Wasted space. WAP v1 wasn’t this bad!

Overall it’s OK, but nothing to get excited about.

Anyway, back to the main story. A few days later, one last go at registering my email client. Now we’re past the trial period. Fire up the app, click register, and it refuses to take you anywhere. Says you have to go to the wired website to buy. Tough shit, otherwise. That’s right, the trial period has expired so we’re not going to allow you access to buy this product. Business genius — I should write an article for HBR on it.

Luckily, I had suspected that disaster would strike, so I gave myself a back-up plan. I’ve been in this IT thing long enough to know that cocked-up is the natural state of affairs, and a Plan C is never a bad idea. I opened a Vodadone Mail email account. (Oh, just another two calls to customer support because their web self-provisioning doesn’t work, and password reset doesn’t exist.) Eventually we get there. I forward copies of all my inbox messages to Vodafone, and I can browse them via the wireless web. Not great, but better than zilch.

You won’t be too amazed to learn that the address book in the web-based mail app in no way syncs or integrates with that in the phone. Modal, moi? Such seamlessness must involve futuristic technology we can barely dream of. And the actual sending of an email results in a gobbledegook 9502 error (or whatever - I didn’t write it down for posterity). And forget Gmail or Yahoo-style gigabytes of storage. Expect “out of room” errors after you’ve got 50 weeny messages in your