The Right, the Easy and the Unusual

By Matthias Warkus

1. Where it all began

It all started out on comp.os.linux.advocacy. One knows the place, one knows the score. c.o.l.a is a noisy group, considered the ultimate waste of time by many; it is the headquarters of reasonable Linux advocacy as well as a place where you can expect zealots of every OS and platform know to man to kick in and deliver lengthy rants, occasional bits of extreme silliness and the usual lot of explicit language. And of course, there is what looks like a well-organised team of trolls trying to make us Linux advocates look like religious fanatics… we have even been compared to terrorists. Oh well. Whoever wants to go to c.o.l.a should be sure to have patience, a flashlight and a score file with them.

As soon as one has gotten over the flame bait, the trolls and the political discussions, as soon as one learns to quietly ignore the violent language many of the more zealous posters cultivate, what becomes most annoying in the advocacy newsgroups are probably the rehashes. What gets most on my personal nerves are the periodical visits of zealots from OS/2 and Macintosh groups, to be more exact, those who want to have their pet user interface pushed into Linux. “What if IBM ported the OS/2 GUI?”, they ask, rhetorically, expecting such a port to suddenly outshine all other OSes and their user interfaces. “If Apple bases OSX on the Linux kernel, they will win!”, they claimed not long ago, not explaining what `winning’ was all about in that case. “I have seen the future: the MacOS GUI had been ported to Linux, and Apple dominated the market, since they made the only user-friendly Linux interface!”, they post with all signs of blissful ignorance.

So this is the point where I decided to make the list of c.o.l.a Frequently Rehashed Topics (alternate site), a/k/a the FRT. This list was greatly inspired by the wonderful crowd of c.o.l.a regulars, and I got a lot of feedback to it. Reviewing the FRT and working the feedback into it, I realised that at the very heart of most debates on the `user-friendliness’ of Linux (or Unix in general, for that matter), there is the belief that interfaces can either be friendly or functional, but not both.

2. `Dumbing down’ and what it actually means

2.1. Definition

Experienced users of different OSes and interfaces to them are usually unanimous in the opinion that the Windows interface, and, to a lesser extent, the interfaces of MacOS and OS/2, as well as the application interfaces usually found on (resp. dictated by the style guides of) these platforms, are dumbed down to make them easier to use. So, what is a dumbed down interface?

Generally, dumbing down means the purposeful obfuscation and hiding of functionality for the sake of a perceived gain in ease of usability, usually on the expense of efficiency.

Sometimes, on a deeper level one can find not only dumbed down interfaces, but dumbed down concepts and philosophies, too. The reason for this kind of `brain damage’ is most often the fear that a piece of software might somehow appear daunting and unattractive, or, even worse, unintuitive to the end user – or, alternatively, the person who makes decisions about which software the end user will have got to use.

2.2. Some examples

I am not a user interface designer. All I have got is common sense. But nevertheless, I tried to think of some widespread examples for brain damage caused by dumbed down interfaces or concepts. Examples include:

• Scriptability, but no command line to directly enter commands in the scripting language
• Formatting mark-up that cannot be displayed explicitly as `tags’ or such
• Front ends to command line tools that do not allow to directly change the command line passed to the tool
• Actions that can be invoked via a tool bar icon, but not via a menu or a key binding
• A search tool that allows multiple search strings and boolean expressions – but only two strings and one expression between them, that is

You have surely noticed the usage of the word `directly’ in the above examples. It is indeed a key word in user interface design. A user interface over existing functionality should always leave a way to access it directly; if it does not, there is the danger of the user being effectively locked away from some of the software’s features.

For an excellent Web site on user interface design, have a look at Isys Information Architects, Inc.. Those people are professionals. If they should tell you that all I wrote is utter nonsense, believe them – stop believing me. 🙂

2.3. Consequences

While dumbed down interfaces may have got the advantage of looking easy and attractive to a beginner, they do not provide means to increase efficiency very far. Automation and shortcuts to existing functionality often simply do not exist, or they are very weak. The first result of this is frustration of the end user.

