Jef Raskin's Humane Interface
I finally finished Jef Raskin's book "The Humane Interface" and have promised enough people comments that I figured I'd just write a review - and livejournal turns out to be the most convenient place for me to put it up and get feedback, so here it is.
Jef Raskin's name has come up numerous times over the years, as a user interface design god - but as with many gods, he seemed distant and incomprehensible. I finally saw him speak (and demo) at EuroPython 2004, when he was opposite a talk that ended early (fame is not in and of itself attractive, at a technical conference) and discovered that he fits a pattern that I've found worth of attention before - "Everything you know about [topic] is wrong, here's what you get if you examine it rigorously instead of believing the folklore". Examples include Measured capacity of an Ethernet: myths and reality (Boggs, Mogul, Kent) (notable for debunking early myths about ethernet having a maximum capacity of 1/3 the wire-bandwidth) and ON FOOD AND COOKING by Harold McGee (notable for the definitive explanation of copper bowls and egg whites, with confirming evidence from a spectrophotometer.) He also turns out to be very clear and concrete with his examples; the book follows the same pattern.
It is definitely a book to read for anyone designing a workflow - especially if you have the opportunity to escape "modern" application toolkits. If you are stuck using rich standard libraries, you may want to avoid this book, as it will bring you moments of enlightenment that come crashing down when you try to fit them into the metaphors current systems have stumbled upon. Also, if you've ever thought "if only my work tools had interfaces as slick as this video game", this book is for you.
I'd treat the book as having three major parts. The first part is a broad collection of tools - individual piecewise-convincing principles, with evidence and experimental rigor to back them up. Many of these can be applied to conventional interfaces - or at very least can be used to choose among conventional interface components on the basis of actual user effort, instead of guesswork. The second part is about how the Canon Cat applied many of these principles in a single interface, and where one could take them using modern hardware (which he and his son are currently working on, in Python.) The final part goes off in a different direction, the Zooming Interface model - this manages to be far less convincing, having underpinnings only in some vague (and unfootnoted) concepts of spatial memory, which are presented only anecdotally and not strongly tied to the tools of the first part. It's still a fascinating concept, but it is hard to reconcile with earlier discussion of better ways to handle documents - and that clash makes it look somewhat "off the deep end", especially to a skeptical reader who found the earlier material convincing.
One of the concrete tools is "GOMS analysis". This stands for "Goals, Operators, Methods, and Selection rules", a way of breaking down an activity or workflow into fundamental actions that represent the key costs or effort involved - such that one can then more easily compare two models, than having to extensively repeat the activities to get build up statistics. Comparing this model to my personal experience, it certainly gives solid ammo for a belief that "hot keyboard use" outpaces mouse use. It is also one of the underpinnings of the "LEAP" model used by the Canon Cat - it isn't "randomly different", it is actually a near-limit case of how one can push the model.
I found that not only did this book have a reasonably solid "big picture", there were many "stunning" or startling examples - a few of which I've called out here.
Page 50: "To avoid a mode, the Canon Cat was designed without a power switch." This isn't out-of-the-blue, there's a detailed explanation of when modes are harmful - and the simplicity this provides is startling. (After all, you don't have to turn on a pad of paper either [my analogy, not his - Raskin's model is all about "locus of attention" and the ways in which modes lead to error.]
Page 31 (section 2-3-6) is entitled "Resumption of Interrupted Work" and is all about a problem I've put some effort into solving - having to log in and run my applications again. The idea that you probably want to continue what you were doing before is straightforward, in that "yeah, why *doesn't* everything work that way" sense. The problem is that I've put together a bunch of ad-hoc tools (monitor_safari for example) for things that should really be built in.
Page 10, footnote 1: "for example, nearly all carpal tunnel injuries are due to mouse, not keyboard, usage (Anderson et al., 2003)" - the full reference turns out to be JAMA 289:22 p. 2963 (2003), "Computer Use and Carpal Tunnel Syndrome: A 1-year follow-up study". Specifically, "In the cross-sectional comparisons and in the follow-up analyses, there was an association between use of a mouse device for more than 20 h/wk and risk of possible CTS but no statistically significant association with keyboard use." Of course, I've always objected to the mouse from a workflow interruption basis (and Raskin quantifies that, with measures for "homing" on the device) but it is encouraging to see some solid numbers on why it really is a bad idea.
Page 60, about the advantages of "noun-verb paradigm" in everything except for the most direct palette selections (where verb-noun is still error inducing, but other benefits outweigh that) led me to the realization that this was the difference between most Unix command line interactions with files, and emacs "dired" mode.
Page 119: "The content of a text file is its own best name." What he describes fits in fairly well with both the Apple and Microsoft indexed filesystems, I'm not sure if it actually predates them, but it gives a hint that maybe not everything is going in an entirely wrong direction...
Page 126: Incremental search (vs. delimited "dialog box" search) is "just better", but many toolkits make it hard to implement - VB and JavaScript are mentioned explicitly, though bitflux recently figured out how to do it in JS too, given server backend support to actually do the searching. A few pages later, Raskin analyzes Emacs' isearch - pointing out that it should leave the cursor at the start of target, not end, because that's more predictable and useful (compared to stopping at whatever character happens to be the one upon which you reached the result.) It may be worth experimenting with that modification; most of isearch is in elisp, and should be tweakable.
Page 141, as part of discussion the flaw of applications, quotes a PARC researcher as pointing out that windows *are* modes, another "obvious insight".
Chapter 6 is mostly about a "Zooming" interface, which brings to mind some of what I've seen demoed with Croquet (and Squeak), not surprising given Alan Kay's influence there. It seems to be all about leveraging locational intuition. I get the sense the the Mac Exposé interface is based very loosely on the same ideas, but fails to actually achieve them. A footnote does reference an actual example, Pad++, so these ideas seem to have a number of concrete instantiations to explore. It isn't until Page 164 (after working through "Apricus", a hospital chart application with zooming) that Raskin points out that this kind of environment "can replace the browser, the desktop metaphor, and the traditional operating system." Many would consider this point off the deep end, but he has supported it all along, and one is compelled to consider the possibility, since there isn't a particular point of going off the rails - text-oriented users will certainly quail at such an even more "graphical" environment.
Page 170 goes into why Icons are worse than active text buttons - they're smaller (Fitt's Law) targets, and they often need explanation - citing user reaction to mouseover-labels as "So why not just use the labels directly?" (I've switched a few of the Mac apps I use regularly to that mode, to see what it feels like...)
One issue with the LEAP approach that concerns me is that finding things (documents, interface elements) is just searching. What causes priority, or rather prevents "pollution" of the command namespace?
Little clevernesses: p. 185: autorepeat on third-key-hold down; p. 186: overstriking for accents - instead of the somewhat goofy mac approach, simply using e-down '-down '-up e-up should enter é cleanly. I could implement this in my captioning tool easily enough, since it uses PyGame and gets key events directly.
Page 194, 7-1-2, interface issues in software development: "the cognitive unconscious can sustain contradictions" - therefore heavy advance commenting is good because it brings such potential contradictions into the conscious space...
Page 203 - references Tufte (yay!) and suggests that a lot could be done to improve the efficiency of modern interfaces simply by displaying more data.
Jef Raskin's name has come up numerous times over the years, as a user interface design god - but as with many gods, he seemed distant and incomprehensible. I finally saw him speak (and demo) at EuroPython 2004, when he was opposite a talk that ended early (fame is not in and of itself attractive, at a technical conference) and discovered that he fits a pattern that I've found worth of attention before - "Everything you know about [topic] is wrong, here's what you get if you examine it rigorously instead of believing the folklore". Examples include Measured capacity of an Ethernet: myths and reality (Boggs, Mogul, Kent) (notable for debunking early myths about ethernet having a maximum capacity of 1/3 the wire-bandwidth) and ON FOOD AND COOKING by Harold McGee (notable for the definitive explanation of copper bowls and egg whites, with confirming evidence from a spectrophotometer.) He also turns out to be very clear and concrete with his examples; the book follows the same pattern.
It is definitely a book to read for anyone designing a workflow - especially if you have the opportunity to escape "modern" application toolkits. If you are stuck using rich standard libraries, you may want to avoid this book, as it will bring you moments of enlightenment that come crashing down when you try to fit them into the metaphors current systems have stumbled upon. Also, if you've ever thought "if only my work tools had interfaces as slick as this video game", this book is for you.
I'd treat the book as having three major parts. The first part is a broad collection of tools - individual piecewise-convincing principles, with evidence and experimental rigor to back them up. Many of these can be applied to conventional interfaces - or at very least can be used to choose among conventional interface components on the basis of actual user effort, instead of guesswork. The second part is about how the Canon Cat applied many of these principles in a single interface, and where one could take them using modern hardware (which he and his son are currently working on, in Python.) The final part goes off in a different direction, the Zooming Interface model - this manages to be far less convincing, having underpinnings only in some vague (and unfootnoted) concepts of spatial memory, which are presented only anecdotally and not strongly tied to the tools of the first part. It's still a fascinating concept, but it is hard to reconcile with earlier discussion of better ways to handle documents - and that clash makes it look somewhat "off the deep end", especially to a skeptical reader who found the earlier material convincing.
One of the concrete tools is "GOMS analysis". This stands for "Goals, Operators, Methods, and Selection rules", a way of breaking down an activity or workflow into fundamental actions that represent the key costs or effort involved - such that one can then more easily compare two models, than having to extensively repeat the activities to get build up statistics. Comparing this model to my personal experience, it certainly gives solid ammo for a belief that "hot keyboard use" outpaces mouse use. It is also one of the underpinnings of the "LEAP" model used by the Canon Cat - it isn't "randomly different", it is actually a near-limit case of how one can push the model.
I found that not only did this book have a reasonably solid "big picture", there were many "stunning" or startling examples - a few of which I've called out here.
Page 50: "To avoid a mode, the Canon Cat was designed without a power switch." This isn't out-of-the-blue, there's a detailed explanation of when modes are harmful - and the simplicity this provides is startling. (After all, you don't have to turn on a pad of paper either [my analogy, not his - Raskin's model is all about "locus of attention" and the ways in which modes lead to error.]
Page 31 (section 2-3-6) is entitled "Resumption of Interrupted Work" and is all about a problem I've put some effort into solving - having to log in and run my applications again. The idea that you probably want to continue what you were doing before is straightforward, in that "yeah, why *doesn't* everything work that way" sense. The problem is that I've put together a bunch of ad-hoc tools (monitor_safari for example) for things that should really be built in.
Page 10, footnote 1: "for example, nearly all carpal tunnel injuries are due to mouse, not keyboard, usage (Anderson et al., 2003)" - the full reference turns out to be JAMA 289:22 p. 2963 (2003), "Computer Use and Carpal Tunnel Syndrome: A 1-year follow-up study". Specifically, "In the cross-sectional comparisons and in the follow-up analyses, there was an association between use of a mouse device for more than 20 h/wk and risk of possible CTS but no statistically significant association with keyboard use." Of course, I've always objected to the mouse from a workflow interruption basis (and Raskin quantifies that, with measures for "homing" on the device) but it is encouraging to see some solid numbers on why it really is a bad idea.
Page 60, about the advantages of "noun-verb paradigm" in everything except for the most direct palette selections (where verb-noun is still error inducing, but other benefits outweigh that) led me to the realization that this was the difference between most Unix command line interactions with files, and emacs "dired" mode.
Page 119: "The content of a text file is its own best name." What he describes fits in fairly well with both the Apple and Microsoft indexed filesystems, I'm not sure if it actually predates them, but it gives a hint that maybe not everything is going in an entirely wrong direction...
Page 126: Incremental search (vs. delimited "dialog box" search) is "just better", but many toolkits make it hard to implement - VB and JavaScript are mentioned explicitly, though bitflux recently figured out how to do it in JS too, given server backend support to actually do the searching. A few pages later, Raskin analyzes Emacs' isearch - pointing out that it should leave the cursor at the start of target, not end, because that's more predictable and useful (compared to stopping at whatever character happens to be the one upon which you reached the result.) It may be worth experimenting with that modification; most of isearch is in elisp, and should be tweakable.
Page 141, as part of discussion the flaw of applications, quotes a PARC researcher as pointing out that windows *are* modes, another "obvious insight".
Chapter 6 is mostly about a "Zooming" interface, which brings to mind some of what I've seen demoed with Croquet (and Squeak), not surprising given Alan Kay's influence there. It seems to be all about leveraging locational intuition. I get the sense the the Mac Exposé interface is based very loosely on the same ideas, but fails to actually achieve them. A footnote does reference an actual example, Pad++, so these ideas seem to have a number of concrete instantiations to explore. It isn't until Page 164 (after working through "Apricus", a hospital chart application with zooming) that Raskin points out that this kind of environment "can replace the browser, the desktop metaphor, and the traditional operating system." Many would consider this point off the deep end, but he has supported it all along, and one is compelled to consider the possibility, since there isn't a particular point of going off the rails - text-oriented users will certainly quail at such an even more "graphical" environment.
Page 170 goes into why Icons are worse than active text buttons - they're smaller (Fitt's Law) targets, and they often need explanation - citing user reaction to mouseover-labels as "So why not just use the labels directly?" (I've switched a few of the Mac apps I use regularly to that mode, to see what it feels like...)
One issue with the LEAP approach that concerns me is that finding things (documents, interface elements) is just searching. What causes priority, or rather prevents "pollution" of the command namespace?
Little clevernesses: p. 185: autorepeat on third-key-hold down; p. 186: overstriking for accents - instead of the somewhat goofy mac approach, simply using e-down '-down '-up e-up should enter é cleanly. I could implement this in my captioning tool easily enough, since it uses PyGame and gets key events directly.
Page 194, 7-1-2, interface issues in software development: "the cognitive unconscious can sustain contradictions" - therefore heavy advance commenting is good because it brings such potential contradictions into the conscious space...
Page 203 - references Tufte (yay!) and suggests that a lot could be done to improve the efficiency of modern interfaces simply by displaying more data.