08.13.02
GUI, Considered … Something
2002, August 13th
I would like to expound upon a theory that I have held for some time that, conceptually, GUIs can lead to poor management practices.
First, let me discuss the alternatives to graphical user interfaces (GUIs.) Since GUIs were designed to replace command line interfaces (CLIs) and there was really nothing before the CLI and nothing new since the GUI, the only alternative is the CLI. Well, OK, there is the menu driven interface that was the shadow between CLI and GUI, but the concept of a menu driven interface is more similar to GUI than CLI, so I’ll just lump it in.
A CLI is a model for interacting with a computer system based upon command/response pairs. An example command might be “dir bob” which could mean, “Computer, I would like a listing of the directory ‘bob’.” The computer would probably respond with a list of things which could be found in ‘bob’ assuming that this is a command that the computer in question understood. Keep in mind that the CLI was invented in the infancy of the computing science and there are quite a few different ones to choose from.
In the early days of computing, we wasted a lot of paper. Some would argue that we still do, but in this case I am refering to the printing console. It may seem archaic in the modern era of the monitor console, but we used to go through boxes of graybar paper every month by using paper to hold every command/response pair. This was horribly wasteful because, in general, a computer user only needed to see the response for a few minutes or even seconds. Still, the mechanism created a permanent record.
For a single user computer, like the early IBM PC, the computer spent most of its time waiting for the user to tell it what to do next. So, if a user ran the “dir bob” command, and never touched the bob directory again, the response would be valid forever. With multi-user systems, this is not true and users have become familiar with this concept. A good example is a command that outputs the current time. Since the computer doesn’t distinguish between a printing terminal and a monitor terminal for normal commands, the time does not update on the screen, just like it would not update on the paper. Users are familiar with the idea that the information output by the computer is out of date the instant after it is displayed.
By the early 1980s higher end systems had terminals with screens, but the command line metaphor of the screen as a piece of paper still held true for basic interaction with the computer. Certainly there were word processors and other applications that were more interactive, but once you exited the word processor, you were back to the command/response behavior. The CRT terminal was so successful that when IBM came out with their PC, even though it could work with a terminal, IBM built in the keyboard and the ability to interact directly with the monitor rather than requiring a seperate terminal device.
Enter the GUI.
The original GUI was developed by Xerox at the Palo Alto Research Center, Xerox PARC. The original design called for a WYSIWYG (what you see is what you get) word processor. After a while, the development team decided to use this “Desktop Metaphor” to interact with the computer at every level. So, instead of creating directories with files, you would create file cabinets with files. Each of these objects had a little picture that represented it on a graphical screen. Just as you can close a file cabinet or drawer and not see all of the folders in it, you can close the little picture of the file cabinet, hiding its files. This proved to be a wildly successful method of making the computer concepts accessable to non-computer savy individuals.
Because the lab at Xerox PARC was designing a system from the ground up with a GUI interaction in mind, their GUI had hooks into the behavior of objects. This meant that, if the state of an object changed, its little picture on the screen could track that change. For instance, if one user deleted a file from a particular cabinet and another user had that cabinet displayed on their desktop, the picture representing that file in that cabinet disappeared.
Unfortunately, this behavior is not pervasive while the expectation of this behavior is. Many software developers, recognizing the success of the GUI developed GUIs for their systems that would run the command line equivalents and display the results graphically. This sounds like a good idea. It is frequently not a good idea. The reason it is not a good idea is that the GUI and the real state of things can get out of sync.
An example: Suppose that you manufacture a large disk array and that the management software was written using a command line. Now you want to create a GUI “wrapper” so your customers will like you. So you do, but you don’t change the command line, you just run the commands and display the results graphically. So, two users have the GUI open and one allocates a bunch of disks in the array, but the second one doesn’t know about it. When the second user comes back, he still sees the allocation of disks when he started his copy of the management GUI. So, he selects several disks and allocates them. Unfortunately, he selects some of the same disks user 1 already allocated. If the command line isn’t designed well enough to realize that this is a mistake, it may very well allow this behavior and destroy user 1’s data. Oops.
OK, so you fix this by either having the software poll the array periodically or you update the GUI before allowing any actions. Polling is slow, and frequently costly of system resources. In any case, it doesn’t solve the problem; you can still be out of sync, just less frequently. So, you go with option 2 and force an update of the GUI state before any action takes place. You still have the problem that user 1 can update and start and action and before it finishes user 2 updates and starts an action and they collide.
The only solution that makes sense is one where the GUI interacts with the managed system and constantly updates the screen with correct information. If the user of the GUI selects an object, then the fact of that selection must be reflected instantly in all other copies of the GUI. Any other behavior leads to chaos.