Cutting the Cake the Wrong Way

Summary: The Presentation Manager, X Windows and other GUIs have cut applications in half the wrong way, making it impossible to seriously try new ways of working without giving up all the programs we like. Chris Wenham explains what the mistake was, and how to fix it.

For the past 20 years, WIMP (Windows, Icons, Menus and Pointers) has been the dominant user interface ever since the mouse became ubiquitous and Super VGA got cheap. If only you knew how awful WIMP really is. Ingenious for its time, WIMP should have been a teaching experiment rather than a production philosophy, now we're still paying for it in under realized power and crippled productivity (how often do you futz with something as trivial as a window size or position?). WIMP has gotta go, but the job of replacing it has been made impossibly difficult because of the way programs and GUIs have been written. The big stupid mistake was in creating a large, complex, but essentially dumb terminal called the "Windowing environment" that forced application developers to still design most of the interface themselves.

In OS/2 you use a windowing environment called Presentation Manager (or 'PM' for short) that's bonded with the application in that both must be running on the same machine. Also available in OS/2, but more prominently in Unix is X Windows; essentially the same but which took the "dumb terminal" idea even more seriously - the application doesn't need to be running on the same computer as the GUI. In both cases, Presentation Manager and X Windows aren't much different from the VT220 terminal you use to login to a mainframe or remote computer. All that either do is interpret instructions that explicitly tell them where to put this piece of text, where to put that button, where to put this menu, and so-on. The GUIs can simply display prettier windows and fancier controls than a VT220 terminal can.

This "dumb terminal" design philosophy cuts programs in half the wrong way. First it assumes that the interface can be entirely separate from the program, but that's wrong. Take a word processor for example. It's almost entirely interface, merely providing a convenient way of arranging characters in a linear stream. Bold and italics are part of the presentation, so all the word processor's "guts" have to do is put an invisible marker in the document that says "emphasis starts here and ends there". Is that the way it really works? No, the GUI is endlessly sending messages to the word processor to say "the user just pressed C, the user just pressed H, the user just pressed R" and so-on. The word processor in turn is endlessly sending more messages back that instruct the GUI to "draw the letter C at this pixel location in heavy type, draw the letter H at this pixel location in heavy type, draw the letter R at this pixel location in heavy type". If the word processor and the GUI were separated by a network, as it can be with X Windows and a number of "remote control" programs, then the network will get flooded with useless traffic.

Are you beginning to see how brain-dead this arrangement is?

But there's more. Since the GUI is quite stupid, the program has to explicitly describe how the presentation is supposed to look. The programmer (and the network) has to concern herself with instructions to "put a button at this pixel location and insert the word 'OK' in it, put a button at this location and insert the word 'Cancel' in it". If this arrangement isn't aesthetically pleasing or especially ergonomic to the user -- that's tough. Some programs try to make their interfaces configurable, but what do you get? You get to add or subtract buttons to a toolbar you still don't like, or you get to move that toolbar to the top or bottom of the screen. Big deal. And the vast majority of programs don't even do that, nor can you be sure that two programs will handle that kind of customization the same way. One wants you to drag tool palettes around with the mouse button (Communicator), another wants you to click on radio buttons in a dialog box (Embellish).

And poor you if the programmer puts in no configuration options and has a lousy sense of ergonomics.

It becomes clear that while the designers of GUIs and windowing systems wanted to separate the program from the presentation, they drew the dividing line too close to the end and gave the programs too much responsibility. They should have made smart GUI terminals, ones that figure out for themselves where all the buttons and menus should go, or if there even need to be any buttons or menus at all. They need to take away the responsibility (and the power) the application programmer has in deciding how the program should look when run. They need to put that power in the hands of the users and interface experts instead.

So now a word processor wouldn't concern itself with individual keystrokes anymore, nor where a file-save button would go or a scroll-bar would sit. It'd supply spell-checking services, document type conversions and print formatting instead.

And while it would also be the job of the word processor to build templates for newsletters and reports based on the user's needs, it would be the job of the GUI to decide how it would let the user define those needs. So if I wanted to control the whole shabang I'd choose a GUI arrangement that let me cut and paste, move blocks of text around, change font sizes and everything. But if I was a lawyer that needed to produce lots of legal documents that are all the same except for the client's name, then my "word processor" could be just a space to type the name and a list box of templates. No need for a window that takes up the whole screen and no need for a toolbar of widgets I won't use. No need even to load a "WYSIWYG" editor into memory at all.

The GUI would decide how to display information like a page of text or a table of numbers based on the nature of the data itself or a suggestion from the application. The application would no longer be the final authority.

I could at last decide that I don't need title-bars or free-floating windows anymore, getting rid of them by dividing up my screen into frames where I can dock a spreadsheet at the top, a list of incoming e-mail in the middle, the conversation view of a chat client at the bottom, and a list of news headlines to the side. The spreadsheet would look like a spreadsheet because the application sent the GUI a table of numbers, not because the application itself was meticulously drawing a grid of cells. It might be 1-2-3 under there, now only doing the job of crunching numbers. The list of incoming e-mail will include the first paragraph of the message just under the subject and sender, the way I'd like it. It'll also have all the messaging features of PMMail, perhaps because it'll actually be PMMail handling the messages. And the list of news headlines will react to a mouse click by printing the body of the article instead of opening a browser. The printed page will be formatted as if Netscape had printed it, perhaps because it was Netscape and I just told it to skip the display part and get down to sending the page to the printer.

All of this goes way beyond Window Managers or "skins" or other primitive means of customizing the user interface. Look at X Windows and you can see it's a mess of experimentation for fancy window managers trying new widgets and ways of arranging icons, but still stupid by design. No window manager can pluck the controls out of Netscape's "Save As" dialog box and put them in place of the main window's toolbar for people who need to frequently save the web pages they visit. Window Managers and utilities like Dialog Enhancer and X-File for OS/2 also fail miserably when it comes to access for the disabled. Screen readers for the blind are hopelessly compromised by the modern GUI, and how about someone that can't operate a pointing device?

The next generation user interfaces could still take the philosophy of separating the program from the presentation, but they could mean it this time. By removing an application developer's ability to control how a program's interface looks and behaves you force him to concentrate on making a reliable program. And by separating the presentation, you open up the opportunity for developers with new ideas to not only create radically different and better user interfaces, but to guarantee they'll work with all programs. Finally, you give the user the power to arrange things that fit to their ergonomic tastes.

Post your ideas about the next generation user interface in our interactive forum. Selected feedback will be posted below.

• HTML+ - Pseu
  • HTML not the end of the Rainbow - Chris Wenham
    • You've got it backwards... - David D'Antonio
      • IS Managers and WSOD - Chris Wenham
• Consider where it all started... - Robert B. Gamble
• Cute idea, but where's the beef? - John Drabik
• What you are describing WAS OpenDoc. - Bill Olson
  • Too Bad - rogerc@zianet.com
• New is Old is New is ... - Lawrence R. Hooten
• Use OSS - It is a proven method - Terry Boldt
• Great Idea, Can you get anyone interested? - bnc@altavista.net
  • Actually... - Chris Adams
• Is the idea doable? - Gili
• Sounds like Oberon - J Christopher Kennedy
• Try IBM dialect of XML called PDML (Panel Definition Markup Language) - Russell
• another slick IBM GUI - unknown