I’ve always loved how TextEdit’s “don’t save” button is actually a red button that says “delete” for unsaved text files.

There’s no ambiguity there. The user is very well-informed that they’re about to quit and lose the document they were working on.

The example of Pages from the article has actually since been changed to do the same thing.

Red "Delete" on the far left, then on the far right a gray/neutral "Cancel" button, and an orange (the app's primary color) "Save"

"Delete" is the wrong verb, suggests I'm deleting the file, which I'm not. Sure you could say, well you're deleting the unsaved changes, but this isn't what it means on any other computer or even in other Mac apps.

The same update (Lion?) ruined saving overall. Apple has insisted that apps should never have a "save as." You can hold opt to do it anyway, but it silently overwrites the original too. Maybe or maybe not lets me revert, and idk where even those revisions are stored. Apple might've hoped this catches on, but again nothing else does it this way. I get they want me to duplicate the file first, but no, I already made changes that I want to save-as, it's too late to duplicate.

If they were going for blurring the line between memory and disk, that didn't work either because there is still the concept of saved vs unsaved changes (that can get "deleted"). It's not like Google Docs.

I think you’re technically correct but that “delete” gets the right thought across to someone who doesn’t understand how files work. You’re deleting whatever you have in front of you.

I agree about Save As…

Maybe that could have just been updated to “Save a Copy” or something like that. I don’t really understand why it’s a hidden option.

If common users understand it then fine, but it doesn't seem like they do. Only Apple does it this way.

You are deleting the document from your computer.

In some instances this could be a file on disk. But it does not have to be.

It's not deleted. I already have a.txt. I edit it then quit without saving. a.txt is still there.

Technically true but that's not what "delete" implies to most people, it's the mental model that's wrong, not the mechanism. Calling it delete when the file itself survives untouched is just confusing.

A better verb would be "Discard"

Yes exactly. Which I think is sometimes said.

On the subject of being slightly too pedantic for my own good, using "disk" in a conversation sort of worries me, It does not really matter, everyone knows what you are talking about, but it is not often an actual disk anymore. Is "storage" fine as a replacement? as in, memory vs storage.

I could go full nerd and call it "non-volatile storage" but nobody wants that.

A power user who’s aware they didn’t save would be confused, as there isn’t any file to delete. I would prefer “Discard”, which would also be applicable to the case of not saving changes to an existing file, where “Delete” would be entirely inappropriate.

… but, a power power user would know that it was transparently saved every several keystrokes, even while named Untitled and ostensibly unsaved, ready for immediate transparent recovery on relaunch, after an app or system crash -- so they might again be okay with it.

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

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.

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.

My favorite is apps that offer a way to cancel a long-running operation, where clicking "cancel" on the confirm dialog cancels the cancellation.

Sydney Padua's awesome, mostly true, steampunk graphic novel "The Thrilling Adventures of Lovelace and Babbage" jokes about the error messages that might have produced by the difference engine. One example occurs when a character tries to stop a sequence that may or may not destroy a precious manuscript:

Annulation lever activated!

Do you wish to continue?

Engage STOP lever to continue. Engage CONTINUE lever to stop.

Time remaining 5..4..3...

I still see "Press ENTER to exit" on many ATM interfaces.

This is largely the consequence of the Windows API having a built in option to use these buttons, without having an option for custom text. It would be a lot more work to build a custom window with custom buttons than just callong this API.

https://learn.microsoft.com/en-us/windows/win32/api/winuser/...

You could set a custom text by sending WM_SETTEXT to the respective button. It wasn’t a recommended practice, though.

It's actually more than yes/no/cancel. There's also a red X. I only know from experience that it's usually the same as cancel, but not always.

And clicking outside the modal

We had customers do this constantly with our billing dialogs, click away then email support asking why nothing saved. Ended up disabling outside-click dismiss entirely, support tickets dropped like 30%.

Classic Windows experience, continuing to use some program while there are 8 models that I've moved to the side

(A)bort? (R)etry? (F)ail?

Rip John C. Dvorak, writer of the Abort/Retry/Fail column from PC Magazine.

On a different note, never underestimate the value of a modal dialog that gives you a chance to retry an IO operation that failed. Loose USB cables and network shares over Wifi can make those happen a lot more often.

And it came from the days of floppy disks, so we often needed the chance to put the correct disk back in the right drive!

When the game comes on 14 floppy disks, sometimes you forget how to count in the excitement.

As I remember, standard operating procedure was to retry 4 or 5 times, then turn off the computer and walk away in frustration.

What always got me at the time was retry is understandable, but what the heck is the difference between abort and fail? I don't want to complain too much it was probably in the manual, but as a young teen during my DOS days (there are manuals? read?) The distinction was lost on me.

My understanding today is that one of them(fail?) gives the application a chance to do something clever. Did any application actually handle this gracefully? Something like, Disk 11/15 error(fail) Please put in recovery parity disk.

An active "yes/no/cancel" prompt is a paragon of usability compared to the modern standard of constant yes, except for when it fails with a silent no.

I'll take "Yes/No/Cancel" over the "Discover Windows 11/Remind Me Later" pairing that pops up on my arbitrarily non-upgradable PCs every month or so.

"Maybe later..."

“Maybe later” and variants annoyed me to no end until I realized that the implication is that you’re not making an indelible choice. As with anything, it can be overused, but I personally enjoy not having to think about whether I can change my mind later.

Except in practice "Maybe later" means "Nag me about this until I relent and accept"

"Not indelible" cuts both ways though. If choice never sticks, app just keeps asking, and that's worse than a real no. Reversibility's only good if it respects the answer meanwhile.

1. LibreOffice's recover files dialogue series of steps is frustrating like this.

2. Still better than "Yes, Ask me Later" dialogues that are so insulting to users.

Q: Do you think Microsoft¹ understands and respects the idea of consent? A: Yes / Ask Again Later

--------

[1] Or the BBC, or whoever, a great many are guilty of this sort of thing.

PedOS is so bad that I would actually try to use Linux instead nowadays if I didn't have a Mac. Even though I fully assume that any Linux distro will be endless problems.

What a weird article. In both shown cases it takes a perfectly legible and understandable dialog and then twists it beyond recognition into something I've never seen being actually used to go "see? that's what's wrong with it!", and when it actually mentions what and how can be improved it feels like merely a footnote.

I thought this was going to be about a marketing success example for Aspirin! ... Although, I guess in a roundabout way it was.

This is more or less the reason why bool is not recommended as a type, instead use a enums which add semantic value

This was well known 20+ years ago: https://thedailywtf.com/articles/what_is_truth_0x3f_

Right, though the deeper point (Minsky's "Effective ML" essay is the canonical reference) isn't just enums vs bool but making illegal states unrepresentable at all. A tri-state enum still lets you forget the Cancel branch entirely; exhaustiveness checking is what actually saves you.

    enum DoesUserWantToSave {
      Yes,
      No,
      Cancel,
    }

:p

Not understanding the aspirin reference.

Pretty sure "causes Aspirin sales to soar" is an attempt at cleverly saying "gives people headaches"

Thanks, I also found this unclear.

Aspirin had (though this is increasingly dated) unique cultural currency as a headache medicine for quite a while after it stopped being the overwhelmingly dominant first-line OTC remedy.

Omitting clarifying information is how cool kids signal their coolness to others, and exclude uncool kids.

This is even more true of HN users than it was on the actual playground.

My ambiguity stack overflows...

    _______________________
    | Error.              |
    |_____________________|
    |                     |
    |   Unknown Error     |
    |                     |
    |     (Continue)      |
    |_____________________|

(2007)

For a site about usability, I was going to gripe about the tiny font, low contrast, and unresponsive layout until I saw that. It does look more suitable at 1024x768.

Good year

Every year was better before 2020!

Good for aspirin sales, anyway.

Ran into that exact dialog pattern building an internal tool years back, users clicked Cancel meaning "not yet" and it wiped their draft. Rewrote every button with explicit verbs after support tickets piled up.

We added a clause in our coding standard to make all booleans reference the positive frame of reference only. This happened after I got fed up with dealing with too many if !(!not_has_missing_field) operators. Just.... make everything positive: if (is_field_present)

I try to keep to that, but sometimes the flag is turning on a negative feature, disabling that which is the default and will remain so for compatibility reasons.

Sometimes it is worth the effort of going through and changing the logic elsewhere to keep the boolean positive, sometimes that would be too much effort to retest at the time.

Another option I like, when I have a config object interpreting things so I'm reading doing `if (config.IsWhateverThatThingIsEnabled)` then I can just have paired properties to pick from when I want to check IsEnabled or IsDisabled.

I've come across code where there is an overide for an option to disable something and the naming plus the logical not really make you think about what is happening…

    if (!OverrideDisabledOptionToBlockAction) {}

However, if all tests happen to be of the form `if (!isValid)`, one might reconsider and use `isInvalid` instead.

This is by the author of "Designing Data-Intensive Applications", one of HNs favourite books. https://dataintensive.net/

A program I occasionally use has a "Don't close" button in that dialog. Of course I'm more used to "Don't save", so I often hit it and then am surprised when the program stays open.

I mean I don't bother reading the dialogs. If there's modifications, "Yes" means save, "No" means close the program without saving, and "Cancel" means go back. And almost every program agrees on that convention, so you don't need to read the dialogs.

"the program is still trying to answer two questions at the same time, which you may consider to be an unnecessary complication" - fuck off. This is why we have the modern idiom of saving everything to temp files all the time without even asking the question, an idiom that silently says you may not write a throwaway document because you can't handle anything so dangerous and cannot be trusted.

Let users have complicated things. You know, moderately complicated. They may not all have degrees in Complicator Science but they should at least grasp the concept of a three-way choice, and if some users find that an unnecessary complication then they can go away and stop trying to use devices.

I love how the link to Raymond Chen's blog is broken because one of the largest technology companies in the world doesn't give two shits about permalinks.

Great title. Great topic. The tiny details are all here, including the 4th option (X), the Abort/Retry/Fail link, and they even have RSS! Subscribed.