Due to this frustration, motivation to learn more decreases, and since the dumbed down concepts of the interface and/or application will not have provided any `tourist information’ that would eventually lead to increased knowledge and computer literacy of the end user, supporting these users is an equally frustrating task. This directly leads to the frequent assertion that the end user is simply a moron, a `dummie’, whereas it is in fact the software they are using that frustrates them, de-motivates them, and prevents them from learning.

Perhaps the worst consequence of all this is the arrogance and elitism it fosters with the more computer-literate users of software that is neither dumbed down nor easy to use. They all too often start to believe that dumbing down is the only way of making software friendly, and they will of course oppose user-friendliness. They will start to feel as wizards, who have bought their knowledge and their right to be efficient and productive in the tedious process of learning unfriendly software.

If these `wizards’ have got to develop software which is supposed to be friendly, they will dumb it down, and they will not develop it with their heart and mind, because they feel like it is inferior software for an inferior caste of users. Actually, there is a lot of software in the market which looks like it really has been made by such frustrated wizards.

About the only way to break this vicious circle is to take a new approach towards application design and user interface design. Unlike the `wizards’, I believe with my whole heart and mind that computer interfaces need neither be arcane nor simplistic, and I hope I am not the only one at that.

There are certain de facto standards for modern GUIs, it seems. On some platforms, such as Windows or MacOS, more or less explicit style guides enforce these standards. Of course, this assures that nearly all the interfaces in the market look familiar. But rethinking never hurts, and user interfaces should be rethought at times, like everything else.

Not much has changed in the last ten years of GUI evolution. Interfaces have become prettier, with a `neater’ look to them; sometimes their looks are even themable (consider GTK+ 1.2 or Qt 2.0). Widgets have been polished (e.g. canvases and tree widgets have become real Swiss Army chain saws), and a few new widgets have been invented, such as dials or rollers, but they do not actually implement radically new functionality. The single biggest change, revolutioning the consumption of screen real estate, was probably the mass invasion of tear-off and pin-down elements, together with their friends, context menus. Drag and drop are nothing new, but finally showed up everywhere.

Underneath, implementation paradigms, models and languages may have changed. Yet, a GUI application today is still very much the same as in 1990 or 1985. Rectangular panels with areas to work in, a bar of pull-down menus, one or more tool bars, dialogs with certain ever-recurring widgets – a simple design, and so far, it has worked well. The concepts behind the scenes are very much the same, too: usually, you do your work by creating something in the workspace; to change it, you select some of it with the mouse or the keyboard, and you invoke actions that act upon the selection. Usually, there is a copy buffer or `clipboard’ for selections, too.

3.1. Blue sky: Clipboard feedback

This directly leads to one of my main complaints about today’s GUIs: graphical interfaces are about visualisation, and in some cases, it just does not happen. Perhaps this lack of transparency was excusable in 1985 and 1990, but with the advent of widget sets that are comparably easy to program and extend, object-oriented programming and object models such as CORBA that make code reuse considerably easier, there should not be any excuses anymore in 1999, 2000 or later.

Back to clipboards: the notion of a clipboard indicates that you can keep multiple objects on it and that you can view what is in it. Except for Emacs with its `kill ring’ and its “Edit/Select and Paste” menu (in the case of GNU Emacs, I do not know about XEmacs), I have not yet seen a program that features multiple clipboard buffers and a way to view their contents. It is already useful enough in a text editor – in a system where one handles lots of different objects, such as a DTP program or multi-media authoring system (hand wave… I do not know much about those, I must admit), it would be even better. What I imagine is something vaguely resembling a large tool-bar-like widget with a frame for each copy buffer, showing the elements inside in a WYSIWYG view, acting as drag sources and drop targets, too.

One may argue that this kind of visualisation is a terrible waste of screen real estate, but I think that has become a non-issue with widget sets that allow one to tear off, rearrange and fold away most parts of the UI.

It may only be a personal gripe – but I think this is a nice example to illustrate that today’s GUIs often are one-way interfaces: they provide a way to trigger operations (`Cut’, `Copy’ and `Paste’ buttons), but not all the feedback they could provide about these operations.

