GUIs Considered Harmful by Tom Christiansen

[princepawn]

This short article by Tom Christiansen is nothing short of a classic. I italicized the part that is most important to me. This was written about 10 years ago (1991 or so) and posted to usenet.

When you read it, think of just how wedded your business logic is to HTML, CGI, or mod_perl.

GUIs Considered Harmful

I am increasingly troubled by how many new applications are designed to work solely under a GUI. While this may make some amount of sense for people coming from the PC or Mac worlds, one of the strengths of Unix has always been the ability to use it from anywhere. These people don't seem to understand this.

Of how much ultimate utility is that nifty new spreadsheet, editor, or debugger if I can't dialup from the field and run it on my vt100? Too often a tool that "does windows" is little more than a marketing gimmick to dazzle impressionable users into not noticing that they don't have the real functionality they need.

GUI-minded programs seldom lend themselves to being used as components in larger tools. As such, they do not fit well into the UNIX tool-and-filter philosophy. Instead of each being a single program that modestly attempts to do one thing well, they are a throwback to the Bad Old Days when each program was a standalone, monolithic monster that didn't interface with anything else.

It's all well and good to place a GUI wrapper around an existing tool, but to design a new application with only a GUI interface in mind is to forever limit that tool's flexibility. After all, how to you write a shell script that drives an automated xrn session?

Providing programmability for the fancy graphics software remains an open problem. The most effective use of GUIs in UNIX environments is to design the nitty-gritty computational function as a "back end" that can be driven either manually or automatically.

The GUI wrapper should be a separable module. If they're plug-replaceable, the application isn't irretrievably wedded to any specific GUI technology, such as SunView, NeWS, or even X11 or its children, like Open Look or Motif. Sending standard commands down a pipe the way the STDWIN or wafe packages behave is also a reasonable approach.

This means your program should be runnable both with and without the GUI present, and accept input from a mouse or under programmed control. Preferably that means both a shell-level interface for convenience and a C-level interface for efficiency; Perl programmers could elect either method. That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems.

It has been noted that GUIs make simple things simple, and complex ones impossible. Certainly it is worthwhile to make simple things simple. But too often software is geared to only one level of expertise. That which is novice-friendly is too frequently expert-hostile, and vice versa. Being needlessly forced to click the mouse over a menu will slow down the expert user who is more comfortable with a keyboard interface.

Gratuitous distractions from the keyboard only slow down the experienced user. A precision pointing device that didn't require taking your hands off the keyboard would help. There are cases where only a GUI makes sense, like a CAD system. Being able to delineate a region or draw a figure with a mouse is probably a reasonable use for it, but selection of a range of possibilities isn't, at least not after you've become familiar with the tool.

--tom

-- 
    Tom Christiansen      [e-mail]      

    A truly wise man never plays leapfrog with a unicorn.

[footpad]

I certainly agree with many of the points in the article and with your admonition regarding the separation of business rules from presentation or data abstraction code.

I would caution folks to read the article carefully and to remember when it was written. (In 1991, Windows was just starting to become firmly entrenched in the business world and the Internet was used very differently than it is today.)

I would also be interested in knowing what Tom would amend, if anything, to his thoughts today. I know I held certain rather strong opinions ten years ago, thoughts I'm a little more flexible with today.

In any event, I would rather folks read this as a reminder to design their applications carefully, separating various elements as appropriate, e.g. MVC.

Like them or not, GUI's are a part of the modern application development process. And while I don't think every application should be a GUI, I also think the reverse is true: not every application can (or should) attempt to executed from a command-line.¹

There's a balancing act involved and far too many programmers ignore the flexibility of command-line approaches. Indeed, there are many ways you can use the command-line to make your applications more flexible. For example, The Pragmatic Programmer recommends adding command-line support for testing your derived results, which can save countless hours of manual testing effort.

In any event, I believe that the best programmers create highly organized applications using good practices, such as the MVC model. I believe they also create applications appropriate for the conditions they're commissioned under. For example, a client willing to pay for a 40 hour job will likely get different results than the client paying for an 80 hour job--unless the 80-hour job can be built in 40 hours. So, it's important to consider all factors before making design decisions--and that's my real point. You should know what you're going to do and why you're doing it before you start pounding out code.²

