Jef Raskin’s “Humane Interface” book was such an eye opener for me—-no modes (that explained why I was always frustrated with vi or emacs), and that computers should never lose your data.
From this post I learned there was a project called Archy implementing Cat in software.
> Computer rage is a familiar phenomenon because computers are so adept at losing your data. At any given moment, you are one innocent step away from destroying minutes, hours, days, months, or years of work.
> Archy never loses your work. This shouldn't be a groundbreaking innovation in computer design, but it is. You never have to save because it's done for you automatically. Your data is stored in such a way that if your computer crashes, your information will still be there the next time you start Archy up.
I think these days we are 70-80% to this groundbreaking innovation—-my computers no longer lose my in-progress e-mail or documents, but sure still keep losing form input here and there, and I still accidentally select all text and type over it in a system with a single-level undo (iOS).
Thanks to Moore's law, and this excellent essay by the late, great Michael O'Connor Clarke[1] and our largely successful KillSave campaign, we at least have autosave as a widely adopted measure of sanity. It's better than nothing.
Ugh, I loathe autosave popping up in more and more places, particularly webapps.
I've messed up the working copy of my wife's business website and various docs more than once because she's asked me to fix or tweak something. I automatically change some random things around in Squaredpace/Webnode/Canva just to get a feel for a tool I've never used and discover how the workflow might compare to something I'm familiar with. Then I find out there's no undo or it doesn't revert everything, I have no idea what changes I've made vs the original, and it's autosaved. Terrible UX!
Autosave has no place outside anything more complex than a simple text form, unless it's solely a backup solution for crashes, or paired with a very solid version control system.
Agreed, autosave is wrong, because save is, among other things, a destructive operation: it obliterates the old version of what you save. That should require a decision by the user.
What macOS native apps all do, and have for years, is the right thing. They save your work, but not in your file. Open something, make modifications, close the program, open it: the modifications are still there. Crash? When you reboot, you still have your work. You save when you're ready to replace the old version with the new one, the program doesn't make that choice for you.
Mostly they don't save undo history between boots, though, and that's too bad. Ideally every format in which people actually do the work would be non-destructive, preserving an undo history back to whatever the initial state of the file was. Photoshop got this right, so it's common in image editing, but it should work everywhere.
Clearly you don't usually want finished work to contain the complete edit history, so exporting a rendered version is essential. But this isn't a difficult problem.
We basically need the concept of quicksave and discrete save slots from video games.
The system should regularly quicksave, but when I want to make a conscious checkpoint, let me do so. Perhaps use a VMS-style versioned-file system if you want a seperate channel of undo history.
I bought Jeff Raskin's book years ago in a moment of inspiration.... His ideas were thoughtful, but perhaps impractical? That was my impression nonetheless.
I loved his book (the Humane Interface). I even used ideas from it to create RFPs for a client, and was able to better critique ideas.
Not having modes is still a big deal for me. Getting lost in menus and "not being able to get back" was something I dealt with a lot, and having this spell out my frustrations was very helpful.
That said, he really loved the interface of the Canon Cat; I had no idea what it was when it existed, and I only know of it through Wikipedia.
In the 1990s, I worked on a Canon typewriter (AP800) that had a similar-looking keyboard. That keyboard is the best I've ever had the pleasure to type on and I've tried quite a lot, including IBM Models M and F, all Cherry colors, Topre, etc. I could type for hours on that thing and not get tired. I would love to get my hands on a Cat to see if the keyboard is as good as that one was.
That's interesting; can you articulate specifically what the keyboard is doing better than others? (Lower activation force, more obvious clicking, ...)
Fascinating to imagine that but for an unfortunate marketing approach (and some limited unfortunate product decisions) Canon might have had a significant future --and now a legacy-- in computing!
Canon gets a lot of heat for the failure, but it was not an "obvious" interface imo, unlike WIMP interfaces. I have a faint memory of trying a Canon Cat, and it just made no sense to my young eyes, and that was before I had a computer with a GUI (had used Apples and C64s before this)
"token-threaded" Forth, which instead of storing direct execution addresses for each instruction in a Forth word executes using smaller tokens which are looked up instead. This exchanges the cost of an indirect lookup in a table for substantially greater code density.
In other words, like a bytecode VM?
The "ROM" at IC11 is actually an 8K 150ns static RAM, an NEC D4364C with specific support for battery backup. The service manual calls this the SV-RAM. This is what the CR2032 battery powers at the southeast (lower right) corner.
A CR2032 is surprising for a computer from 1987, given that AFAIK PC mobos didn't have them until the 90s at the earliest.
Kind of, but it's still Forth of the era, so it's still threaded execution. You're still jumping from execution address to execution address (either native 68000 code or another set of Forth words heralded by a JMP to the nesting subroutine); you just have a layer of indirection by having to look them up in the token table first.
Forth style threaded code was used not just for Forth - it was popular strategy for implementing higher level languages at one point, especially to reduce size of resulting binaries.
Funnily enough, some later more advanced compiler systems could be considered to have bits resembling that in code generation, with Virtual OPerations that abstracted CPU instructions (often more than one).
And indeed, threaded interpreters are one of the efficient ways to implement VMs in resource constrained setups.
Yamaha used a CR2032 with legs as battery backup for sounds in most of their synthesizers starting at least with the DX7 that launched in 1983. So there is precedent.
> Raskin was emphatic that the Swyft and Cat should not have modes — when you release the keys, the operation is over, whatever that ends up meaning.
But that's not what this is. Search is a mode; it's just one that, in the Cat design, requires holding down a key to keep active, and by dint of modelessness as a design goal also fails at discoverability. (How do you cancel a search?)
Rasking recommended cancelling searches by mashing the keyboard randomly to extend what you had typed so far with something that was sure to not be found in your text. The search advances with each new key you type while holding "leap". I agree that this was not discoverable at all, though it is trivial to learn. I don't know if backspacing while leaping would backtrack the search, but if that was the case it would have been what I would have tried (this would be just a little slower than Jef's suggestion).
Huh. That's a lot of weird effort and loss of cognitive focus, just to net out at nothing. As with having to hold down a key because the designer refuses to admit the mode it invokes is a mode, by modern standards this seems all not very completely thought out.
The idea of using incremental search transparently for both navigation and retrieval does appeal - I could see adding that to Emacs, as a union of isearch and occur, maybe - but we've learned a lot about interaction design in the intervening decades which leads me to feel the veneration of Raskin may often obstruct evenhanded critique of his work: as with Jobs, people seem to confuse the appellation of "visionary" with a guarantee that its recipient's vision was perfect.
If you can be “in a mode, but only temporarily” – like the shift key puts you in capital letter mode “only temporarily”, as opposed to how CapsLock does it “permanently” (until you press it again) – what does that prove?
AFAICS only that there is a mode.
Glue some little mechanical contraption onto the Cat's keyboard to hold down the Search key until you nudge the thingymabob again to release it, and it's just as (semi-)“permanent” as CapsLock. (AFAIK, that's exactly how CapsLock worked on mechanical typewriters.) The fact that they didn't build that into the Cat's keyboard in the first place is just an implementation detail... That seems very much like a feint to avoid admitting that there's no “quasi” about it; a mode is a mode is a mode.
Those are not equivalent; barring some highly unusual configuration, the Shift key has no effect on application state outside the scope of the keypress. In that sense it seems to me that Leap leaks.
(author) This one has actually been in my collection for around a decade and is not a recent acquisition. I've just started playing with it more and figured I needed to shore it up to keep it going.
I don’t know where he got his, but last August there was one on shopgoodwill.com. I was tipped to it on a small retrocomputing Discord server but I stupidly forgot to bid on it. There were only 2 bids and whoever won the auction only paid $26 for it.
I'm absolutely tickled pink by the idea of a niche collectors-who've-yet-to-find-anything-club. Time to make some membership cards... and if we find one, buy timeshares...
From this post I learned there was a project called Archy implementing Cat in software.
The core principles still ring so very true: https://web.archive.org/web/20061025010636/http://rchi.raski...
> Computer rage is a familiar phenomenon because computers are so adept at losing your data. At any given moment, you are one innocent step away from destroying minutes, hours, days, months, or years of work.
> Archy never loses your work. This shouldn't be a groundbreaking innovation in computer design, but it is. You never have to save because it's done for you automatically. Your data is stored in such a way that if your computer crashes, your information will still be there the next time you start Archy up.
I think these days we are 70-80% to this groundbreaking innovation—-my computers no longer lose my in-progress e-mail or documents, but sure still keep losing form input here and there, and I still accidentally select all text and type over it in a system with a single-level undo (iOS).