A favourite argument of hard-core command-line fanatics is mentioning the interaction of the shell and Unix tools. It is indeed a wonderful thing, representing the `plumber’s approach’ towards getting a job done – at the other side of the spectrum, there is the `kitchen sink approach’, typically represented by Emacs. Large `kitchen sink’ applications usually already feature GUIs, while there does not seem to be an acceptable GUI for general-purpose Unix plumbing yet.

Plumbing, as defined by e.g. the Jargon File, is the act of interconnecting several small Unix tools by means of pipes and/or temporary files. In my opinion, this can be visualised and controlled by interfaces without dumbing them down.

A typical Unix tool can be abstracted as a black box with a data intake, a control panel and a couple of data outlets (typically two). Why not let windows represent those black boxes and connect their sides with pipes, or by letting them snap together like building blocks? Special `tools’ could channel the output into and out of temporary files or convert a stream of file names into a stream made of those files’ contents (à la xargs cat).

Of course, all this needs good front-ends to command-line tools; but they can be done, too (see below).

3.3. Rethinking and redesigning – `dumbed down’ vs. adequate

The work that is done on new graphical interfaces for Unix, especially Linux, is an opportunity to take a new look at GUIs in general. Unix GUIs need to be based on a different philosophy. They should not be afraid to be different wherever it is appropriate to make them easier to use, more efficient or both.

The emphasis in the above sentence is on `both’. It is not necessarily easy for the UI designer -actually, it probably is harder- to design an interface that is easy to use and efficient. Creating a dumbed down interface is much easier on the design side.

Let us suppose a front end for a complex Unix command-line tool needs to be written. The tool has accumulated 30 different command-line options over the years, some of them are switches, others take arguments. In a typical GNU fashion, they come in both long and short versions. In 90% of all cases, only about five of the options are needed. Maybe the front end is necessary as a part of a GUI `plumbing kit’ as described above

A typical dumbed down approach would be to write a dialog to control only these five options, with the appropriate check boxes, radio buttons and text or number entry fields. Of course, this hides lots of the tool’s features. And of course, the user will not learn much using this front end. They do not even see the command line that is built from the options.

If one does not want to dumb the interface down, one could make a huge dialog with entries and buttons for all the 30 options. Unfortunately, this would probably confuse most end users – it would be tedious to pick the small number of commonly needed options out of the big lot.

Multi-page dialogs to the rescue! It would be a workable approach to put the common options on the first page of a `tabbed’ dialog, the others on an `Advanced’ tab, and perhaps an editor widget to edit the finished command line on a third tab. Of course the front end would have got to parse the command line whenever it has been manually changed, such as to re-adjust the widgets in the other tabs of the dialog – this technique, `two-way editing’, is common in modern IDEs.

Of course, one could also put the above functionality in a `wizard’ or `guru’, but wizards tend to be less efficient than multi-page dialogs because one has got to browse through all of their pages even if one has changed just one of the entries. (Hence my firm belief that every wizard should have got a `Finish’ button wherever applicable.)

There is an approach that is even better in my opinion – a documented option browser (Martin Vermeer has suggested the term `man page view’ for this). That is, a dialog with a selector of options the command takes; whenever one clicks on an option, the documentation for this option is displayed along with entries to change its value. A frame with a tree view of the options, sorted by category, would be an excellent selector. This kind of dialog is document-oriented and could, in fact, resemble an interactive, parsed man page. As I often browse through a man page in one window or virtual console while editing a command line in another one, looking at all the options a command takes to pick the ones I need, I find that this interface would fit my needs well – again, I suspect I am not the only one who works this way.

The above approach, too, would profit of a text entry where the command line in composition can be edited. This field would also need a parser and syntax checker, then. Being able to fold it away when you do not need it would be a plus, as always.

(There is a project trying to design a universal GUI front-end in Java which presents `wizard’ or `guru’ interfaces to command-line tools; it can be found on Freshmeat if you’re lucky, but I’ve not been lucky enough to dig it up again. And here is an OS where a similar approach to the one described in the example is already built in: AS/400.)

