Telirati Newsletter #32

Many people have forgotten the Microsoft Cordless Phone. Some, especially those invovled in developing the product, may still be in therapy.

Telirati Newsletter #32: It’s only a phone, how hard could it be?

I don’t do product reviews, and this isn’t a product review. So what am I doing writing about the Microsoft Cordless Phone? Yes, if you haven’t yet heard, Microsoft now makes cordless phones. Naturally, the phone connects to your computer, and thereon hangs the lesson in this newsletter. More often than otherwise, software people come to think “It’s only a phone, how hard could it be?” This, usually just before wading into the quagmire of computer telephony never to be seen again. The Microsoft Cordless Phone is less a product than a touchstone. It characterizes Microsoft’s development approach to a deceptively difficult problem. Let’s see how well they did…

First, what do you get? You get a phone with a charger-base, and a separate radio base-station. This radio base-station is what plugs into the phone line and into the computer’s serial port. (I thought the phone was going to be a USB device. Maybe they just sent a serial version to maximize compatibility?) Both parts are black with gray rubber antennae. The phone is larger than most cordless phones. The buttons are ovoid and bean-shaped, with the feature buttons arranged in rounded groupings that remind me of the Ford Taurus radio and climate control buttons. The shape of the phone is hand-friendly, much like the Microsoft “Dove Bar” mouse. The charger-base does not wall-mount, which is fine with me since anything with a power-cube plug is hard to satisfactorily wall-mount. Installation is a breeze. The drivers work marvelously, playing and recording clear audio in real time over the serial link. The drivers and phone firmware run diagnostics and keep-alive checks that make sure the phone is in touch with the base station, and you are alerted to any errors with informative messages that make it easy to fix problems. Curiously, this phone, which works very well as an audio device, requires a separate audio device in the PC.

You can voice control the phone. I won’t get into the details of this feature, since doing so would occupy the entire newsletter, but the significant aspect of voice controlling the Microsoft Cordless Phone is that this represents getting voice control right. Voice control is used appropriately because when you are holding the phone, you can’t type. This changes the productivity equation. Voice control is, in this context, not competing against the 100% accurate keyboard and mouse.

Voice control human factors are implemented correctly: There is a voice command button on the side of the phone (right handers have their forefinger on the button, lefties their thumb). You tell the phone when you want to issue a voice command with a button press. You get a start beep, and a confirmation beep (or a less pleased sounding un-confirmation beep). There is no mistaking what is a voice command and what isn’t. Since the button is positioned under where your finger rests, there is no hand movement, or anything else that takes you away from your task, associated with issuing a voice command. The feedback is audible, so you never have to look at anything to see if the command was correctly interpreted. And, since the command is spoken into a telephone handset, and all the results are audible through the handset, voice control is not any more intrusive to the people around you than normal phone use.

Microsoft’s hardware division is a curiosity: It is non-strategic. It is a relatively low-margin business (compared to software, any hardware is low-margin). And it makes very nice products. I am typing this on a Microsoft “earth shoes” keyboard and am mousing with a Microsoft mouse. Nice stuff. Always high touch. The phone is no exception. Microsoft must have spent a bundle developing it, and it shows.

Well, it shows in the industrial design, in the product formulation, in the quality of the device drivers, and in the attention that went into conceiving a really useful and usable application of voice control. But what about the application software that comes with the phone? Here things were less well executed: The phone comes with a dialer/answering machine program that doesn’t merit long discussion because it is no better than any above-average prior attempt. The flaws come in with poor integration into existing messaging client environments, in which contact data is shared, but messages end up in their own separate message store and must be accessed through their own UI. A hole in the head, or another place to put messages – which is needed least? Capping the mediocrity of the dialer/answering machine is the UI itself, which is a “consumer-look” UI that, while I have no fundamental objections to friendlier-looking UIs, fails to justify its differences. Indeed it points up the gratuitous-ness by implementing the typical tree view of multiple mailboxes, only with bigger and clunkier graphics than the usual Windows look.

To be fair, designing a multi-user messaging system for Windows PCs is not child’s play. You have to make such a system a true-store-and-forward system in order to integrate properly with messaging clients and Windows’ multi user capabilities and security. A lot of work. But, in addition to illustrating how hard it is to manage design quality across the large spectrum of technologies that go into making a computer-connected phone, the failure of the application software to measure up to the quality level of the rest of the product shows a general disconnection between an otherwise brilliant hardware division at Microsoft and the kind of technology inter-locking that makes Microsoft software hang together so well.

There are three key areas where opportunities went unexploited, either to the immediate detriment of the product, or resulting in missed chances to reinforce Microsoft software technology initiatives: a) Messaging architecture: The messaging software could have shown the way in applying Internet and Windows messaging standards and capabilities. Instead, it settles for using a little of it and mucking up some of it. b) Audio: A telephone handset represents a unique opportunity to create a business audio tool. It enables audio to be used in a cubicle setting without disturbing co-workers. It provides a microphone that won’t get misplaced when most PCs do not have one connected. And the human factors issues of muting other audio while the phone is in use for calls could also have been handled. Perhaps with the USB version. c) It is remarkable that this phone is not well integrated into NetMeeting. For the same reasons that a phone is the right audio device in an office setting, it is also just what is needed for NetMeeting.

It’s only a phone. And this is how hard it can be to get right. With what is probably ten times the money of any other computer connected phone in the development budget, and a result that is head-and-shoulders above anything that came before, there is still plenty to do for rev. 2. While that sounds like a lot of work just to do a good job with a hardware peripheral that probably will not do nearly as well this Christmas shopping season as the Microsoft “Arthur the Aardvark” dolls (I’m not kidding!) there are, in fact, profound, strategic, and highly lucrative opportunities for getting audio, telephony, and the link to conferencing tools like NetMeeting right.

Microsoft has a history of getting it right by continuing to try. The Microsoft Cordless Phone is definitely not “Bob,” and deserves a continued high level of investment. The future of computer telephony could be getting a lot more interesting.


Copyright 1998 Zigurd Mednieks.

Comments

Popular Posts

5G: Hype vs Reality

A $99 Android Tablet That Doesn't Suck

The QUIC Brown Fox Jumped Over the Top of Carrier Messaging, or Allo, Duo, WebRTC, QUIC, Jibe, and RCS, Explained