Hacker News Reader

You’re correct, the linked article contradicts the Human Interface Guide from Apple.

From the official docs [0]:

> Always use “Cancel” to title a button that cancels the alert’s action …

> “A specific button title like “Erase,” “Convert,” “Clear,” or “Delete” helps people understand the action they’re taking.”

In fact, I think the entire topic is much better explained (with considerations for each platform) in the docs.

[0] https://developer.apple.com/design/human-interface-guideline...

More on navigation:

https://developer.apple.com/design/human-interface-guideline...

https://developer.apple.com/videos/play/wwdc2022/10001

In the example of Apple Calendar, creation is arguably the "dangerous" event even if it's not destructive, so one might argue that what Apple is currently doing on Apple Calendar (cancel destroys the event) is compliant with the spirit of their HIG. I'd use the same argument of creation-is-dangerous for the alarm app, which also has a non-scary cancel button that destroys the input.

Then we go to something like Apple Notes where even the slightest bit of data is auto-saved without asking.

I don't follow. Apple Calendar shows a sheet to create a new event. The sheet has a primary action (Add) and a discard action (Cancel). If you hit Cancel after adding some data, you get an action sheet "Are you sure you want to discard this new event?" with the options to "Discard Changes" and "Keep editing"

The primary and secondary actions on a sheet are not the same (different modality and context) as the options on a modal action sheet (where we usually have to confirm or discard).

Oops, you're right, I just didn't change any data. However, on Apple Calendar for MacOS, using ⌘-n and dismissing the prompt will destroy your data. The same is true for alarms on iOS.

Not 100% sure about cancel vs. stop.

Say I'm creating a new calendar entry. I type a lot of information, then I get to save or cancel. Technically, cancel is safe because I'm not messing up my existing calendar. But all the typing I did (especially on mobile) would be lost. So is cancel really safe? But Stop wouldn't the right choice either...

What do you suggest?

> Technically, cancel is safe

No, it's not safe in that scenario. "Destructive" means throwing away anything, even one word the user typed. Do not use the word "cancel" for that operation - use the word "Discard" or an X button, with an are-you-sure prompt that has a cancel button that safely brings you back to the editing interface.

Edit: OK, maybe "one word" is an exaggeration. Certainly for the case of a form of input fields a no-prompt cancel button is inappropriate. However, if you have a simple OK/Cancel dialogue that contains a single one-line input field, it is usually acceptable to have a Cancel button that throws away your input without prompting.

If I'm filling out a modal form and "Cancel" doesn't result in a clean form after I open it again, it should probably say something like "Hide" or "Finish later" instead.

Give the user an option to save it as a draft. Fantastical does this, not sure about Apple's own calendar.

Both apps show a ‘cancel’ button on the ‘add event’ popup, as per this post.

They both then show a ‘discard/keep editing’ prompt, but only fantastical has the extra option of a draft.

But in addition to that — fantastical’s popup isn’t even modal. You can push the sheet down to see and interact with the main calendar.

Unfortunately, fantastical doesn’t show the ‘drag handle’ that Mail and other apps use to show this functionality, so it’s not particularly discoverable.

My understanding is that if the navigation bar style starts with large then it should have the drag indicator.

Label your buttons "Save" and "Discard".

"Save", "Discard" (or "Don't save"), and "Cancel", where "Cancel" does not dismiss the editor.

