Yep. While there are only a few techniques I would use unchanged, the book's philosophy has been very formative. The focus on allowing users to form habits has particularly stuck with me as a principle with important non-obvious results (e.g. no adaptive menus).
It’s also a principle that’s useful for resisting trend-based redesigns in SaaS products where users typically don’t have a choice of staying with the old design.
Most web apps are the polar opposite of Raskin’s principles: highly modal screen-based UIs with low information density (because the designer loves airy padding and big fonts), constantly getting tinkered and unintentionally preventing habit formation.
I was one of the early in-house reviewers of the book, and it absolutely changed my life.
One of the things that really struck me about it: the manuscript was written in double-spaced courier, with sketched out hand drawings. Coming from one of the designers of the Macintosh, the manuscript could have come from a Canon Cat.
And that was the Right Thing. The formatting would be done by professionals. (I learned that after I put in an enormous amount of work formatting my own manuscript.) He did the thing that got the job done, putting the words in my hands and the hands of those who would make it look nice.
The interface implemented a lot of ideas from The Humane Interface https://en.wikipedia.org/wiki/The_Humane_Interface One of those is to avoid "modes" where the same key does different things depending on context, because people are bad at tracking that kind of thing. So when modes are needed - like typing to search instead of entering text - it uses "semi-modes" that require holding a key down so you don't forget what mode you're in.
What made this easy to work with is you can easily hit escape and it will put you in edit mode and you can easily build muscle memory to do this quickly.
Not really. Vi has fewer modes than just about every word processor or editor in history. It has 3 core modes (2 major ones). Most word processors have countless more “modes” for even doing things like search and replace, and emacs has the mini buffer.
The vi design principal is that a limited number of modes used frequently is better than numerous specialized ones used leas frequently.
Any HCI dweeb that thinks 2 clearly visible modes is somehow inherently less usable than any alternative can fight me. And they’re full of shit on this in general. It’s not like they have the quality data to prove this, it’s always been something that has been taken for granted, avoid modes, just because there are a few examples (some catastrophic) of it being done poorly.
Edit: I mean really has anyone seen an experienced user use vi? You think from the HCI navel gazers that they would be half the time fumbling over what mode they’re in. Less talk, more observation.
Vi was 1976. The Canon Cat was 1987, and Raskin's work on the Macintosh was before it was launched in 1984.
This work was a _response_ to vi and modal editing.
And it was _right_ because it's how basically every GUI app and web app in the world works.
Sure, programs have functions that while you perform them put you in a special restricted environment, but it's not a mode. If there's a search-and-replace operation going on, you can see that on the screen. You can see if you're browsing menus or stepping through a tab bar or something.
In modal programs, it's the same program all the time, but in one mode, for instance, pressing ``dd`` types a double D like in "middle", and in another mode, it deletes the whole line, and unless you are experienced enough to look for a single character somewhere else on the screen, you don't know which it will do. You have to memorize the sequence of operations and know where you are. If I blindfold you, sit you in front of someone else's computer, take the blindfold off and ask you what "dd" will do at this point, you might not be able to tell.
And that is bad UI, and bad design, and we have learned better now.
The fact is that this is _proved_ by _every user-facing computer having a GUI.
> Sure, programs have functions that while you perform them put you in a special restricted environment, but it's not a mode. If there's a search-and-replace operation going on, you can see that on the screen.
That's how vi works, too. The 'i' command begins an insertion operation, wherein whatever you type after that command is inserted before the cursor. It's not a special mode, it's just how you provide input to that 'insertion' operation.
And the fact that the resulting program state and behavior is somewhat reminiscent of the "default" mode in other editors where all commands must be entered via menus or special keystrokes, etc. (e.g. emacs) is ultimately coincidental. That has nothing to do with the underlying principles of how 'vi' itself works.
The interesting thing to me is, that I don't feel vi and modern programs do things that much differently. In vi, Esc puts me in command mode, in any modern GUI Editor (at least on windows) Alt puts me in command mode (Jumps to the menu).
Yet, I seldom use the wrong mode accidentally on modern applications, yet constantly on vi. One part, as you said, is probably down to visibility, but a highlighted menu item could just as easily be overlooked. Maybe vi's main problem is the command mode as default? I always pondered if I would make as many mistakes (or would have found it quite so confusing as a new user) if edit mode was the default.
It’s a bit hilarious to look back on this keyboard with added application specific keys and wonder why they couldn’t have been replaced with keyboard shortcuts. I’m sure the state of “normal” UX as we know it today didn’t exist then, at least with respect to something as fundamental as the keyboard.
Back in those days, it was ordinary for application software to ship with cardboard over-the-keyboard templates showing the commands associated with key combinations. The user could swap them out between different applications.
Using key combinations for the operating system would have encroached on “application space.” Even today the standard keyboard has dedicated home, page down, delete, keys (etc.).
The cardboard overlay became less viable as bespoke keyboards were replaced by commodity designs with arbitrary key layouts and spacings.
The overlays generally encompassed only the top row of the keyboard (which is an island) right? So they indexed the top row and the row immediately below. At least those are the kind I remember and are easy to find on Google images. Or were there also larger/full keyboard overlays that made use of the other gutters between islands of keys?
Also, I remember these for the Model M keyboard layout. What other standard keyboard layouts were popular for the cardboard guides?
Since everyone followed the IBM keyboard layout, the templates fitted virtually every keyboard. Right now I'm typing on an Apple Extended keyboard from about 1987 and it has little pegs at top right and top left corners of the casing for the keyboard templates to hang on.
There were some F-key cardboard templates to fit over those keys, but they were less common -- partly because the original PC was so limited, maxing out at 640 kB of RAM and a 4.77MHz CPU, and not coming with a hard disk as standard, just 360 kB floppy drives, so that apps tended to be small and simple and not have very rich functionality to learn and remember.
I was recently looking at another site linked from HN which had dozens of split keyboard designs. One of the ones that I really liked was the Matias Ergopro, which has dedicated Cut/copy/paste/undo keys. That seems really convenient, made me wonder why more keyboards don't do this. Maybe it is a slippery slope, but those four shortcuts are so ubiquitous across so many pieces of software that I think it makes sense to have dedicated keys for them. As a Dvorak keyboard typist, the standard shortcuts become pretty annoying (no longer doable with one hand) so the thought of having a single key for those operations really appeals to me. But I would think it would also be something that would have caught on amongst the masses as well. I wonder, what percentage of computer users know the shortcuts for those operations, versus use menus or icons to perform copy and paste
Interesting point, I never think of the Dvorak people like yourself and I apologize for that :p Never really thought about how all the keyboard shortcuts the world accepted make zero sense outside of QWERTY
Honestly, copy/cut/paste in today’s world warrants physical keys far more than insert/print screen/etc. Maybe someone will decide to challenge that one day, but I’m sure people will have a million reasons why it can’t happen.
Everything is suboptimal for everyone and life goes on I guess lol
Funny to hear this, because I have that Matias keyboard and never ever use those dedicated undo/cut/copy/paste keys, because I feel there's no point retraining myself to get used to their placement (in a column on the far left of the board) when they're never going to be on my laptop keyboards too.
AFAIK those keys send the equivalent of the literal key chord (e.g. Cmd-Z) to the computer. I wish I could flip a switch and have them be considered keys in their own right, maybe F13-F16.
True.. at this point I have figured out how to remap the qwerty ctrl-c ctrl-v etc to work as cut paste under Dvorak so having dedicated keys might just involve too much retraining, so maybe it would not be worthwhile
By 1980, we had been through almost two decades of keyboard input - 10 years of the screen and keyboard. Using shortcuts was common, and without a mouse, required. Most "professional" keyboards came with some combination of ctrl, alt, meta, and option keys. The Cat came out at an interesting time. There was a ton of experimentation in the market - most people did not own a computer or know how to use them. The Cat is a very interesting take on easy to use and if you are into UX, reading through the built in help on the Cat is really interesting. http://www.canoncat.org/canoncat/onlinehelp.html
I was doing PC tech support in 1988-1992 -- the era when the PC world went from MS-DOS to Windows 3.0 to Windows 3.1. (And a few weirdos, like me, ran OS/2 2, because Linux wasn't ready yet.)
I used to support, for instance...
• WordStar (3/4, Express and 2000)
• WordPerfect
• Ashton-Tate MultiMate
• IBM DisplayWrite
• MS Word for DOS
... on almost a daily basis, plus lots more occasionally: LocoScript, VolksWriter, PC Write, Samna Executive, and more.
Every one had a totally different user interface. Every keystroke, every menu -- if it had menus; lots didn't -- every status bar, with no similarities.
There was one key -- one -- that almost everyone respected: F1 for Help. Except WordPerfect, where it was F3.
Then IBM introduced a standard called Common User Access, soon after the Mac started kicking IBM's backside in user-friendliness.
CUA mandated that all apps should have a menu bar, at the top of the screen. (Lotus 1-2-3 and MS apps put it at the bottom, before.) It should have options called:
File -- for loading and saving. (Previously, MS called this "Transfer". Lotus called it "Workspace". WordPerfect didn't call it anything but it was on F7, or Shift-F7, or Ctrl-F7, or Alt-F7, or Shift-Ctrl-F7 (etc) depending on what you wanted to do.
Edit -- for editing: cut, copy, paste, search, replace, etc.. (Mostly not even a menu before, just hotkeys.)
View -- for controlling viewing options: text mode, graphics mode, colour, show formatting codes, whatever.
And a bunch of others, but all had to be 1 word only, with a unique letter to open the menu with the Alt key.
The last had to be Help.
And so on. It mandated a standard, borrowing heavily from the Mac HCI guide to do it. And amazingly, it mostly caught on. MS followed it for Windows, mostly, and after Windows 3.0 DOS app vendors found it beneficial to make their clunky old DOS apps at least look and work vaguely like their Windows apps.
Ironically, MS itself had to change more than most. MS Word 3, 4 and 5 were nothing even vaguely like CUA. To load a file in them, you pressed Esc to open the menu (2 lines at the bottom of the screen), T for Transfer then L for Load.
After CUA, in Word 5.5 (a free download now, if you want to try it out -- works well under DOSemu in Linux), this was replaced by Alt-F for File, then O for Open.
I have never played with one, only studied the videos (e.g. https://youtu.be/o_TlE_U_X3c ) and documentation. It was a very radical UI. If you added programs, they just added new functionality to the existing editor. So, for instance, a spreadsheet module might mean that suddenly, when loaded, you can do operations like SUM{...} or MEAN{...} on a table of numbers in the editor.
I've long wished that someone would implement the Canon Cat UI as an Emacs module. It would seem to me that Emacs has all or most of the necessary functionality already.
31 comments
[ 1.8 ms ] story [ 80.9 ms ] thread(And by "see also" I mean "stop what you're doing, get a copy, and read it now.")
Most web apps are the polar opposite of Raskin’s principles: highly modal screen-based UIs with low information density (because the designer loves airy padding and big fonts), constantly getting tinkered and unintentionally preventing habit formation.
One of the things that really struck me about it: the manuscript was written in double-spaced courier, with sketched out hand drawings. Coming from one of the designers of the Macintosh, the manuscript could have come from a Canon Cat.
And that was the Right Thing. The formatting would be done by professionals. (I learned that after I put in an enormous amount of work formatting my own manuscript.) He did the thing that got the job done, putting the words in my hands and the hands of those who would make it look nice.
What made this easy to work with is you can easily hit escape and it will put you in edit mode and you can easily build muscle memory to do this quickly.
The vi design principal is that a limited number of modes used frequently is better than numerous specialized ones used leas frequently.
Any HCI dweeb that thinks 2 clearly visible modes is somehow inherently less usable than any alternative can fight me. And they’re full of shit on this in general. It’s not like they have the quality data to prove this, it’s always been something that has been taken for granted, avoid modes, just because there are a few examples (some catastrophic) of it being done poorly.
Edit: I mean really has anyone seen an experienced user use vi? You think from the HCI navel gazers that they would be half the time fumbling over what mode they’re in. Less talk, more observation.
This work was a _response_ to vi and modal editing.
And it was _right_ because it's how basically every GUI app and web app in the world works.
Sure, programs have functions that while you perform them put you in a special restricted environment, but it's not a mode. If there's a search-and-replace operation going on, you can see that on the screen. You can see if you're browsing menus or stepping through a tab bar or something.
In modal programs, it's the same program all the time, but in one mode, for instance, pressing ``dd`` types a double D like in "middle", and in another mode, it deletes the whole line, and unless you are experienced enough to look for a single character somewhere else on the screen, you don't know which it will do. You have to memorize the sequence of operations and know where you are. If I blindfold you, sit you in front of someone else's computer, take the blindfold off and ask you what "dd" will do at this point, you might not be able to tell.
And that is bad UI, and bad design, and we have learned better now.
The fact is that this is _proved_ by _every user-facing computer having a GUI.
Larry Tesler was right:
DON'T MODE ME IN.
Even his website is NOMODES.COM: http://nomodes.com/Larry_Tesler_Consulting/Home.html
That's how vi works, too. The 'i' command begins an insertion operation, wherein whatever you type after that command is inserted before the cursor. It's not a special mode, it's just how you provide input to that 'insertion' operation.
And the fact that the resulting program state and behavior is somewhat reminiscent of the "default" mode in other editors where all commands must be entered via menus or special keystrokes, etc. (e.g. emacs) is ultimately coincidental. That has nothing to do with the underlying principles of how 'vi' itself works.
Yet, I seldom use the wrong mode accidentally on modern applications, yet constantly on vi. One part, as you said, is probably down to visibility, but a highlighted menu item could just as easily be overlooked. Maybe vi's main problem is the command mode as default? I always pondered if I would make as many mistakes (or would have found it quite so confusing as a new user) if edit mode was the default.
Using key combinations for the operating system would have encroached on “application space.” Even today the standard keyboard has dedicated home, page down, delete, keys (etc.).
The cardboard overlay became less viable as bespoke keyboards were replaced by commodity designs with arbitrary key layouts and spacings.
Also, I remember these for the Model M keyboard layout. What other standard keyboard layouts were popular for the cardboard guides?
Before the Extended layout, the F-keys were in a vertical double row to the left of the QWERTY block, as shown here: https://deskthority.net/wiki/IBM_Personal_Computer_keyboard
There were some F-key cardboard templates to fit over those keys, but they were less common -- partly because the original PC was so limited, maxing out at 640 kB of RAM and a 4.77MHz CPU, and not coming with a hard disk as standard, just 360 kB floppy drives, so that apps tended to be small and simple and not have very rich functionality to learn and remember.
But 3rd parties made ones you could stick on, e.g. https://imgur.com/gallery/pwNQZ9S
Honestly, copy/cut/paste in today’s world warrants physical keys far more than insert/print screen/etc. Maybe someone will decide to challenge that one day, but I’m sure people will have a million reasons why it can’t happen.
Everything is suboptimal for everyone and life goes on I guess lol
AFAIK those keys send the equivalent of the literal key chord (e.g. Cmd-Z) to the computer. I wish I could flip a switch and have them be considered keys in their own right, maybe F13-F16.
https://www.digibarn.com/friends/curbow/star/keyboard/index....
I'm not sure I understand; I'd guess they were used often enough to justify a separate key. E.g. some TV remotes still have a "Netflix" button.
Product placement and UX improvements could coexist too; sometimes literally, e.g. this keyboard has a MS office button and an emoji button: https://www.theverge.com/2019/10/11/20909475/microsoft-offic... .
I was doing PC tech support in 1988-1992 -- the era when the PC world went from MS-DOS to Windows 3.0 to Windows 3.1. (And a few weirdos, like me, ran OS/2 2, because Linux wasn't ready yet.)
I used to support, for instance...
• WordStar (3/4, Express and 2000)
• WordPerfect
• Ashton-Tate MultiMate
• IBM DisplayWrite
• MS Word for DOS
... on almost a daily basis, plus lots more occasionally: LocoScript, VolksWriter, PC Write, Samna Executive, and more.
Every one had a totally different user interface. Every keystroke, every menu -- if it had menus; lots didn't -- every status bar, with no similarities.
There was one key -- one -- that almost everyone respected: F1 for Help. Except WordPerfect, where it was F3.
Then IBM introduced a standard called Common User Access, soon after the Mac started kicking IBM's backside in user-friendliness.
CUA mandated that all apps should have a menu bar, at the top of the screen. (Lotus 1-2-3 and MS apps put it at the bottom, before.) It should have options called:
File -- for loading and saving. (Previously, MS called this "Transfer". Lotus called it "Workspace". WordPerfect didn't call it anything but it was on F7, or Shift-F7, or Ctrl-F7, or Alt-F7, or Shift-Ctrl-F7 (etc) depending on what you wanted to do.
Edit -- for editing: cut, copy, paste, search, replace, etc.. (Mostly not even a menu before, just hotkeys.)
View -- for controlling viewing options: text mode, graphics mode, colour, show formatting codes, whatever.
And a bunch of others, but all had to be 1 word only, with a unique letter to open the menu with the Alt key.
The last had to be Help.
And so on. It mandated a standard, borrowing heavily from the Mac HCI guide to do it. And amazingly, it mostly caught on. MS followed it for Windows, mostly, and after Windows 3.0 DOS app vendors found it beneficial to make their clunky old DOS apps at least look and work vaguely like their Windows apps.
Ironically, MS itself had to change more than most. MS Word 3, 4 and 5 were nothing even vaguely like CUA. To load a file in them, you pressed Esc to open the menu (2 lines at the bottom of the screen), T for Transfer then L for Load.
After CUA, in Word 5.5 (a free download now, if you want to try it out -- works well under DOSemu in Linux), this was replaced by Alt-F for File, then O for Open.
Old DOS Word users had a lot of relearning to do.
Long ago, I expanded this from a stub into an article: https://en.wikipedia.org/wiki/IBM_Common_User_Access
I've long wished that someone would implement the Canon Cat UI as an Emacs module. It would seem to me that Emacs has all or most of the necessary functionality already.