Why can’t I get in contact with people by telephone sometimes (often)? It’s simple. My telephone only offers me a 50/50 chance, or less, of making contact. If I dial your number, I have no idea if you’re available or not.

Why do we still have this problem? After all, we live in an age of mass computing. Moreover, there’s more computing power in my phone than yesterday’s laptop. And, isn’t it a problem that everyone has? Telephone tag. You’d think that we’d have solved this by now, wouldn’t you?

It’s possibly to do with frames of thinking. In telephony, we talk about circuits and circuit-switched calls, which is how most mobile calls still work. Therefore, to complete a call, you ‘need’ to complete a circuit. In fact, in the old days you’d need an operator to do this and they’re still pretending that they’re there, which is why roaming calls are artificially expensive.

Are we really interested in a completing-a-circuit experience? No. Only communications engineers care about such things. We’re mostly interested in having a communication experience. A conversation, no less. An exchange of ideas, requests, views and so on.

If we were designing a complete-the-conversation experience, we might think differently. We would think about all the ways that two (or more) people could connect and exchange whatever they need to exchange that day in a timely fashion.

The issue is primarily one of scheduling and availability. For two people to attempt a connection and have a high probability of success, then they need to agree when it’s going to take place. We all know this, yet why isn’t it a feature of our phones? Isn’t this an essential and integral part of making a call? Not in the telecoms mindset, no. Any state diagram showing a call being made begins with placing the call, it never begins with scheduling the call. This, it seems, isn’t important. It’s somebody else’s problem.

There are lots, possibly hundreds, of oversights like this when we critically analyse telephony services with a view to how well they support real human interactivity rather than meeting functional technological goals, such as completing a circuit.

This relates to my previous post about ecosystems and user experience. Thinking in terms of two people making contact is all about the user experience. Thinking in terms of closing circuits isn’t. Creating a solution that meets the experiential needs of the user in a holistic fashion is mostly about creating an ecosystem, not a point solution. For example, we would need a calendaring system to support call scheduling. It is remarkable that we still don’t have shared and group calendaring on our mobiles, especially considering that we all have them and we all have diaries, whether computerised, on paper or in our heads! (In fact, it probably doesn’t pay to think in terms of diaries, but that’s another story.)

We could brainstorm how best to facilitate scheduling and you might be surprised by the range of solutions. Why don’t you have a go.

What’s going on here? There is no simple answer, but a lot of it has to do with framing - how we think about things. This doesn’t just apply to technology. Almost everything we do has a historical basis. This becomes forgotten and we carry on with the solution without question. You might call it design-by-tradition.

This isn’t always the case. Sometimes we think that we understand the problem and we come up with a solution that fits with our preferred understanding. Later on, or even from the outset, that understanding might prove to be inappropriate, yet we stick with it because we ‘believe’ in it, perhaps for good reason. You might call it design-by-dogma.

It seems to me that IP Telephony is design-by-tradition. Apart from the cost savings, it is an almost useless facsimile of the whole circuit-switched experience. There is a vague attempt to solve the scheduling problem, using presence or chat, but this just pushes the problem into an out-of-band channel. These are not scheduling tools. They are not part of a holistic solution to having a remote conversation. They are just other traditional tools bundled in with the package.

On the iPhone, most people I talk with agree that it is a great device. Most of us who have one tend to admire it. I love mine. Overall, the experience is impressive. However, the texting part is incredibly poor, surprisingly so. In fact, it is so bad that I am left wondering what on earth they were thinking. For example, why leave out the ability to forward a message? This is like ‘messaging 101′ or ‘designing a messaging system for dummies’ kind of stuff.

It would seem that this is design-by-dogma. The iPhone’s texting interface is an attempt to copy the iChat interface - they are identical visually. Yet, they are NOT the same. Texting is asynchronous (’fire and forget’) and not exclusively a chatting tool. Anyone who’s read a basic book about texting habits knows that forwarding texts is a huge amount of texting traffic. Yet, this doesn’t fit with the iChat frame of thinking.

And then, only this week, I discover yet another problem with texting on the iPhone - it isn’t ‘fire and forget.’ Without coverage, it simply tells the user ‘error sending message,’ or some unhelpful equivalent. It doesn’t pop the message into an ‘outgoing’ box and attempt to send it later when coverage resumes.

Again, this is design-by-dogma. If you’re having a real-time chat, then you probably don’t want your message stuck in an outbox and sent some arbitrary time later - it wouldn’t mesh with the chat experience.

Where’s cut-and-paste on the iPhone? More dogma. It doesn’t quite fit with the multi-touch paradigm, so they simply leave it out, against all sense I would say. It’s like designing a car that does 100 mpg and then leaving out seats because they didn’t fit with the design goal, which was 100 mpg, not ‘getting me comfortably and safely from A to B within 100 mpg.’

Apple seem to be the masters of thinking about user experience, but this shows that even they can get it wrong, such is the power of sticking to a particular frame of thought.

[This blog has moved to here]