All right, now I have said a lot about how I think user interfaces could be made more intelligent and more efficient, but remember how I talked about how they should be easy to use at the same time?

Surely another hard job for the UI designer, that is obvious, but how can it be done?

4.1. A case in point: vi the gentle way

The classic visual editor on Unix is doubtlessly vi. There is hardly any piece of software over which as many flame wars have been fought, except maybe its perennial opponent in such wars, namely Emacs.

vi is the archetypical example for a very user-unfriendly, yet, in the hands of a professional, highly efficient application. Classic vi is really like that. The program gives no hint whatsoever of the various clear-text commands it accepts, of what state it is in (vi‘s insert commands like i, a or A put the editor into a different state), not even of how to leave it. This has changed with modern implementations of vi; e.g. Vim will by default tell you about its state and display a help text when started without specifying an initial file to edit. Vim also comes with an on-line help system.

Now, let us have a look at the `learning curve’. At the end of the curve, there is a vi professional who knows all the commands by heart and has had enough practice with the editor to never be unsure about which state it is in. Obviously, this is the ideal user for the original vi. The only way to get to this point with the original is to read the vi(1) manual page, written documentation, books or to use some vi tutorial. I have read that many Unices ship a vilearn program that will teach one vi; yet I have not seen one of those.

At the beginning of the learning curve, there is a user which knows absolutely nothing about vi, not even the concept of command mode, colon mode and insert commands which is essential for using this editor. We can however presume that they at least know about what the special keys on their keyboard do.

Such a user could surely start Vim and read the instructions on the splash screen, they could even enter the on-line help and, if Vim is correctly configured, soon start working inside an i or a insert command, since Vim allows the use of special keys there. As one can see, this implementation of vi already goes a long way to bridge the distance between the ends of the learning curve.

Yet, most of the commands are still non-obvious. When I first started to use Vim regularly, I almost never left the insert commands and thus treated this editor quite like a micro-Emacs – which is pretty ironic. Most of the knowledge about command-mode key combinations was then picked up from newsgroups or books, sometimes even from Vim’s on-line help. Clearly, there is some need for both obvious and (I hate using this word) `intuitive’ shortcuts into vi‘s functionality that are transparent enough to give `tourist information’ about how to invoke such functionality over the keyboard.

This could be done in an X11 implementation of vi or Vim (gVim, the GTK-based front-end to Vim, already does it to a certain degree). There could be tool bar buttons and menu entries for common commands, labeled with the appropriate key combinations. The buttons could display the command letters shortly, when depressed. This is probably a viable way to transfer tourist information. Another feature could be borrowed from Emacs: if you invoke a function over the Meta-x command mode in Emacs which is already bound to a key, Emacs tells you about it. A newbie-friendly vi could do about the same, for example telling the user that dd deletes a line when they have deleted one with Backspace for the tenth time.

Even in a program with such a crassly unusual user interface as vi‘s, user-friendliness is possible. Implementations such as Vim demonstrate it, and clearly, even more could be done.

5. Conclusions

As one can see in the above examples, adequate, efficient and user-friendly interfaces need a lot of thought -even vision- and work. Again, I am not a UI designer – people who are would probably have got far more and better ideas than me.

Anyway, when designing a user interface, the goal should never be to duplicate something existing, but to create something adequate. Every task needs the interface that fits.

5.1. First Conclusion: What makes a Unix GUI different?

Unix is mainly two things:

Powerful,

because of its (mostly) elegant design, and

old,

thus having developed a huge number of tools and applications that have been improved and honed over sometimes more than twenty years.

Any adequate interfaces to Unix, especially graphical user interfaces (which always run the risk of becoming `dumbed down’), need to take these factors in account.

A user interface that ignores the big Unix tradition is as frustrating to the more-than-occasional user as is an interface that does not allow full control over Unix’s power. As you could see in the section about Unix plumbing above, unusual approaches may need to be taken to allow that kind of control.

