Hacker News Reader

Comment by thefourthchime | Hacker News Reader

One of the most influential books I ever read was About Face by Alan Cooper. What he said about this bad modal dialogue is that you should simply not ask the user, and let them undo later.

This was heresy at the time, but turned out to be the native user flow for iOS later on. And now it's common in web apps.

https://www.amazon.com/dp/1118766571?lv=shuf&channelId=500&p...

View on HN

Remember in 1990 (the pictures are from around then) there wasn't unlimited fast disk space. There was a good chance you were saving to a floppy disk which not only was slow, but might not be in the drive all the time. At least in 1990 you could assume a hard drive - but you couldn't safely assume there was enough free space on the drive to save anything, since 40mb drives filled fast.

35 years latter we live in a different world where you can assume an unlimited fast data connection to a data center. Saving and allowing undo is possible today.

Even in 2005 when I was a kid using computers in school, I had some larger docs where constant autosave would've been unreasonable. Word had a timer that was like 5 minutes.

I once heard Cooper talk at a conference. He said that he was indeed the father of Visual Basic, in the sense that he had a little participation at the inception but most of the work was done by someone else. I think you can draw a line between that kind of self deprecation and the ego level required to look through someone else's eyes and design good UI.

In the world of 2TB SSD’s, it does seem silly to risk inadvertently deleting an important ~2kb word document.

It took me quite a while to get used to the "save continuously, keep revision history" of Google Docs, but in that context I've gotten used to it. For something like code, or image edits, etc. I still prefer explicit "Save" or "Save As..." operations that I control, because quite often I get myself boxed into something that I just want to throw away and start over.

You might like "save continously but call it 'history', offer a save button but that just names the current revision"

This lets you throw away and start over, but also gives you infinite undo even after "loading" an older version.

In IntelliJ you can look at local history of a file and see that the ide remembers your changes for a long time. It seems to take a snapshot on actions like test runs, build complete, or maybe every few minutes. This is on top of auto saving and git of course. It saved my ass when I ran the wrong git command more than once!

For me this is what I use Git for, even if I have no intention of pushing to a remote repository. So I suppose some of Git's functionality could be considered redundant if only the applications would be generous about saving history and deltas.

I've had my code editor's configuration set to auto save for at least 15 years at this point. I've never had the problem of not being able to throw something away that I wanted to throw away - either it's in the git history (broad edits), or it's in the undo-history (fine edits). It helps to have an undo history that survives restarts and that preserves branches, which I guess may not be a default for every editor

We could have both. The "save" button just becomes a pointer to a specific point in the revision history, the same way we already have that with git.

Well we're rapidly approaching a world going back to 256GB (or smaller) SSDs because VC money is being used to buy up all semiconductor and HDD output by AI hyperscalers. Everything will end up cloud storage, you'll own nothing and like it.

Also the minimum Word document is far larger than 2KB. IIRC it's about 10x that size for an empty Word document (docx).

In general, I hate undo. I'd almost always rather confirm/decline. Undo is ephemeral, if I even notice it, and is a recovery from an accidental action (that I may or may not even know would have happened depending on the UI). Declining is a deliberate action.

Reply on news.ycombinator.com