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.
Here's the kind of idea that would break Gnome, or KDE away from the GUI pack (again, from JR's site):
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.
Here on Windows2000, an exception is made, and a reasonable one, for scrollbars. Menus and buttons do not track outside the control, but scrollbars do, and definitely should. There are two reasons for this:
1) The control moves, but it's restricted to only one orientation.
2) The control is very narrow (in the orientation perpendicular to its movement).
Moving a vertical scrollbar for any significant distance requires moving the pointer in a nearly perfect vertical line. Try it and watch how the pointer wanders from left to right. To be usable, the scrollbar should then track in order to accomodate the pointer's inevitable horizontal movement outside of its area. Imagine trying to move a 1-pixel wide scrollbar if it didn't track! (or just try XTerm with Emulate3Buttons with a pencil eraser-type mouse for a reasonable simulation!)
Things are a little different with a menu. When you move the pointer up and down to select a menu item, the "control" (in this case, the menu highlighting) does not need to track because the menu itself is wide enough to accomodate any horizontal wander. Note however, that the the menu itself still tracks: when the mouse leaves its area, the highlighting disappears but not the menu itself. Why? It seems like this behavior is to enable nested menus. Chasing down a deeply nested menu item requires moving the pointer in a series of long horizontal lines punctuated by steps. The menu should track so that if even if you drift off of a menu, you can go back and continue from the last "step".
I believe that KDE and/or GNOME do NOT track nested menus, and this can be VERY frustrating.
Finally, when you click on a button, the button doesn't move, and neither does the pointer -- or at least it doesn't need to. Therefore no tracking. On Windows the button correctly pops back up when the pointer leaves.
BTW, this is all off the top of my head, just from messing around on Windows...
How long does driving take to learn? ...to get behind the wheel of a potentially deadly vehicle, slap 'er in gear, and tear out across the interstate?
It *does* take a while-- a few months, perhaps, to become proficient. Cars are simple because they have 4 or 5 controls, not counting simple things like lights and air conditioning. But it takes a few months to learn how to drive.
Why is this? Could it be there is more to driving than just learning the function of 4 or 5 controls? Could it be that the interaction of other drivers fouls up the simple use of 4 or 5 controls?
If a simple something with a single purpose, such as a car, takes weeks or months to learn how to handle properly, why shouldn't we expect the *same* learning curve for a multipurpose device like the computer?
I don't expect my SO to know how to rebuild a carbuerator. But at the same time, I *do* expect her to use the turn signals at the appropriate time, and know how to obey speed limits. I also don't expect her to park her car in someone's bedroom.
Similarly, I expect her to know how to find a simple file she created last year, but managed to misplace. I expect her to know how to open photos, and email said photos to friends.
One day, when computers are sufficiently intelligent, we can simply talk to them as if they were Sigfrid von Shrink. Until that day, it is a mark of intellectual laziness to refuse to take the time to learn a general tool that is so important to our lives.
Microsoft is to software what Budweiser is to beer.
Grab cygnus toolset for win32 before you lose your mind. Hamilton c-shell is good too. Forget dos prompt, it's no replacement for a shell.
The gui monkeys have misunderstood something:
Hey language is inefficient... lets go back to scratching pictures in the dirt or hieroglyphics on the wall in order to communicate.
The command line is a language. They are stuck on the "pictures are better than words" meme. Yeah, true, they are, until you learn to read that is.
Visual stuff, GUIs, languages etc, are more *intuitive* in the same way that picture books are more intuitive to babies. It doesn't mean they are superior. This is why the best interfaces are a combination of GUI and language. It's just like the way you give children picture books while they are learning to read.
http://rareformnewmedia.com/
You know, I'm willing to bet that hermaphrodites are well-aware that people think of them as strange or weird without being called "freaks" in a large public forum completely non-related to sexuality or biology issues.
Furthermore, I'm pretty sure that most gay people would not list a "hermaphroditic freak" as their distraction-of-choice.
The traditional neutral phrase is "member of the appropriate sex", or MOTAS (straight from the Jargon File). Better still, leave the weird imagery out of future book reviews.
Dewey, what part of this looks like authorities should be involved?
Squeak, the open source implementation of Smalltalk, comes with windows with scrollbars on the right. Also, there is a strange way to page up and down. It also has another number of unusual UI ideas. And they are difficult if you come from other environments!
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
For commands to become habitual as quickly as possible some interface-guidelines are given.
No, for commands to become habitual you need to practice them. People have a difficult time learning the intricacies of vi because they don't use it for 100% of their text editing. Once I started thinking about every command I entered in vi before doing it (such as hitting 10j instead of the down arrow 10 times, or the various ex commands) they quickly became habitual. No interface is intuitive automatically (except, of course, the nipple :-) ). True, some are easier, but those that are the most powerful are usually those that require the most effort to learn.
This doesn't just apply to vi, of course, but anything sufficiently complex on a computer. Stick with one way and learn it.
As a new owner of a PalmOS device, I couldn't disgree more.
The palm is very simple. It doesn't cover a lot of ground. You can select buttons, you can enter text, you can choose menus, and the like. This leaves no excuse for the laundry list of issues I've had with my device so far. To list a few:
You may not agree with all these issues, but I believe you will find most of them stand. The Palm device, for something so trivial, suffers from far more than its share of usability issues.
-josh
Naturally, a review can't build up a supporting argument for the points made in the book. Therefore it's no suprise that several posters have refuted some of Raskin's proposals using arguments that Raskin addressed in his book. Here's a summary of counterpoints to several of the most common responses I found in this discussion. Also tossed in are an occasional citation from The Invisible Computer by Donald Norman. It is an excellent companion to Raskin's book.
and
Human beings are far more similar cognetively (psychologically) than they are different. Before we worry about designing interfaces that are optimized to those differences, we must first develop interfaces that are best suited to the %99.99 ways we think and behave alike. One example cited in the book is that human beings can only concentrate on one thing at a time. Raskin writes that the current state of user interfaces is nowhere close to being ready for the minor tweaks to our differences.
The above comment was arguing against having a Single Way to Do It. It's partially refuted by the previous counterargument. It's further refuted by Raskin's coverage of "habituation". The degree to which an interface becomes easy to use is directly proportional to the degree to which users can develop habits using the system. Having more than one way to do it prevents or slows down habituation by forcing the user to make a concious choice about which way to do it. The UI is also complicated by increasing the number of commands in the system.
Actually, they are mutually exclusive. Having a "single way to do it" means having a single, system-wide command to perform an operation. See above counterargument for why a single command is good. Furthermore, if having the user "choose" involves setting a preference that changes the way the system behaves, then you've created a mode. Modes are bad, m'kay?
Several posts talk about "intuitive" interfaces. Raskin points out that there is no such thing. People usually mean "familiar" when they talk about intuitiveness, i.e. a UI that is like another UI they have already learned or become habituated to.
In the The Invisible Computer Norman writes that there are 3 equally necessary legs to support a product: Technical, User Experience, and Marketing. Canon Cat had two of the three licked, but failed on marketing. That doesn't diminish the value of it technical and user experience achievements.
Yes, buy the book. Raskin's proposal for an interface without file hierarchies, file managers, or "files" per se is my favorite part. He addresses categorizing, organization, and finding documents.
This one's hard to address completely in a single paragraph. In short: efficient interfaces that allow habituation are both friendly and capable of expert use. Raskin dispells the notion that "user friendly" means "dumbed down". A humane interface is usable and powerful. A much better argument is in the book.
Actually, Raskin proposes something more like 0 applications, 1 system, N number of user created documents, 100's of commands that work in all documents. As an example he writes about the "calculate" command. Say a user wants to type in a formula and calculate the result. In contemporary systems, the user must run the spreadsheet application, type the formula into one of the approved formula entry text areas, and execute the formula. Raskin proposes that the user should be able to select any text, anywhere, and perform a "calculate" command on it (perhaps by pressing "calculate" on their keyboard). The selection is replaced with the result (which could be "can't calculate", "Not a Number", "Divide by Zero", etc.). The original formula is preserved in the document. So calculating a formula is reduced to: 1) type in formula 2) select formula 3) calculate selection.
Raskin directly addresses OpenDoc. OpenDoc and OLE (and it's ancestors) are still the wrong approach. The "different editors" are still applications, just disguised. It still has the same mode problems as seperate applications depending on which part of the document I'm editing, i.e. "am I in spreadsheet mode right now, or am I word processing mode, or am I in paint program mode?".
Citing The Invisible Computer again, Norman would say that these should be seperate devices. That is, one device for the creation and navigation of content and information. Another device for playing games. Norman proposes abandoning the general purpose computer and instead having multiple, less expensive devices focused on a single activity.
> all visionaries are subject to much abuse.
And therefore, all those that are subject to abuse must be visionaries? MicroSoft must therefore truly be the most innovative company out there.
True, they laughed at the Wright brothers and they laughed at Marconi. They also laughed at Bozo the Clown...
I take solace in knowing that if I'm modded down, it will only because I, too, am a visionary.
-- Don't Tase me, bro!
> The really controversial idea, though, is to abandon applications altogether. There would be only the system, with its commands, and the users' content
This sounds like opendoc. Does Raskin actually mention that opendoc is what he's talking about? Is opendoc what he's talking about?
How does Raskin propose that this state he advocates in his book be reached? If he wants to follow the opendoc model of applications being split up into as many tiny interlocking pieces as possible, with a framework for pieces from disparate apps being allowed to interlock with one another as long as they operate on the same kinds of data, then how does he propose that the parts be coordinated together in such a way that they appear, as he wants them to, modeless and consistent?
Basically what i'm asking is this: The things he proposes (a single modeless system that does EVERYTHING and in which every bit of interface is consistent with every other) are things which are extremely difficult to achieve unless every bit of said system is written by the same company. Does he suggest any way that disparate groups could work on the creation of a system such as he proposes without the different voices involved ruining the purity of the whole thing-- like, the people writing apps start doing their own thing, and eventually the differnet parts of the system become inconsistent again.
I also would be curious to see what Raskin would think of the mac os x "services" model, which attempts to revive the opendoc idea with in a less extreme-marxism manner-- applications can rewrite parts of themselves as "services" that do certain actions on certain types of data. If the user is using a program which uses a type of data that a service the user has installed can work with, the user is allowed to let the service wrest control of the data from the application and operate on it. Is this good because it's a step in the right direction, or bad because unlike opendoc the focus remains on the application and not the document?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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.
Because the number of people killed by incompetent computer usage is vanishingly small.
-jon
Remember Amalek.
While the Flamethrowers may be out of line, I do have some issues with some of his beliefs.
Most importantly, Raskin has a theory on UI and an idealized view of what can be accomplished. Neither of these can be viewed as realistic. An old axiom that comes to mind is: "The best way to make software user-friendly is to limit options."
Sure, let's do away with Beginner and Advanced interfaces to computers... How? Just do away with the advanced interface. Let's do away with Perl and its TMTOWTDI core belief.
Ideally, the computer should learn as it goes along. This is somewhat possible even with the "!grep" syntax of the shells. And even aliasing. When I type "!grep" it remembers the last grep pattern I did. What if grep became more intelligent. So I could say.... "grep messages.log" and it would remember the string I last searched that file for and options.
The next step in UI development is a UI that will learn from its user and adapt. Not a UI that tries to simplify the entire computing experience so that it is manageable by anyone with an IQ over 75. This was the initial design of the Mac OS, and one of it's worst features IMHO.
I'm reminded of VCR plus, the "make it easy to record programs" breakthrough of the '90's. VCR programming was too hard for most people it was reasoned, why not make it easier. Well, sure enough the problems with VCR plus were worse than trying to learn to set the recorder. And the "User-Friendliness" (aka. lack of telling you what's going on) made you reluctant to use it anyway, because you didn't know whether it would work or not until after it was supposed to have worked.
Modeless????? Well, the original modes came out of the fact that noone could decide how these things should work, some liked to insert, some overwrite. My mother has never switched modes, but I do 3-4 times an hour. Again, the answer is to do away with insert or overstrike, or devise something even more onerous that will not look like a mode but still accomplish the same thing I can do with one button right now. Perhaps Raskin would also like to do away with "Caps Lock" in the process. (Yes, that is also a mode.)
While there are some good points, the S/N ratio is well over 50.... And it is many times Raskin himself who is unwilling or unable to give up or reconsider what he thinks he "knows" as truths, often to his own detriment. Much of it stemming from the beliefs he fostered as an Apple developer.
~Hammy
I can see the problems with the huge, multi-level file hierarchies that are present in Windows, Unix and every other system under the sun. People just can't keep track of thousands of files organized in hundreds of directories in a big tree structure. So far, that's the only way to organize the googlebytes of data a typical computer has, and it works poorly.
Windows, the Mac, and the X GUIs GNOME and KDE address this problem by hiding the filesystem whenever it can. In Windows, you click on an icon or navigate the Start menu to start a program instead of finding the executable foo.exe somewhere in c:\Program Files\foo\. Unfortunately, the filesystem still rears its ugly head frequently, and forces people to wander through it.
Maybe a database model would work better than the traditional hierarchical file system for managing all our data - instead of having a tree of files in subdirectories, have a large database that can be queried using SQL-style commands by the geeks among us, and GUIs capable of Doing The Right Thing for every piece of data in the database by using type information in the tables to put things in the right context. Programs would end up in the program table, word processor documents would end up in the document table, and the system would know instantly what it's dealing with when it looks in a table, and if the database is set up correctly, most searches can be made very quickly and be more likely to return useful results.
OK, its a crazy idea that has the potential of being a hundred times more complicated than hierarchical file systems. Anyone else have any ideas?
Meldroc, Waster of Electrons
Considering that Raskin could be considered the father of the Apple Macintosh, I think it's a little unfair to say he hasn't done anything for making user interfaces beter.
I heartily recommend this book. Jef Raskin is a highly misunderstood HCI expert. I say that because about 6 months ago he got a lot of flames for criticizing Apple for continuing to make the mistakes which he preaches against inherent in the WIMP (windows, icons, mouse, pointer) interface. Raskin himself replied and tried to explain some things. He said that to understand him you had to read his book.
I bought the book soon after that, and as I read it, I was blown away. Sometimes when you read a book, it just gets into your head and it's all you can think about. That's how it was for me.
Unfortunately, although it describes many of the principles by which a Humane interface should be designed, there is not a design for a specific kind of interface. Perhaps it's because there is no one single right way to make an interface, but there are many wrong ways. Software producers continue to make the same mistakes about what they think is user-friendly (yes, including GNOME and KDE by following the WIMP example), but Raskin shows that many of the usual assumptions are wrong (pretty much everything we currently understand about user interfaces, e.g. "icons are user friendly").
After reading it, I felt that if I followed the principles of the book, I too could design a radically different yet vastly improved system for beginners and experts alike. I emailed Raskin with my thoughts. The response to the possibility that I could program such a thing was (paraphrased) "You will need a spec, which I am still working on."
I suppose I am still interested in making an interface with the principles outlined in the book, but I think it would require as much work as a GNOME or KDE project (including applications), perhaps even an entire new operating system, depending on how far you wanted to take it.
Jef Raskin's homepage is here. Be sure to check out the summary of The Humane Interface at least, if you aren't going to read the book.
so when i paint a new picture in real life, where do i put it? do i put it on the shelf in the den, or do i file it in the basement with my college art? real life models in many places where things need places to exist ... what computers may be able to do for us is improve/automate the process. hiding the fact that things go places may not actually help.
This is only moderately true even in the real world, and not at all true for computers.
If you paint one picture, you can put it one place. If you make ten prints of one lithograph, you can put them ten places, and none is intrinsically more important than the other. And what if you're a poet? You think of a poem, so it's filed in one place: your head. Then you teach it to a friend. And then you recite it at a public reading. Where is your poem "filed" now?
Computers are even worse. When I create an image with Photoshop, where is it filed? Well, in truth, it exists only as a bunch of variances in magnetic fields on a number of spots scattered across several metal plates inside one or more metal boxes inside my computer. Unless, of course, I'm using a network, in which case it's inside computers that I may not know the location of and may never see. That's the only "fact" about where it is. Hiding the fact that that things go places is more than helpful; it's vital. If I had to specify the exact physical locations of the components of my Photoshop file, it would be ridiculous.
That's not to say that making things work like they physical world is wrong. The metaphor of a desk, complete with a desktop, filing cabinets, folders, and so on made the Mac useful to a lot of people. But there's no need to stick with a metaphor past the point where it is useful.
The web is a great example of this. Thanks to Google, I rarely bookmark anything; I just search for it. And if I do remember something about the URL, I usually remember only the domain name, finding the actual document I'm after via navigation bars and search forms. Would it be possible to force this into a real-world metaphor, where each "thing" is in exactly one "place"? Sure. Would it be useful? Absolutely not.
Categories and subcategories map well to the real world. If I have only a few files (documents, whatever) they can be in one place. But if I have many, then I?ll want them to be organized somehow, and hierarchically makes a lot of sense for that.
That's nearly true. Categories and subcategories map well to a particular view of the world. But to make effective use of the hierarchy, you are forced to use that view of the world.
Take an example. Say I create an Excel spreadsheet for a 2002 budget projection for a project for one of my clients. What folder and subfolder do I put it in? The top level of the hierarchy could be my role (personal documents vs business documents); it could be the entity the document belongs to (the client's name); it could be the topic of the document (a budget); the period it covers (2002); the type of document (a spreadsheet); the application used to create it (Excel); the date it was created (2001-05-17); or the name of the project. Or something else entirely.
So which is my top-level folder and which are subfolders? It depends on which I consider most "important" or "intuitive", which varies from person to person and from day to day. Heck, if you grew up with Windows you may believe the best place for an Excel document is in the C:\Program Files\Excel directory. I know secretaries who keep all their files right in with the program files because they never learned to make or change directories.
I haven't read Raskin's book yet, but when I dream of better ways to do this, I imagine history lists, search boxes, and hierarchies with multiple roots and automatic filing of documents based on things like name, date, creator, type, and keywords and categories chosen by the author. So when I'm looking for that budget projection, I can browse based on any of those criteria I mentioned above.
http://www.brainfingers.com/technical.htm
Myabe the author of the book can work on an offspin of this product.
Want Root?
The obvious alternative to a fixed category system is arbitrary search criteria.
"Computer, give me the document I was working on last week about Genghis Khan."
"Computer? Didn't I once write something that compared Bill Gates to a hibernating wombat?"
... and so on. The computer can retrieve your document based on any criteria you like, not just the one (or, counting symlinks, the several) you happened to file it under.
With the exception of the universal undo, it sounds a lot like the interface for the Palm OS. No filesystem, the same widgets do the same thing, keep it extremely simple. In short, it's simply obvious what to do as soon as you turn the thing on the first time.
the most inhumane interface ever designed, complete with MDI 'window within a window' and toolbars that so aggressively attempt to dock with other stuff that it is impossible to get any work done. I wouldn't trust an ex-microsoft employee (save Tog, who criticizes them frequently) as far as I could throw them when it comes to any interface design issue. And yes, this does go for M$ programmers who now work at Ximian.
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.Is it "human interface" or "humane interface"? They mean very different things.
-no broken link
The original Mac had a reasonable, but limited, approach to system administration:
This was limited, but explainable. No "Registry" or "System environment variable" crap.
We need a theoretical basis for system admnistration. And the Linux crowd will never get it right.
If anyone on slashdot hasn't read this, they probably should:
In the beginning was the command line:i nning_print.html
http://www-classic.be.com/users/cryptonomicon/beg
It's an interesting look at computers and their users. It goes along with what you say, in general, and elaborates on your statements even more.
So we alnaturally just plain suck.
Man that sucks
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
I liked the book a lot because it focused a lot on making the human machine interface more efficient. I pretty much hate gui's that force you to jump through umpteen dialogs to configure something that should take 5 or 6 key strokes and Raskin seems to understand this.
I even had my wife a non-programmer read the section on modalism, which has greatly enhanced her ability to turn on the TV and actually play the TiVo or DVD successfully without calling me.
After reading the book I am even more rabid about my adoration of ViM
One problem ... in the book he talks a lot about products like this Canon word processor that didn't seem like commercial successes. They may have been "humane" or even efficient, but no one bought them. What good is that?
I don't know how extreme he is on this point, but my sense is he takes it too far. Modes in some form are integral to our interactions with machines, people, and the world.
If we forbid modes, a TV remote control must have an on button and an off button. Nobody wants this, because it's much harder to remember which button is which, than it is to observe that the TV is off and deduce that the button will thus turn it on.
The system should always react in the same way to a command.
Very few things in the real world always react the same way to the same command. You don't behave the same way in the library as you would at a friend's home. Your car responds much better to the gas pedal when it's in drive than in neutral. You read people's moods before deciding how to communicate with them.
People can observe and remember a certain amount of context, and tune their behaviors accordingly. It's frequently convenient to enter a mode, because you can forget about everything not appropriate to that mode. This is just as applicable to computers as to the real world--when we perform different activities, we enter different mindsets and adopt different expectations. Computer interfaces should take advantage of this human capability (with appropriate restraint, of course).
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
..of course "Unix" backwards is "Xinu", which is awfully close to "Xenu", super being. Ask your local Scientologist if you're not sure.
The Master Of Muppets,
The Master Of Muppets,
CAPTAIN: TAKE OFF EVERY "SIG"!!
IMHO MacOS X is the best of both worlds -- bulletproof and powerful underpinnings covered with a cutesy interface. That way it can be as simple or as powerful as you need it.
(And anyone who ridicules MacOS classic as hopelessly dumbed down should look into AppleScript -- scriptable applications are pretty common, and you can control them like marionettes. The only reason that Unix doesn't have that kind of fine-grained control is that Unix shell commands are (or were) pretty fine-grained themselves, but that's why we have sockets and SysV IPC...)
/Brian
Slashdot has discussed Raskin before with disappointing results.
Instead of trying to understand some of the concepts that may, at first, sound strange - his concepts are riduculed and flamed out of hand.
Flamethrowers grab a little bit of text, twist it - without trying to really comprehend, and proclaim Raskin an idiot. A shame because Raskin has some *very* good ideas that he generally supports quite well.
The only positive from what's going to be a large amount of flames is that Raskin should take some solace that all visionaries are subject to much abuse. Most people are unwilling to give up or reconsider what they think they "know" as truths, often to their own detriment.
Interestingly, this strange, awkward, stale moment pulled me out of the article long enough to cause me to forget what point the author was trying to make.
Let's rewrite a later sentence:
Maybe these rules for interface design apply equally well to good writing for a broad audience, or to attempts at "humor" in general.
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.
I wholeheartedly disagree. I like to have multiple ways to do things. I try them all and figure out the one that suits me best, then make it a habit.
Someone else's idea of "the most natural way to do x" often times isn't mine. I guess that's why I always set custom keys in games, use emacs, and think PERL is fun to hack around with.
The general idea is good (especially global undo/redo! Imagine being able to undo the last time you stupidly walked right in front of a rocket!).. I see some problems with it though.. :P..
firstly, not all applications can use the same interface. Period. Can you imagine trying to play Quake using a MS word (or emacs.. or vi.. or pretty much anything not remotely related to 3d navigation) interface? Or for that matter, trying to type out that document the boss wants in 20 minutes if you have to use a mouse/keyboard combination to pick letters from your latest Quake/text editor mix?.. it just cant be done.. its like trying to create a car using the "interface" of a pair of rollerskates.
secondly.. modes.. I agree that modes can be a pain in the @$$ (especially when Word decides to change modes for you when you dont want it to).. but really.. how are you going to get around this?.. if you want to allow bold/italic/underscored/different font/etc text, you need some way of specifying what you want. You obviously cant have an enormous keyboard with a set of keys for bold, another set for italic, etc (not to mention that that would likely be more confusing and distracting than accidentally bolding some text).. that leaves basically two options.. dont allow bold (unlikely), or have the text editor do it all for you.. and we've all seen that THAT doesnt work very well these days.. (maybe when they get direct-brain-control working and we can just think it the way we want:)
thirdly is legal.. MS has already attempted to meld things together, and found themselves slapped with a nice big antitrust lawsuit (not that I dont agree with that, but the point is there).. so we know this cant be done within one company (at least, not one that has any reasonable sized portion of the market share, and smaller companies dont have the funds for the R&D needed I'd guess).. open source/free software might be able to have a go at it here, but I doubt anyone would bother on any sort of large scale
oh.. and about that bit about removing the file structures and stuff from the user view.. uhmm.. no.. a user might not care if the extension is ".rtf" or ".doc", but they DO care where their files are put.. having a billion files in the same place is NOT cool.. thats why we invented directories and libraries and whatnot in the first place! organization!
I wonder how this work when you are attempting to make GUI's accesible. Its very hard to provide this sort of utility for visually impared people, as speech synthesis only comes one bit at a time. You can not listen in parallel.
"That is one of the downsides of the otherwise efficient command line interface"
Unless you hit tab of course.
Phil
BTW, who said that originally?
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
Raskin has some curmudgeon in him. Just read this page on what Raskin thinks we should do with the word "intuitive".
Unlike Tog, who seems to think that anything the Mac interface does is The Right Way To Do It, Raskin appears to receive some influence from actually experimentation.
On the other hand, going hard-over against modal interfaces seems a little odd. As far as I know, only one study has ever been done on this sort of thing: "A Comparative Study of Moded and Modeless Text Editing by Experienced Editor Users", by Poller, M.F., Garter, S.K., appearing in Proceedings of CHI '83, pp 166-170.
One interesting conclusion from that study:
I haven't read the book, of course, but interface designers almost always have to take advantage of modality. Even in the "simple" case of driving an automobile, the accelerator has a "modal" effect on the behavior of the vehicle, depending on which gear is selected. In computer interface design, the most fundamentally modal input device is the keyboard. In a windowing system, it has dramatically different effects depending on which window is selected.
The important item to keep in mind is the number of modalities and the complexity of their interactions. Keeping modalities obvious and intuitive will keep most users out of trouble. (e.g. a tiny little "Ovwrt" isn't always an obvious indicator that you've left Insert mode). Then all you have to do is figure out what's "intuitive" for your users :-)
What do you mean they cut the power? How can they cut the power, man? They're animals!
It's good to see a frwsh perspective on this issue. I'm tired of reading stodgy texts from 30 years ago about how it would be a great advance to use a 'mouse'.
Over the past 20 years though, interface design has been pretty much dictated by OS vendors such as Apple and Microsoft. This trend is going full circle with the proliferation of applications to which various 'skins' can be applied, producing an entirely new look. This trend has appeared, I believe as a direct result of the advent of dynamic layout methodologies similar to HTML. Let's all remember it wasn't always so.
Apple was the first to implement draconian interface specifications for 3rd party applications (since 1984). Microsoft has generally left it more to the compiler vendors, although all design seemed to sprout from Microsoft anyway...
It's thrilled to see new thought in this vary important area of the field.
--CTH
--
--Got Lists? | Top 95 Star Wars Line
...is "The Inmates are Running the Asylum" by Alan Cooper, ISBN 0672316498. You can probably find it cheap, too... got my copy at Borders for about $4.00, hardcover even.
...who said that "Unix is backards" (or is at least alleged to have said that. I think it would not be a surprise that he takes issue with a lot of Unix truisms...
I cannot help thinking that the author is using the same logic that brought us the language Esperanto. (One way to do it, complete consistency, very few rules, etc.) I think the problem is that humans themselves are not really that way.
I suppose it is a criticism of the English language, just as it is of, say, Perl, that in different contexts the same word means different things. Many might argue that this is not a defect and that people intuitively use English despite all its modes because they are so well practiced in it.
This is not to say that computers should not be designed to be easier, merely that there is perhaps some utility in having different programs function differently. And even having one program respond differently to the same input at different times. For instance vi and emacs (and other programs for editing code) respond differently to a carriage return depending on the situation, by tabbing to a different point in the following line. Though I could disable this feature, I do not since it is so useful.
You know, I hate using paper and pencil. It's so modal. If I want to erase something, I have to either turn my pencil upside down, or drop the pencil and grab an eraser. Oh, and painting is even worse! I constantly have to change modes by changing instruments. Why can't my palette knife do everything?
The lesson here is don't give users everything they think they want. In my experience, users don't even really know what they want. For applications, etc., focus on use cases: how people want to use the system. Design the interface to make those cases easy to do. Basically, goal oriented interfaces (which is what that VB guy who wrote Inmates Running the Asylum is a big fan of). Unfortunately, Microsoft took his ideas and created "wizards" which are the most useless goal-oriented interfaces I've ever had to use.
Even for hardware, like VCR's, focusing on how users want to use the system would make more effecient interfaces. Users really just want to say, "Record 'Manimal' at 8 o'clock on NBC" and have their VCR know what the heck they are talking about. They don't want to go into their TV Guide and type in numbers to a VCR+. Another option is the way I think TiVO does it where you can have an on-line list of programs, you select the program you want and indicate you want to record it. It's better than working through an on-screen interface to try to tell the VCR what time to start and stop recording.
Another example of goal-oriented interface is the Wacom Intuos digitizing tablets. You can get three extra pens, each withs it own unique digital id, and an airbrush pen (which looks and feels like an airbrush). Each pen can then be assigned a unique function in Photoshop (or other app). This way, the mode becomes obvious as picking up a different pen or picking up the airbrush tool. The tablet knows you've chosen the airbrush tool, so it automatically changes to airbrushing. You take the first pen, and it knows you want to draw. You change your mind, turn the pen around to the "eraser" on the end, and voila you're erasing. This is an intuitive mode change that I think is far more useful than trying to make a modeless interface.
The point here is the interfaces must be engineered towards what people want to do with it, and that you behave in a consistent way. For example, if you have modes, then make sure that there is a standard way in each mode to get out of it (like the ESCAPE key). Users can learn arbitrary interfaces, as long as they are consistent and geared to helping them do what they want to do.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
You request data through abstract queries like "what was that cartoon I was looking at one evening about Windows 95?", or "get me everything about the Wilson project".
Unfortunately it would require strong AI to achieve.
Yep, and in the box it says: "Title: The Human Interface".
The nice thing about standards is that there are so many to choose from. - ast
How would one organize files? Ok, say you don't have "files" but just documents. Is the device only good for editing one at a time? Or is he suggesting a replacement by a more random-access structure, so that you need to give it keywords to find the file you're looking for?
Categories and subcategories map well to the real world. If I have only a few files (documents, whatever) they can be in one place. But if I have many, then I'll want them to be organized somehow, and hierarchically makes a lot of sense for that.
My fear is that he's advocating a "sufficiently advanced technology" interface that somehow magically finds the file that you want based on your limited, possibly ambiguous query. If anyone has read the book and knows more specifically what he's advocating, please reply to this.
Tim
Some random thoughts in the spirit of this discussion: We often judge user interfaces by their feature sets. More features mean more power, and are better, right? I think not. I actually want my software to have a minimal feature set which is maximally robust.
The idea behind building feature-rich software runs something like this: figure out what a program will generally be used for, and come up with a set of tasks -- use cases -- which are representative of what the majority of users will want to do with the software. Design the software around the use cases, using the ease and efficiency of each of the use cases as a yardstick for the program's success. If users demand more features, the market for the software expands, or the company simply has more resources to build up the software, then add more use cases and repeat.
This works reasonably well, but it has a serious flaw: as the amount of functionality and thus the number of use cases go to infinity, the number of features goes to infinity. Think of M$ Word -- at a certain point, the wizard that will make multi-column address labels is useless to me, because there are so many damned wizards I don't know where to find it.
What software really should try to do is maximize robustness while minimizing the feature set that achieves that functionality. If you want your software to achieve a wider base of functionality, you have to make your interface's features more generalized, and more expressive. As the amount of functionality goes to infinity, the feature set stays bounded, and just approaches some sort of Turing-complete programming language.
So when designing software, don't ask "What features should we add?" Ask "What functionality can we add, and what features can we generalize in the hope of removing others?"
I realize that this is all very idealistic, but it seems like a guiding principle that could keep software bloat in check.
There is certainly a glut of command-line tools, though. The problem with the 1000 UN*X apps is that
But I suppose this happy mess is really in the nature of a sort of the Darwinian free-for-all of UN*X.
I'd really like to see a shell built on a single powerful set of list and pure function operations that would neatly generalize pipes, redirects, backquotes and lots of command-specific features into a single, more general scheme. It's silly that I have to know about the output format of ps to kill all processes with some specific thing in the command line:
kill `ps -ef | grep nuj | cut -c9-15`
I should really be able to say something like:
kill (ps ? (#.cmd==nuj)).pid
...where ps just outputs some list of named hashes, and I don't have to play ASCII games or know anything about the format of its output.
-END OF PONTIFICATION-
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.
I don't see anything controversial about that. There were several systems that mostly behaved that way before the Macintosh. The idea was to eventually move towards a system with persistent object store and direct manipulation of objects, eliminating the need for applications and allowing easy reuse among applications. Generally, the way that was implemented at the time (early 1980's) was via "workspaces" in which all data and objects lived, together with implementations in safe languages that allowed code to co-exist in a single address space.
What killed this approach was, in fact, the Macintosh, later copied by Microsoft. Using Pascal and later C++ as its language made it very difficult for "applications" to safely coexist or to share data in memory. The Macintosh and Windows merely put a pretty face on a DOS-like system of files and applications.
I'd still recommend reading Raskin's book. It does have historical significance, and it gives you a good idea of what mainstream thinking in UI design is. Raskin himself, of course, has contributed significantly to the state of the art and the body of knowledge he describes. There are some ideas in there that are probably not so widely known and that may be helpful.
But don't turn off your brain while reading it and don't take it as ghospel truth. UI design is not a science, and many of the connections to experimental results are tenuous at best. And a lot more goes into making a UI successful than how quickly a user can hit a button. If anybody really knew how to design a UI that is significantly better in practice than what we have, it would be obvious from their development of highly distinctive, novel systems and applications.
Computer interfaces really haven't changed in at least the last ten years. They have gotten prettier, maybe faster, but there has been no fundamental change in all that time. In fact, as far as I can see they have only changed twice in computing history (Let me know if I am wrong, lord knows I am not omniscient). The changed from simple printouts/registers to character based interfaces then from character based interfaces to our present GUI interfaces.
I can't see this lack of change as a good thing. In an industry where rapid change is standard it surprises me that interfaces have remained stagnant. So if this book can foster some original thinking and perhaps some newer more efficient designs for interfaces, we should probably take it seriously, not matter how controversial the content.
As always just my 2cI'm a programmer, I don't have to spell correctly; I just have to spell consistently
..until you read the book.
I personally just purchased this little ditty at Border's not four nights ago, and flew through it. What Raskin does, and why, in the end, you can not help but agree with him, is to walk up to each concept he presents clearly, and explain that why, yes, UI designers often think this way, I think they are forgetting x and y, and thinking of z. Very similar to Aquinus's theolgica in voice.
What he points out, quite poignantly, is that engineers design the interfaces, not people. We engineers are a different breed, and, when creating our interactions, we tend more towards Neal Stephenson's essay "In The Beginning..", where every intimate interaction with machine, as well as each step in the process, should be visible to us.
However, as Raskin states, this is rarely transfered into an interface that makes it's current state obvious to it's user, and instead, engineers often assume the user a vast idiot.
Unlike Tog, who claims to be the definitive source of interfaces, Raskin admits that his ideas are difficult to actually place in an interface, and instead, seems to prefer the book be used as a guideline for meeting halfway.
Raskin also explains in very simple terms, just how the human mind is thought to work, and that if these fundamental are true, then why would working with a computer feel like x, when, in review, it should be z.
For instance, perhaps the most harped upon item in the work is the idea of modes. What Raskin believes is that the human brain takes 10 seconds to switch gears between two tasks, and that modes actually slow a user down. He seems to believe there should only be one mode, 'edit', giving the user complete control of all aspects of the document at any time. Most UI people believe modes save users from themselves, allowing certain changes to a document only when in mode x, and you have to click 'Ok' to enter. However, Raskin solves this argument by simply calling for the Universal Undo/Redo button ( as found on the Canon Cat), the inability to delete anything permanently, and automatic saving of documents.
One of the more intricate ideas, and one everyone seems to wonder about is the Raskin's idea to remove file-heirarchies.Here's how Raskin believes it should work; One, within a machine there are only documents. The system itself is invisible to the user. You don't launch applications, or move around system extensions, you just work. With this removed, you then look upon hard drives as actually an infinitely long scroll, where documents simple begin to occupy blocks of space, and can grow within their space indefinetly. While Raskin never explain exactly how this will work with hard drives that become radically more crammed, I don't think it was ever his intention to explain exactly how to do anything.
What many reviewers miss is Raskin's assertion that his ideas, the sum of this book, are just that, ideas, and guidelines. Bascially the book is a statement of 'In an Ideal world, this world happen.' However, he does provide several methods for testing current interfaces, as well as examing ways to improve them now.
I recommend it as shelf-material for anyone who works day-to-day in UI. At it's best, the book is a profound guide for the ideal that computers, or any device for that matter, should be less-complicated, more thought-out structures.