Slashdot Mirror

Reader Torulf contributed the below review of Jef Raskin's The Humane Interface .Though the book does not spend much time on Open Source software, it emphasizes ideas that every programmer probably ought to bear in mind -- at least if they wants hisprograms to have users. (And yes, he takes explicit exception to some UNIX truisms.)

The Human Interface: New Directions for Interface Design author Jef Raskin pages 233 publisher Addison-Wesley rating 9 reviewer Torulf Jernstr�m ISBN 0-201-37937-6 summary A thought-provoking book on how to design user interfaces.

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.

Conclusions

The 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.

Madsen submitted this as an Ask Slashdot, and its been weighing on my mind recently. I want a new keyboard- my wrists just aren't what they used to be after 16 hours of replying to flame mail. I'm curious what ergo keyboards people have tried. What ones they like. What ones will make my wrists last longer. And ideally, where I can find them and how much its gonna set me back.

Michael Eilers has written a sort of introduction to Beowulf, what it does, what it doesn't do, and why we should care. It really is a sort of quickie distributed computing FAQ that many of you might enjoy. So hit the link below and find out. The following is a feature by Slashdot Reader Michael Eilers Beowulf beyond the Hype A Quickstart to the Beowulf Concept During the last weeks the Beowulf project got a lot of attention in the PC press and even on Slashdot. With Red Hat's Extreme Linux CD the relevant mailing lists show an increasing number of newbie questions. Unfortunately the informat ion Red Hat provides on their Extreme Linux web pages is less than informative and full of hype. This may result in disappointed users. It seems appropriate to make some comments an hardware and software and give some guidance for the v ery beginner.

The name Beowulf stems from an old English tale and was the name of the first e xample of this class of computers. In fact a Beowulf is nothing else as a local computer network. You might say I have a small network in my flat (f.e. an old 486 connected to my newer machine), do I have a Beowulf? The answer is yes. Yo u do own already the hardware to start. Even if your connection is via PLIP/SLI P you can call your construction a Beowulf as soon as ping is successf ul. Forget all the hype about expensive special networking stuff like switches, Myrinet or SCI. For some tasks it is helpful but others won't benefit. A 10/10 0Mb connection seems to be sufficient for serious starting.

A Beowulf is not a solution for all of your speed problems. Building a Beowulf has not the same effect as f.e. the increasing of clock speed. With a Beowulf y ou won't see a speedup of your daily software and the class of software that is already adopted to Beowulfs can have very different speedups.

The hardware part is nothing more than connecting PCs with standard networking hardware. The main idea is to make your PCs to talk to each other. The most com mon solution is message passing. There are two main ways for doing message pass ing: PVM and MPI. The decision between them is mainly a matter of taste (see here for a comparing paper). I will foc us on PVM but keep in mind that MPI is as good. You can get that stuff here. The pvm3.x.x.tar.gz package has a long history and is rock solid stuff. Sinc e 1993 I did install it on half a dozen unices and never met a major problem. A fter unpacking and compiling play around (yes there is a "hello world" example) . After playing with the examples. You will see that the main commands are pvm_ send and pvm_receive and If you think that you do understand the examples start your own programming If you know what matrix multiplication is, try to impleme nt a parallel version. This is an instructive example. If you have problems you may ask for a debugging utility. Try to get xpvm-1.2.5.tar.gz from the above U RL. Its not a debugger but it visualises the behaviour of your parallel code. T he whole thing may take you two or three evenings. After that you know the basi cs of the Beowulf concept of making a pile of PCs looking as one machine.

Now you may have some questions:

Q: Sounds interesting, but I don't have a network at home. What can I do?
A: You have a network (the loopback device) in your Linux box. This means that you can install PVM/MPI and play with it. Of course you won't see a speedup. :-(

Q: I have access to a computer pool but I'm only a common user.
A: You don't have to be "root". You can install PVM/MPI as a normal user and tr ansform this pool in your personal Beowulf.

Q: I'm not a C programmer, but I use [Perl|Tcl|Python]?
A: There are interfaces available at the PVM home page (MPI??).

Q: Im not a programmer. Are there interesting applications?
A: Im sure there are plenty of applications that exploit the power of Beowulfs. Most of the stuff lives in academic environment and this means that availabilit y and quality differs. I use f.e. GAMESS a quantum chemistry program that uses MPI. Maybe one appl ication need's to be specially mentioned. There are two Beowulf-ready patches f or the famous POVray ray-tracing program. PV MPOV is more flexible but less robust and FLY3 is robust but a little inflexible. If you use POVray very o ften and play with the idea of buying a PII[34]00 MHz you may rethink this idea if you checked the povbench res ults at The fastest rendering was done with a messa ge passing version of povray.

Q: If you state that building and using of Beowulfs is that easy why aren't the re more Beowulfs?
A: I don't know why there aren't more, but I think this situation will change.

Q: I'm a little confused about the many packages that allows computing of Beowu lfs?
A: Indeed there is a whole zoo of packages for programming networked workstatio ns. For a first attempt you don't need them but some of them solve special prob lems. For an overview about the important ones check out the "Linux Parallel Pr ocessing HOWTO" by Hank Dietz.

Q: Is there a PVM/MPI version for Windows95?
A: Yes there are Win32 versions of PVM and MPI, but who cares. In fact every (pseudo)multitasking operating system with network support can in principal be used to build a Beowulf (f.e. there is Win 3.x port for PVM).

Q: Where can I get more Information?
A: As you may have seen from the above the message passing part is the stuff th at is tricky. You find links to books and tutorial for parallel programming on the PVM/MPI home pages. Hardware related information at introductory level you will find in the "Beowulf HOWTO" by Jacek Radajewski and Doug Eadline. A comprehensive overv iew on hardware and software in the "Linux Parallel Programming HOWTO" by Hank Dietz.

Q: Do I need the Beowulf software packages from the Beowulf project at NASA?
A: If you use Linux, then you probably use one of the network driver developed by Donald Becker. So the Beowulf project is already at your home and in this se nse necessary. The rest of NASA's Beowulf software provided for the use with cl usters helps you to manage a large cluster but it's not necessary and probably not the first step to do and beyond the scope of a quickstart. Even the suits a t NASA have realized that Beowulfs are a powerful tool, but the shutdown of the Beowulf web pages is like preventing the production of cars by closing a horn factory.

Q: If you can connect local PC's to look as one computer, why not coupling comp uters via Internet to a supercomputer?
A: Standard message passing software uses communication protocols that are very sensitive to packet loss. But there are activities in this area. Look for the keywords "metacomputing" or "hypercomputing".

Michael Eilers

Patrik R}dman INF wrote in to tell us that a New Version of Wine has hit the net. Grab it if you're into that sorta thing. I'm waiting until I can emulate Diablo personally. My guess is it'll be awhile before we have DirectX though *smile*