(Along the same lines, I also believe that you should also give yourself a break. You will make good decisions and you'll make bad ones. That's part of the process. Learn from the mistakes and take time to run a personal post-mortem on your part of a project. What could you have done differently? What worked? What didn't? Once you have that, devise and incoporporate strategies for avoiding the mistakes in the future.)

I do agree that many people who design GUI applications take far too many shortcuts and ignore the potential needs of users other than the ones interviewed by the business analyst. And that's dangerous. It can also limit your access to certain markets. For example, the U.S. Government now requires accessibilty³ to be built into all applications developed by sub-contractors. If you can't do that, you can't bid on those contracts.

If you create GUI's, then make certain that every rodent-triggered event can also be triggered with the keyboard. For best results, let the user assign the hot-keys, the accelerators, and so on. That way, you can let the user configure the program for their way of working.

If you're interested in reading a good, thought-provoking book on GUI design considerations, I highly recommend Alan Cooper's About Face. It's a little dated now, but it still raises some important points worthy of consideration.

In any event, the real lesson from all of this is to separate content from presentation (You're all doing this in your web pages, right? Yeah, that's what I thought) and to make the decisions appropriate for the project at hand.

--f

¹ I think very few applications fall into the latter category.

² For those looking for things to work on, this might an area to explore. We have gained a tremendous number of tools for building various applications with Perl and with other languages, but the process is still very labor intensive. It would be really nice, for example, to see tools appear that automate the tedious stuff. There is, after all, more than one way to do things.

³ The site that link points to is geared toward web accessibility, but the anchor points to the actual standards. Since I believe it's useful for folks to understand both issues, I chose the first link. Hope you understand.

[jplindstrom]

While I agree 100% on the programming part of this article, I think it kind of misses the point when it comes to what GUIs are good for.

It has been noted that GUIs make simple things simple, and complex ones impossible. Certainly it is worthwhile to make simple things simple. But too often software is geared to only one level of expertise. That which is novice-friendly is too frequently expert-hostile, and vice versa. Being needlessly forced to click the mouse over a menu will slow down the expert user who is more comfortable with a keyboard interface.

What has mouse-only interaction got to do with a GUI? A _good_ GUI will provide as many modes of operation as possible, including keyboard where appropriate (which is many places for most applications).

E.g. a graphic-intensive program like Photoshop has a LOT of keyboard shortcuts for e.g. selecting tools in the toolbox, selecting etc, etc. You can really tell that this program has been around a long time by looking at the streamlined UI. And, it's really a shining example of TMTOWTDI once you learn the more esotheric parts :)

One of the good things about a GUI as opposed to a CLI (Command Line Interface) is that they are "explorable"(1) to a greater extent. Rarely used commands are found in menus for easy browsing, commonly used commands have shortcuts and maybe a button in the toolbar. Using the GUI to learn to use the application is a good thing because it will allow people with different skills to jump right in at a comfortable level, allowing them to grow more advanced and efficient ways to use the program over time.

People are different. Some prefer text. Some people are more visually oriented.

Programs are different. Some problems are more suitable for a visual direct-manipulation approach, while other are strictly text-oriented, which the moronic and endless point-and-click configuration of many Windows programs proves (where text files would be a so much more usable and efficient solution(2)).

Programs have different usage patterns: the program itself may be complex or "shallow", different users may use the program seldom or daily. Ignoring these usage patterns will get you a bad user interface, be it a GUI or CLI.

/J

(1) http://www.asktog.com/basics/firstPrinciples.html#explorableInterfaces

His entire site is very good, BTW. Other nice sites about GUI and usability design are:

http://www.yendor.com/usability/

http://www.iarchitect.com/mshame.htm

http://www.sylvantech.com/~talin/projects/ui_design.html

(2) But like I said, more modes of operation is better. What's wrong with text files for experts and automatic processing, _and_ a GUI for seldom-users?

[pmas]

I liked jplindstrom expresion "explorable interface".

I read somewhere about psychologic research how users are learning and remembers new knowledge. Result was, that we have two modes of memory: "learning" and "recalling".

When in learning mode, it's easier to work with fully described text info. Easier to use menu, and even maybe RTFM... ;-)
In "recall" mode, when we want to find something we learned before. Any association works quicker than text. So you can recall by music, picture, position of fingers...

I remember after couple months not able to work with computer and my favorite editor, I could not recall how to do some actions. However, when I put my fingers on the keyboard, fingers knew what to do. Same with icons - they do not make sense first, so we have ToolTips in windows (yellow bubles with help text) - but hey will appear only if you are not sure if you want to click, for a seconnd hovering mouse over the button.

I guess this shows that GUI is not all bad. Sure I like CLI for tools, and non-mouse commands (keyborad shortcuts) for actions I use often. But I like I can explore menu I do not use quite often. If interface is complex, you may not want to expose all complexities in flat CLI. System of hierarchical menus, grouping relevant commands together, might be preferable.

And yes, I like all my keyboard shortcuts and scripts to save clicks on GUI - but only for actions I perform qften enough.

pmas
To make errors is human. But to make million errors per second, you need a computer.

[zebedee]

Bitter experience has taught me ... keep your gui, business and data layers separate.
Always ask - what would happen if I had to access the business logic from a command line, or programmatically (e.g. using COM)? How much would it take to use my component/black box/business logic from a web page rather than from a client-side "thick" gui or console app? What would happen if the database back-end changed from server X to server Y?
I've written too much code when all three layers are all mixed up and it's "impossible" to move to different technologies ...

[mandog]

If you consider the possibility of limited development time there may be a flaw in this argument. If GUI loving newbies are only willing to pay for GUI version of the application, it may not make sense to develop both.

On the other hand, it is probably easier to build a framework of test code around a CLUI than to record and replay sequences of keystrokes and mouse clicks. The unwanted CLUI might be justified to assure quality.



--mandog