Microsoft's text-like interfaces
February 16, 2010 at 9:34 PM by Dr. Drang
Following a link from Daring Fireball, I read this article by Luke Wroblewski comparing the user interfaces of the iPhone and the new Microsoft Windows Phone 7 Series [sic]. The gist of the article is that the iPhone’s information-dense interface makes the user experience more efficient than that of the MWP7S. I agree with Wroblewski’s comparison, but I think he has the cause/effect relationship backward. The inefficiencies of the MWP7S interface aren’t due to the low density of information MS puts on the screen; rather, the screen is information-sparse because Microsoft has an institutional preference for layered, multi-step, inefficient interfaces. This preference goes back to the DOS days of character-based displays.
Back then, the menu of “user friendly” programs typically consisted of a strip of words running across the bottom of the screen. You’d choose one of these words through a set of keystrokes. If you were lucky, choosing that word would actually execute a command. More commonly, it would lead to a new set of words at the bottom of the screen and you’d choose one of them to execute the command. (If you were unlucky, this second choice wouldn’t execute a command, but would lead to yet another set of choices.) This layered approach wasn’t exclusive to Microsoft, it was a pretty common way of writing menu-based programs.
The Macintosh was a huge departure. Considered in the abstract, it didn’t seem like it should be. After all, its menubar was just a strip of words running across the top of the screen, and you had to choose commands from the individual menus. But somehow in practice, this didn’t seem like a two-step process. After a few minutes, you didn’t think “I’m going to click on the File menu, then drag down to the Save As… item,” you thought “I’m going to choose Save As… from the File menu.” The click and drag on the menu became a single step in your mind and in your hand.
The early versions of Word and Excel for the Mac worked like other Mac programs, with almost all the commands in the menus, but as Microsoft further developed Windows itself and the Windows versions of Word and Excel, the Mac versions began to take on the characteristics of their Windows cousins. More menu choices led to dialog boxes instead of actions. Buttons within dialog boxes led to other dialog boxes. It was the multi-layered, text-based interface all over again, just tarted up with a GUI. By the late 80s or early 90s, two clever Mac programs had been converted into clumsy oafs.
And the conversion was Microsoft’s choice. They’d already written programs that were Mac-like, and they could have used that experience to make efficient Windows programs. Instead they made awkward Windows programs and backported the awkwardness to the Mac side.1
That great advance in user friendliness, the Windows wizard, is another example of Microsoft using what is essentially a text-based interface in a graphical environment. At heart, a wizard is a series of multiple choice questions, something every beginning programmer learns to accomplish with write and read statements. The wizard just puts these questions in a dialog box with a (sometimes animated!) picture next to them.
Obviously, Microsoft has hundreds, if not thousands, of really smart programmers and designers on staff. I can’t believe that such talented people would make such poor decisions over such a long period of time if it weren’t an institutional requirement.
Update 2/17/10
I forgot to add that Apple is not immune to clumsy, over-layered interfaces. For example, if you manage two or more email accounts on your iPhone, you know how inefficient it is to go from the Inbox of one account to the Inbox of the other: climb two levels up, then two levels down.
-
I’m pretty sure Apple’s “look and feel” lawsuit was under way, but I doubt that’s the reason Microsoft took the clumsy route. “Judge, if we had copied Apple, we wouldn’t have such a shitty interface.” ↩
