GUIs are a bad thing, and this applies on many levels. As I write this opinion piece I need two hands on the keyboard to touch type and a third hand on the mouse to navigate through the document. Problem is I only have two hands! The move to and fro between keyboard and mouse is a real hassle. No better system has really emerged, even though WIMP (Windows, icons, and mouse pointer) has been popular for over twenty years. The trackpoint does solve some problems but this is not ideal either.
Of course, this is not the only issue. Another grudge I have, still from a user point of view, is this whole desktop metaphor. Don't get me wrong, I am all in favour of metaphors. Recently reading Metaphors we live by (Lakoff and Johnson, ISBN 0-226-46801-1) was a real eye opener. But the desktop metaphor as used in GUIs doesn't work very well at all. It has too many mismatches with real desktops. I can, and I do, have my desk in a real clutter, but I can nearly always find any paper in just a few seconds. I can't say the same thing about finding a document on my computer. And no, I definitely do not leave my wastebasket on top of my desk.
One amusing point is that it seems that Doug Englebart, the inventor of both mice and GUIs, is also dissatisfied with their current use. When he invented the mouse, he devised at the same time a one-hand operated chording device: one hand on the mouse and the other on the chording device. More natural for us two handed humans. (You could always use your feet; a Ctrl-Alt-Del foot pedal was recently advertised on the Web!) On Englebart's appreciation of today's GUIs, here's a quote taken from Technology Review: 'Here's the language they're proposing: you point to something and grunt.'
Diabolical as they are, graphical interfaces do make controlling a computer easier (and prettier) than from the command line, but so far this has happened with some power taken away from users. For anything a bit complex, grunting a double-click just won't do. The next best thing is going through screens of parameters/configurations in what are usually called preferences or options. To help in this maze of tick boxes, there are the ever helpful ToolTips and contextual help, except that more than half the time they're not fully implemented or out of date; and the help system is just slow enough to dissuade you from using it in the first place.
Back some fifteen years or so, a friend working in a training company explained to me how easier it was training people to use DOS than the Mac. In one case they had recipes to type for each goal they were trying to achieve. True, they didn't always understand the deeper meaning of the incantations they were typing but it did work. On the Mac, the users had to understand the full desktop metaphor and then all its flaws before they were able to do the simplest operation. In other words, the learning curve was steeper for GUIs. How counter-intuitive.
Yet, I haven't touched on my main beef. In the good ol' days of Unix, most command outputs could be used as the input of other commands, and there was a cracking good shell. Okay, this is still available today in GNU/Linux and all other Unixes, but it is mostly lacking in the standard Windows platform (you can always add so many add-ons to give it a Unix feel).
Extending the power of simple commands by combining them together is something that Unix users (including many developers and most system administrators) miss terribly when moving to a GUI environment. With the relatively simple concepts of pipes and filters, Unix has achieved a consistent framework to extend even the most basic command. Instead of having to include everything possible in one application, just in case someone might need a specific feature, developers can focus on one task at a time knowing that users will be able to combine their programs with any other present on the system. The power is in the (two) hands of the users.
Enter the world of the regular expression, the back quote, and the pipe character. All this potential power is fantastic but not everyone dares unleash it. Even if simple conceptually, it is a rather complex and unforgiving world. Make a typo in your .procmailrc and all your mail might go ashtray. Dumbing down the interface does offer protection against many errors and safety for the fools.
Xerox was where the first computer with a graphical user interface was invented. For the past thirty years we've essentially been using the same technology. Some say the Alto was even better as a computer than today's offerings (within the limitations of the time). The pipe and filter metaphors have continued their own life in a quite separate way. Either you get a CLI system, and get the power and accept being bitten sometimes, or go for a GUI and accept its many limitations.
Except that it doesn't have to be this way. Graphical interface designers and system programmers should work together to make the best of both worlds. One possible scheme would be to have a core system based on the pipe and filter metaphors with most if not all programs written to take advantage of them, and on top of it a GUI with a real visual development system where you could draw lines from the output of a program to the input of another and annotate the links with some constructions describing any kind of regexp. Pre- and post-conditions perhaps. This should work in such a way that these two representations are functionally equivalent. One could use either one or go from one to the other and back. That would be a better way to edit programs... and documents. But that's enough about this suggestion; I should let others offer even better schemes...
David Mery
(C)2000, Centaur Communications Ltd. Reproduced with the kind permission of EXE Magazine.
Bootnote: This soapflake acrostically announced the end of my editorship of EXE after nearly five years.