Slashdot Mirror
The Humane Interface
Introduction
The Humane Interface: New Directions for Interface Design, by Jef Raskin, the creator of the Macintosh project, provides an interesting read chock full of controversial ideas. As the book's full title suggests, Raskin focuses mainly on how things ideally should be made, rather than offering advice and recepies that can be immediately applied to problems in today's systems.
Don't Think!The approach taken by Raskin stems from his definition of a humane interface: "An interface is humane if it is responsive to human needs and considerate of human frailties." In practice, this means that the interface he suggests is based on ergonomics and cognetics (psychology).
Basically, the idea is that we can do only one thing well at a time consciously. Most of us can walk, chew bubblegum, hold our bladder and speak (semi-intelligently) with a friend, all at the same time. This is because the only thing we are consciously doing (the only thing we are concentrating on) is the semi-intelligent babble. On the other hand most of us run into trouble when trying to study calculus at the same time we're hitting on a sexy lady (make that a handsome man for those 5% of ladies here at Slashdot, or some sort of hermaphrodite freak for those 11% with doubts about their sex).
The point with this is that the one thing we're consciously working with should, with as few interruptions as possible, be the content we are producing with the computer, not the computer itself. That is, all interaction with the system should, after the initial learning phase, become habitual or automated, just like we can walk or drive a car without ever consciously thinking about it. This way we could maximize productivity and concentrate on the content of our work.
There's Only One Way to Do it
For commands to become habitual as quickly as possible some interface-guidelines are given. First of all, all modes (differing types of responses based on context) should be eliminated. The system should always react in the same way to a command. All modes generate user errors when the user isn't paying attention to what mode the system is currently in (and the user should not have to pay attention to the systems current mode, the user should only have to pay attention to the content he or she is currently producing). An example of mode error happened to me while I was writing this review, just a few lines up: I unintentionally left overwrite on when I thought I was in insert-mode and thus overwrote a word by mistake. Of course, this was no big deal, but I had to take my mind off formulating the sentence to figure out what had happened, just for a second, but long enough to derail my thoughts, and that derailing should never happen.
Another way to speed the transition to habitual use is monotony. You should never have to think about what way to do something, there should always be one, and only one, obvious way. Offering multiple ways of doing the same thing makes the user think about the interface instead of the actual work that should be done. At the very least this slows down the process of making the interface habitual.
Unorthodox Suggestions
There are of course a lot of other suggestions in the book, some expected, some very surprising and unorthodox. The more conventional wisdom includes noting that the interface should be visible. That is one of the downsides of the otherwise efficient command line interface, i.e. you cannot see the commands at your disposal by just looking at the interface. A method called GOMS, for evaluating keystroke efficiency, and Fitts' law (the time it takes for you to hit a GUI button is a function of the distance from the cursor and the size of the button) are also among the less surprising ideas in the book.
The more unorthodox suggestions include Raskin's proposal for a universal undo/redo function, not just in the different applications but in the system itself. The same gesture would always undo, no matter what application or setting you last touched.
The really controversial idea, though, is to abandon applications altogether. There would be only the system, with its commands, and the users' content. Even file-hierarchies should vanish along with the applications, according to Raskin.
ConclusionsThe Humane Interface focuses on the principle of user interfaces and the theory behind them. The ideas presented in the book generally make sense, after considering the background and argument for them presented by Raskin; even if some seem very drastic when first encountered (I can hear Slashdotters firing up their flamethrowers after reading the end of last paragraph). As mentioned before, the book does not provide many ready to use recipes. It does provide a good insight into the background of user interfaces, which the reader can apply to the project at hand.
Some related ideas were dicussed about a year ago on slashdot. The Anti-Mac paper discussed then, came to pretty much the opposite conclusions from the ones that Raskin presents (Raskin makes a case against beginner/expert interface levels). After reading both sides of the story, I'm inclined to believe more in Raskin's reasoning.
The only Open Source or Free Software the book mentions is Emacs, in a discussion about string searches. (The incremental model in Emacs is preferable to systems where the search does not begin until you click the search button.) I do, however, believe that the alternative interface models could be an opportunity to the open source community and that Raskin's ideas perhaps are more likely to be implemented and tested in such an environment, compared to the possibility that Microsoft would greatly simplify the thousands of commands that MS Office consists of. I therefore warmly recommend this book to anyone doing software development and I would love to see some of the ideas used in KDE or GNOME.
You can purchase this book at Fatbrain.
A lot of users (my mom, for example) use their computer for three things: reading email, surfing the web and word processing (Word). Now tell me why any of these three tasks require a user to think about "a file". Tell me why any of these three tasks require the user to think about "C:\My Documents\WorkStuff" (or "/home/foo/docs/workStuff", if you prefer).
These concepts are all hold-overs from an era where the people designing software were the only users of the software. If I'm a programmer, of course I'm going to design my shell so I can write shell scripts. Of course I'm going to give myself the ability to create complicated hierarchies -- that's how I think!
Now, we have a lot of users of software who are not programmers and geeks. If we care about them using technology, we need to think about the easiest thing for them. This doesn't mean we have to get rid of command lines, we just have to come up with something else for users who do not want (or need) command lines. This is not a zero-sum game. The growth and popularity of technology is a win for everyone.
To make this happen, a portion of the software community has to realize that they are designing software for people who are not programmers and who are not (gasp!) interested in technology for technology's sake. Some of us (but not all) need to get rid of the attitude exemplified by the following quote:
"Linux *is* user friendly. It's not idiot-friendly or fool-friendly!"
The majority of users are not "idiots" or "fools". Some are doctors, lawyers or artists who have chosen to concentrate in an area outside of computers. Saying they are idiots because they don't understand symbolic links is like a eye surgeon saying that a programmer is an idiot because he can't remove a cataract.
In an ideal world, there should be only one way to do it, BUT the USER should be able to determine what this one way is.
In my humble opinion, the direction that GUI design needs to and, inevetably-- i have no idea when, but it HAS to go this way eventually-- will go, is in the direction of infinite modularity: the direction of seperating style from content, seperating form from function. Up until this point, interface design has been a constant war between the macintosh "all applications should act roughly consistently with one another" mindset, where you take a single set of guidelines and stick with them, and the Xwindows/UNIX "interface guidelines are fascism" mindset. The UNIX mindset has an extremely good point-- but makes the mistake that it just trades off apple's single point of interface fascism for a billion tiny points of interface fascism, one for the author of each application. The author of each application is still the one in control, and is in control only of the application they created. The user is in control of nothing. And from the user's standpoint, being powerless over the behavior of a bunch of applications that all act the same (as on the mac) is better than being powerless over the behavior bunch of applications that all act differently (as on UNIX).
Ideally, the person who dictates interface behavior would be neither Apple nor the application designer, but the user. Ideally Apple and the application designer would both offer *suggestions* as to how the application would behave, and the user would determine which, if either, of these suggestions the application would follow.
Ideally, eventually we will move to where programmers don't say "i want a text field, two buttons, and a menu with these specific sizes and positions", they will say "i want a text field that you can do these two specific things to and which you have these options for, and the text field and the potential buttons and the potential menu have these specific relationships to each other", and the system will build the interface based on the rules the user prefers.
Hmm. I'm kind of rambling now, and i have to go. But how i was going to end this is by saying that the direction things should take from here, and the direction things ARE taking from here (at least with the things that GNOME and apple are putting forth) is that common things like text fields and scrollbars should be done by a single systemwide service, but *abstractly*-- such that the user can augument the behavior of those text fields or whatever at will; and that we should move toward the model used by CSS, the glade files of the GNOME api, and the nib files of apple's Cocoa API-- where you define functions, and then define an interface, and then link the two together. I, the user, can open up the nib files inside of these mac os x applications i use, and because the relationship between interface and function is abstract rather than hardwired into code, i can rewire that relationship-- i can delete, rearrange, and redesign the function of interface elements of existing programs in InterfaceBuilder despite not having the source code to the program. This is the way things should be.
OK.. i'm done. thanks for listening :)
"I have a firm belief that computers should conform themselves to my behavior, and not the other way around." --Steven Levy, on the original Newton release of the Graffiti pen input system now used in the palmpilot
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
I've said this before, but I'm not sure it sticks yet. I think that Raskin has a good point about consistency across system interface. However, I've come to beleive that UI is not the bugaboo of human-computer interaction. The real problem is system configuration/administration.
My parents, for example, are competent using any number of applications (all with varying purposes and slightly different UIs). But ask them to change any system setting, and they will either give you a blank look or freak out. They don't have the faintest idea of how to start. They're even wary of navigating control panels until they find the right tab/checkbox.
Fair enough, right? The big realization came when I realized that I'm afraid of system administration too. Especially when it comes to unix systems. Even with all those neat-o little configuration tools that come with Linux now, it can be a nightmare to setup X or networking if things aren't just how you found them.
Compared to these sorts of trials, learning to type the right commands or navigate a heirarchy of menus is easy. Most humans are born with the ability to pick up language, so typing commands isn't too much of a stretch. Pointing and clicking isn't hard either. What we're not equiped to do is manage a lot of detail, or absorb a lot of underlying principles quickly. Until someone manages to address those concerns, UI may be great but human-computer interaction will not move far forward.
--
Tweet, tweet.
M$ Windows is one of the worst things that could have ever happened to GUI design. Microsoft has allowed so much DOS to pollute the Windows UI that what you have is a complete breakdown of the whole "user is in control" file/folder system the mac had. I think many geeks who say "we need to get rid of files and folders. They're too hard for normal people to understand" fail to take this into account.
On the mac, the user could drag a folder with an application to their desktop. We're not talking shortcut, we're talking actual program. If they needed to reinstall the OS, they could drag a folder with an application inside it to a zip disk, re-format the main HD (and give it a name more intelligible than a drive letter), reinstall OS, and then drag the folder with the program from the zip disk to wherever the hell they wanted to. Congratulations, program is now installed. To delete program, drag folder with app to trash and empty. There were no special names that were appended to the regular name of the file (i.e. no filename extensions). The file was simply whatever the user wanted to name it--they could tell what type of file it is by the LATFI method (Look At The Fine Icon). To install a driver (aka extension), drag extension file to extensions folder. To deinstall, drag to trash and empty. And above all, all files, including system files, had "Plain Damn English Names"(tm). Files and folders were easy to understand simply because there wasn't anything complex that one couldn't understand. The macintosh was the most perfect concrete abstraction anyone has ever designed.
Unfortunately, the redmond morons were extremely unwilling, for technical and well as religious reasons, to make sure that good ole CLI DOS didn't contaminate windows. They didn't design the GUI from the ground up as if the command line never existed (like Apple did). They simply made DOS a little bit easier to understand. And they took a simple, concrete abstraction like the Macintosh and made it abstractly concrete. On windows, you have a desktop, technically, but often when you drag stuff to it, you're asked if you want to create a "shortcut"--it tries to discourage you from putting the real thing there. So the desktop as a container breaks consistency with the folder as a container-type object. "You can put anything in a folder, but the desktop? No that's different." Then there's the matter of "My Computer". Your partitions do not sit directly on the desktop. You have to go through this strange layer called "My Computer" that isn't quite a folder and isn't quite a file. Once inside the "My Computer" limbo, you have the drives/partitions themselves, which cannot be given any name you want. You can sort of give an alias, but you must always see c: and a:. Then you've got "Special" folders with "Special" abilities that break consistency with the way that normal user-created folders act. There's "My Documents", which has the weird property of being the first place the file dialog warps to. Then there's "Control panels" and "Dial-up networking" and "Printers" folders, which exist outside any known location on your drives. These folders really don't like having stuff moved in and out of them like the regular folders do, and in that way, they too break consistency. To add something to a folder, the user simply drags it to the folder and drops it. But the user can't (with most Windows software) drag a folder with an application inside from a CD-ROM to wherever the hell they want to put it. They have to go to "Add new software", which many times will put the program into the specially designated "Program Files" folder--yet another folder with strange and unusual properties. And finally, there's system files. Ordinary files and folders the user names can be up to 255 letters of Plain Damn English. But files such as the ones in the Windows folder and those distributed with most 3rd party software--those are just plain 8 letter gobbledygook. With all this needless complexity that's in windows, with all these rules to exceptions to exceptions to rules, is it really any wonder that M$ users face such a tough time navigating through the file/folder system?
Now maybe the concept of the file/folder is a little bit outdated. Jef Raskin certainly seems to think so. I kind of agree with him. But the fact of the matter is that any flaws that the mac desktop metaphor had was made 100 times worse by Microsoft's incompetance at designing user interfaces.This is the first I heard that this law had a name, but one thing I've wondered about is why most GUI editors have scroll bars on the right and not the left, where most work is done. E.g. for cut-and-paste you have to go all the way to the left to select and all the way to the right to move.