a dose of satire.
With our phone system, the lack of an actual Transfer button supposedly makes the task easier. You “just” dial the person’s extension number, wait until they answer, then put the phone down. Nothing easier! (explains the exasperated receptionist to a red-faced programmer). But it’s that bit about putting the phone down. How do you know for sure that the call will be transferred? So far, nothing on the phone’s little LCD has suggested that that’s what will happen. Usually, when you put the receiver down, you hang up: terminate the call, cut the line dead. Who’s to say that this time will be any different? The user must make a serious leap of faith and just go for it, slam the phone down, trust the system to transfer the call successfully, knowing that if he’s got it wrong then there will be no going back.
The receiver’s inconsistent behaviour is, of course, that dreaded of all UI antipatterns, a “mode”.
In the HCI world, an interface is modal if the same action does different things depending what state some other part of the UI is in. It’s highly confusing, depressingly common, and generally frowned upon. Like this. (I’m frowning right now).
But you can understand why a phone, with its limited set of hardware buttons, would have to be modal in order to pack in all of its super-powerful functions. Notwithstanding that the majority of users only really need a tiny subset of those functions: making a call, ending a call, checking their voicemail, recording a new “Hi this is Bob from accounts, leave your complaint after the beep” voicemail message, transferring a call, putting the call on hold. Each of those functions could quite easily have its own button.
All those other, highly esoteric functions (if they really must be available at all) can be virtual. “Ans.Rel.”, “Group”, “Program” etc. It doesn’t matter if they’re hidden away in a mode, they would never be used anyway.
So until computer geeks learn to re-adapt to the physical world around them, we can only hope that device manufacturers learn some lessons from software UI design, eliminate modes, and make their devices more forgiving, and more… well, obvious.
What’s more likely to happen is that phones and other devices will become more like computers. They’ll consist primarily of a big VGA touchscreen and a receiver, and naturally the phone will be Linux-based. It’s already happening, of course. So techies can rejoice: the mountain has come to them.
Instead of the user creating their own cognitive model of the phone’s internal state, the model is shown on the screen for them: “7 callers on hold: Switch to Caller 1, Switch to Caller 2, ... Show callers in chronological order”, that sort of thing.
But, ironically perhaps, non-techie users will, I’m sure, soon be seen fumbling with these “PCs in disguise”, cursing the logical, dynamic interface with its disappearing virtual buttons, drop-down lists and so forth. The poor receptionist is being airlifted into a foreign land where her amazing ability to construct in her mind these virtual holograms (“mindgrams”?) of the phone’s highly complex internal state, is no longer needed. Instead the evil PC-device has taken over this job for her. It must be like watching the movie of the book, and discovering that the sets and the lead characters look completely different to how you’d imagined them. (As for VoIP applications, don’t even go there!)
I’m not suggesting for a moment that receptionists will be the next victim of the technological revolution, thrown onto the scrapheap of obsolescence along with cobblers, petrol pump attendants and philosophers. My God, we still need receptionists and will do for a very long time. Nothing kills programmer productivity quite like a ringing telephone.
But, for a while at least, the receptionists’ lives are going to be made harder, not easier, by the “advanced” new PC-phones. You'd expect there to be an adjustment period after which they learn to teach this new, friendlier device to sing, but there's more to it.
However more obvious to use (aka “intuitive”) the phones may be, they’ll only slow down an advanced user. It takes longer to fiddle with a bunch of drop-down menus, spin-buttons and so forth than with nice chunky physical buttons (as long as you’re familiar with them); Fitts’ Law governs UI design like gravity governs aeroplane design. In fact, it’s more like Fitts’ Law cubed, because to operate a “soft” UI the user must cross mediums, from the physical to the virtual; “step into” the screen with their fingertips. (I would also mention GOMS here if it didn't sound like somebody clearing their throat).
Similarly, creating the model of the phone’s state on behalf of the user – and showing that model on the screen – makes the phone more usable for the casual user who rarely uses the phone except to answer an incoming call from his boss.
But the ostensibly "user-friendly" UI is also less efficient for experienced users because it creates more “stuff” that they must deal with and navigate through. Experienced users find “helpful” UIs frustrating because to achieve a task they must press maybe 5 buttons instead of just one. Most likely they’ll still map the PC phone’s “helpful” state-model onto their own cognitive model anyway.
What it boils down to is this: Different types of users need different interfaces, because we want to get different things out of the device we’re using. Our goals are different; our experience with the product is different; our level of patience with the device is hugely different.
Hopefully sometime soon, phone designers will figure this out and target different phone UIs for different breeds of people: simple, obvious, hand-holding EezeeFones for us poor fumbling technogeeks who use the desktop phone maybe once a week, and even then only grudgingly; and scary-looking, ultra-efficient, modal (if need be) Rubik’s Cube devices for the super-users for whom it’s their main tool used every minute of the day.
Other UI Design Articles by Matt Stephens
All trademarks and copyrights on this page are owned by their respective owners.