rod mclaughlin

Thoughts on User Interfaces

Sat, January 27, 2007

January, 2007. (This was originally written in 1998, then updated in 2000)

Since the invention of the modern computer interface at Xerox Parc, Palo Alto, it has evolved into a mess of windows, buttons, toolbars, hyperlinks and other controls. Existing interfaces have to be downward-compatible, so their developers tend to "add things on". Attempts to introduce standards have failed [1].

Windows 3.x had two hierarchies with different structures and arbitrary relationships between them: the File Manager and the Program Manager. The solution to this complexity? A third hierarchy, with another structure, and arbitrary relationships to the first two: the Registry.
The following masterpiece summarizes what a good idea the Windows Registry is better than I could:
"Using Registry Editor incorrectly can cause serious, systemwide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk... however... there are settings that can be changed only by using Registry Editor"
- NT Internet Guide, page 9, NT Server Resource Kit, Microsoft Press, 1996.

The concept of "User View" (what users think is happening), has not been remembered. The information given to users is an arbitrary mixture of the user view and the implementation view (what developers think is happening). For example, Tandy Trower explains the difference between "Close" and "Exit" as follows: "Exit implies quitting a process. Close means removing a window.". "Quitting a process" is an implementation detail. "Removing a window" is an application event. Users don't know the difference.

In which Windows menu do you expect to find "Find"? What is the difference between "Options", "Properties", "Preferences" and "Customize"? What does the "Close" button do?
There is no consistent answer to these questions. Consistency is essential to learning. The result is that most computer users barely know how to use their computers.
If cars were computers, users would be dead, and programmers would be in prison.
The proposed new wave of computers, consisting of Network Computers, or "Thin Clients" for business users, and "Information Appliances" for home users, provides user interface designers with a chance to start from scratch.
The foremost principle behind the new interfaces [2] is ease of use. A related principle is never asking users something they don't need to answer [4], nor telling users something they don't need to know [5].

Most of what I have to say about user interface is negative:
No applications.
Components are loaded as needed when necessary. For example, instead of having Notepad, Wordpad, Word and Excel, you would have a simple text editing class, which loads further text or numerical classes when needed, When the user chooses "Bold", the text formatting class will be loaded. When he sums a column, one of the spreadsheet classes will be loaded. Running Excel to add a few numbers is ridiculous. Since applications use each others' components, why not get rid of applications altogether, and just use components?
No menus. For the case against menus, see [3].
Icons and Lists : 1 click to select, 2nd click opens the document.
Buttons : 1 click.
Hyperlinks : 1 click.
No overlapping windows.
No Exit, Minimize or Save.
No difference between the title of a document and what the user sees in order to open it.
Instead of a file system, a database application which stores documents with versions and differences.
Java-style interfaces to enforce compliance on applications.

Whether you are looking at a local file, a file on the network, or somewhere on the World Wide Web, you should have a unified interface to do it with. Microsoft's effort to integrate Internet Explorer with Windows Explorer is an attempt to address this requirement.

Users don't need to know the names of applications. They know they need to write a letter, buy a book, or add some numbers. The computer's front end should load components as needed, silently, enabling the users to do what they want.

On my Windows NT desktop at work, I have "My Computer" and "Network Neighborhood". My Computer includes other computers: some of the ones which appear in Network Neighborhood.

The objects which appear in My Computer and Network Neighborhood also appear in the Windows Explorer. Some of them have three names, eg. "c$ on 'sf-user-5' (E:)".
There are at least two types of Explorer. One is where you double-click on My Computer, and see a bunch of icons. When you double-click on one of the icons, you get another window with more icons. The other type of Explorer has a tree on the left, and a pane on the right. When you click once on a node in the tree, you see its contents in the pane. Windows 98 introduced hyperlinks as well as double-clicks and node-choosing to its navigation. No-one can say Microsoft don't offer you a choice.

Many Windows users ended up with one huge menu bar hanging off Start...Programs, so Microsoft introduced an arrow at the bottom of the menu. If your program was not in the first 40 or so items, you would click the arrow, and see the next 40, and so on. Windows 2000 addressed this problem by keeping only the most-used menu items visible by default, and showing the others when you click on the double-arrow at the bottom of the menu bar, with a tooltip which says "Where are my Programs?".

