![]() Programming with 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.
Message Forum: Please let us know what you think of this article... Message Index:
The Messages: UI Leaps of FaithThis isn't as mysterious as the article makes it sound. Receptionists learn to handle switchboards because they're forced to either learn it or fail at their jobs. Programmers aren't. And a good thing too. Before I was a programmer I was a secretary, and at least half my secretarial career was spent temping. Quite often, I would get no, or a very brief, explanation as to how the phones worked, and there would be no manual. The permanent staff could handle it because they'd been in the same place, using the same phones, for months and years. To them, it amounted to "common sense". I discovered that very similar, and often identical-looking, makes and models of telephone had very different methods of operation. What transfers a call on a Yoyodyne 2000 phone will cut off the caller on a Yoyodyne 2001, even if the user interface looks almost the same. In situations like this, "common sense" won't get you very far. What works is memorizing a series of steps, and consolidating them by repeating them dozens of times a day. When a new phone system is installed, staff whose main job is answering the phone usually do receive training in how to use it. If the user interfaces of telephones are made more transparent, it will only make them easier for everyone to use, not harder. H. The Wrong Side of the Tracks Tue Oct 10 12:41:36 BST 2006 I'm clueless about phones I must admit: I can architect complex applications in various technologies and find elegant solutions to bizarre design problems, but when it comes to phones, I'm lost: I never know how to transfer a call, and when I try to put somebody on hold, I invariably end up hanging up on the person... Now I'm glad I'm not the only one :-) G.C. Atlanta,GA, USA Mon Oct 16 18:48:42 BST 2006 A very good explanation of a real phenomenon While it is true that a receptionist who can't use a phone won't be a receptionist for very long, that is not the whole of the story. Competence does not necessarily breed experthood and the best receptionists I've met do indeed have mastery over their instruments. The "mental state machine" explanation is the best I've ever heard for why that is, and it's something worth studying...see how much you can push on to that mental stack, see how much you can stress the complexity of the various modes before the mind loses track, like in a game of Simon. A similar experthood can be seen in any talented user of emacs -- what I consider to be one of the least visual IDEs still in use among sane individuals. People just fly on the keyboard, and when they make mistakes, go down the wrong path of menus or something, they can quickly correct them. I use eclipse myself, and though I love it for its lovely visual representations of essentially graphic information (such as hierarchy trees and so on), for pure, unadulterated throughput I will never match a man in emacs. dasm das@dasmegabyte.org Albany, NY, USA Tue Oct 24 16:25:43 BST 2006
Other UI Design Articles by Matt Stephens Persona Power
All trademarks and copyrights on this page are owned by their respective owners. |
|||||||||||||||||||||||