As far as I can see, making an interface visualise what is happening underneath instead of hiding it is the best approach towards designing an efficient and easy-to-use GUI. Unfortunately, it is not too usual and not too consistent with the majority of applications to use this approach.

5.2. Final Conclusion: Inconsistency as an opportunity

Looking at the debates in c.o.l.a (and not only there), one could think that the Holy Grail of modern UI design is consistency, that is, consistency of look and feel.

There is nothing to say against consistency per se. Widgets that do the same thing should look the same and feel the same – a perfectly good intention. But, as every advocate does sooner or later, the advocates of consistency tend to go over the top at times. For example, they complain so often about the existence of several different widget libraries for X11 that it has become an advocacy classic over the years.

But, as long as one can recognise radio buttons as radio buttons and check boxes as check boxes, do they really need to look completely alike, everywhere? The developers of, say, Rosegarden or the GIMP have created their own kind of look and feel for their application, the toolkit the GIMP team has designed (GTK+) has even become very popular `outside’, as a general-purpose toolkit – do we really want to take this option away from developers, making them use a single widget library? Unix often is all about choice, and free Unix such as Linux is even more.

Consistency by all means usually is a foolish goal. It certainly is OK to have scrolling look and work the same in every text editor or word processor, but for a pager or previewer, it may very well be clumsy. This is just one example. Different tasks need appropriate interfaces – consistent where possible, but different where necessary.

The unusual and often highly idiosyncratic interfaces that have evolved on Unix over the years, such as those of Emacs and vi, should not be abandoned. They are a huge resource of unusual ideas, and often, unusual interfaces are right interfaces.

Indeed, free software, and especially free Unix, has already become a biotope for user interface ideas which, often having been developed by commercial vendors, are pretty much `dead’ in the marketplace due to overpowering competition or changed corporate tactics. The best-known example is probably the NeXTstep/OpenStep look-and-feel. In its last incarnation, Apple’s MacOS X, the characteristic NeXT elements have mostly been abandoned in favour of a MacOS-like interface. But NeXT is not dead, as it lives on in projects like Window Maker, a part of the large-scale GNUstep effort, and software cloning other NeXT tools, such as the File System Viewer.

A. Resources

All the URLs from the text as well as some additional URLs are listed here.

• AS/400, an operating system where every command-line tool features an optional menu-based interface
• Where it all began: The comp.os.linux.advocacy newsgroup
• Emacs – more than just a text editor featuring a viewable kill ring
• FSViewer, a clone of NeXT’s File System Viewer. Still heavily alpha, but cool for sure. Comes with a neat 460 kB of icons which are works of art.
• Frequently Rehashed Topics on comp.os.linux.advocacy (alternate site)
• Freshmeat – need I say more? This is the bleeding edge.
• The GIMP: the application GTK+ was originally created for
• GNUstep – these people are cloning the complete NeXTstep interface development environment, and they are serious about it. This is a huge project.
• GTK+ – a very popular, themable widget set. Arguably cool.
• Isys Information Architects, Inc., the people running the Interface Halls of Fame and Shame
• Mac OS X, the last descendant of NeXTstep
• Matthias Warkus, author of this editorial
• Rosegarden, a sequencer which would look considerably less stylish if it had to live with a style guide
• Vim, a vi implementation with many features and (in my humble opinion) enhanced usability.
• Window Maker, probably the most popular stand-alone window manager in the free Unix world, with a 100% `steppy’ look-and-feel.
• XEmacs, the competition of GNU-Emacs, which they claim is Generally Not Used, Except by Middle-Aged Computer Scientists. As I am neither middle-aged nor a computer scientist, this was a surprise to me as a GNU-Emacs user.

B. Thanks

Thanks go to:

• Eduard Bloch, who gave me a bit of motivation that certainly helped
• The regular crowd on c.o.l.a
• Martin Vermeer, without whom this document would not exist
• weblint for picking the fluff out of my HTML
• Dave Whitinger, without whose reminders this document would have been abandoned in early alpha stage 🙂