This is not just an anti-Microsoft tirade. Macintosh and all varieties of Unix have similar issures.

It doesn't have to be like this. This is my attempt to present an integrated user interface, as a modest step towards world domination. I call it "Lookout".

A Tree View of the data users deal with is a powerful and useful model, as long as it's only one Tree View. Users don't need a Program Manager, a File Manager, and a Registry [1].

On the left hand side of the user interface is a Tree View, divided into This Computer, Network, and Internet. Each of these branches has further branches as appropriate. To the right of the Tree View is a small browser pane for displaying a simplified view of the contents of a node clicked on in the Tree View.

Windows Explorer displays directories in the Tree View, and the contents of directories (files and subdirectories) in the right hand pane. Lookout also displays files in the Tree View. If you click on a directory in the Tree View, you see its contents (files and subdirectories) in the right hand pane. If you click on a file in the Tree View, you see its contents (words, pictures, ...) in the right hand pane.

This leads us to the major differences between Lookout and legacy interfaces.

Below the Tree View and the browser area is a larger browser. If you click on a file in the Tree View, you see some indication of what's in it in the small, right hand browser pane. If you want to see, and if permitted, edit, the file, you click in the small browser pane and the whole document appears in the large browser window.

In Windows Explorer, if you double click on a file, Windows launches an application. After reading an advertisement for a few minutes, you see what you want to see in another window. In Lookout, the document appears in front of you, instantly. Meanwhile, the code needed to edit it is loaded silently in the background. It does not assume you need to load 90MB of code to write to your mother, or download another 90MB to balance your bank account.

The range of document types will be handled by plug in components. If Lookout doesn't have the plug in for a particular document type, it displays the displayable bytes as ASCII characters. The only documents it understands without additional plug ins are HTML documents up to version 3.2, and text files.

Third parties will be able to produce plug ins to view and edit each document type. These components will have to load smoothly in a fashion analogous to the way Netscape Navigator loads an HTML page: first, a rough picture, then more and more details. If editing is permitted, the user must be able to start editing the document immediately, before the document is fully displayed.

FTP, HTTP, the local area network protocols, and the local file system, are all simplified into one unified Tree View of the "world" the user wants, or needs, to see. The example I have given divides this world into This Computer, Network, and Internet. Different divisions can be allocated by different companies for different users. The Tree View does not have to reflect a file system. It can be the representation of a database, or any user view needed.

2000: Somehow, I missed Alan Cooper's About Face, published by IDG in 1995. Most of what I say about user interface on this site has already been said by Alan, the creator of Visual Basic, the most successful programming environment ever. He is nevertheless extremely critical of Windows. However, I think one can go further. For example, discussing drag-n-drop, he says:

Fundamentally, you can drag-and-drop something from one place to another inside your program, or you can drag-and-drop something from inside your program into some other program (p 249).

Even this great user interface designer allows application details to intrude into rules for user interface design. Users shouldn't need to know whether they are dragging from one program to another or not. They don't anyway. If you drag from one Excel spreadsheet to another in the same Excel application, is that different from dragging between spreadsheets in different instances of Excel? Few users would know, and certainly shouldn't need to know. Whether to run one or two copies of the Excel program is for the operating system to decide, not the user. If you drag from Word to Excel, is that two programs, or two subprograms within the Office program? Who cares?

1. "The Top 10 Windows 95 User Interface Design Errors", Tandy Tower, Microsoft Developer Network News, Sept/Oct 1995.
2. "Goodbye GUI, Hello NUI", Tom R Halfhill, Byte, July 1997.
3. "Designing the HotJava Views User Environment for a Network Computer", Don Gentner, Frank Ludolph and Chris Ryan, White Paper, Sun Microsystems, March 1997.
See also The Anti-Mac Interface, Don Gentner and Jakob Nielsen, ACM, August 1996.
4. Asking users if they want to save what they've just done is a very widespread example of an implementation detail intruding into the user view. It means "Do you want to copy what you have just entered from memory to a disk?". As far as most users are concerned, when you've entered something, it's there. It doesn't need to be saved. If they don't want it, they'll delete it. Saving information is the business of the computer, not the user.
5. "Starting Word as your e-mail editor".
Portland London