(This is the three-button close prompt that's been the standard in desktop operating systems since at least the Windows 3.1 era, but I guess we have to rediscover these things when the same problems come up on mobile.)

That pattern makes more sense when you are A. Editing a document, as opposed to filling out an ephemeral form; and B. The document does not auto-save. This pattern is more likely on desktop, which is where you're getting the correlation from. It's unnecessarily complicated when filling out something that appears in a modal like the article is referring to, e.g. a calendar event.

That's not a cancel.

In the case of a e.g. "New Widget" modal popup, I'm quite comfortable with a "cancel" button that means e.g. "this will discard whatever you typed / stopping the creation of a new widget". That kind of cancel button certainly results in lost information, and in some sense it is "destructive". But isn't "destructive" of data that we expect to persist. I typically use the word in the latter sense.

Hopefully people have a decent shared understanding of the term "destructive" or this is going to be very confusing for all involved. Is there a clear shared understanding? I don't run UX testing.

"Cancel" should never be on an "Are you sure" prompt.

Labels the buttons with what they DO.

"Don't delete", or "Keep", or "Save", and "Delete", would be appropriate button labels.

Sorry, I disagree. I've seen the pattern you're describing. Yes, it is perfectly acceptable (usually preferable, even) to replace "OK" or "Yes" with an explicit verb. But please do not do the same for the cancel button. It creates an unnecessary cognitive prompt. Always give the user a no-thinking safe way of dismissing a confirmation prompt - we have trained users for decades that "Cancel" is that escape hatch.

As another commenter pointed out, I agree with the HIG here: https://developer.apple.com/design/human-interface-guideline...

> Always use “Cancel” to title a button that cancels the alert’s action.

> Are you sure you want to cancel your flight?

> [Cancel] [Cancel]

I totally agree that it is preferable to replace "OK" or "Yes" with an explicit verb. The same thing should be done to the usual "Cancel" button. If you are already thinking of an explicit verb to replace "OK" with, just add "Don't" to the other one.

And as always, the unstated first rule of UI is: Also use common sense :)

E.g. in this case, the first option should be "Cancel Flight" or "Yes", and the second option should be "Do Not Cancel" or "No", though I'm sure there are other reasonably explicit options.

Edit: We each made essentially the same suggestion as an edit to our posts at the same time. The only difference is that I consider this an exceptional case. I still contend that "Do Not XXX" requires more thinking than "Cancel" when there isn't an obvious semantic conflict. You say "if you are already thinking of an explicit verb...", but I am not concerned with saving myself cognitive effort - I am concerned with the user.

Edit: Also, note that this is all tangential. The only point I was interested in writing about at the top of the thread is that, when you do see a "Cancel" button, it should never be destructive.

This is not true. Cancel is often destructive, we just have a bar over which it will ask you if you really meant to throw away your current work. Like, I just went to type a new message in iMessage and if I hit "Cancel" it gets rid of what I typed. That's because it's not worth the mental overhead of saving two lines of text that is the typical amount of unsaved content that a typical message contains. On the flip side, Mail will ask you if you want to save a draft if you exit.

I disagree that this is evidence that it is "often" destructive - however, this is mostly a semantic disagreement. As you have pointed out, "destructive" is subjective. I mention in another comment that I would consider throwing away the contents of "a single one-line input contained in a prompt" to be non-destructive. It's not a large leap to the contents of a single instant message, whether or not I agree that it qualifies. E.g. if iMessage would throw away a large amount of text un-prompted, I would disagree with iMessage's UX.

I'm not sure you really disagree with the core of what I'm saying, which is that "Cancel" is the universal easy way to safely dismiss a modal prompt, and also, regardless of what word you put on the button, if it would throw away a (subjective) threshold of data, you should prompt the user.

I went into this discussion with the suspicion that despite your ALL CAPS exhortation your opinion was not actually all that disagreeable or controversial.

Yeah, I would characterize it as a genuine all-caps exhortation only under the qualification that I am defining the word "prompt" as a simple prompt, not e.g. a message-composing UI (but the author is talking about modals in general, so I was not being precise enough about my disagreement with the author in my first comment).

> A decision is required to dismiss them: A decision whether to save state, whether to confirm (by tapping Done) or to destroy (by tapping Cancel) the data you’ve entered on a form.

Here are my questions so I can fully understand what you mean:

1A. Does it makes sense to have a button to (destroy/prevent) ("in-flight"/tentative) changes?

1B. if so, what do you think a button doing that should be named?

2A. You also think there should be a button to make the modal go away but keeping all inputed data just as it is?

2B. What should that button be called?

I'm wondering if you might answer: 1A: Yes. 1B: "Discard". 2A. Yes. 2B. "Dismiss".

I believe the author used “destructive” because that’s the name used by UIKit to style a cancel button with the system defaults.