3 ms·

This sets off my alarm bells big time: >High-Friction Modal >A decision is required to dismiss them: A decision whether to save state, whether to confirm (by

This sets off my alarm bells big time: >High-Friction Modal >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. >Low-Friction Modal >They are easy to dismiss: “Low friction” means not having to think about how to get back. 'CANCEL' ON A PROMPT IS NEVER, EVER DESTRUCTIVE. This is a huge red flag for the author's understanding of UI conventions. "Cancel" must always be safe. "Cancel" is the low-friction no-thinking way to dismiss a prompt. It should dismiss the prompt, and do nothing else. Corollary to this is that you should avoid putting a "Cancel" button on a full-blown input interface that will throw away user data if dismissed (regardless of whether you have decided to embed said interface in a modal). If you do, you at least need a "are you sure" prompt with a cancel button (hence why you avoid using the word 'cancel' redundantly on the original form).

alain94040 3y ago
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?
- happytoexplain 3y ago
  > 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.
  - mcbits 3y ago
    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.
- lawgimenez 3y ago
  Give the user an option to save it as a draft. Fantastical does this, not sure about Apple's own calendar.
  - systoll 3y ago
    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.
    - lawgimenez 3y ago
      My understanding is that if the navigation bar style starts with large then it should have the drag indicator.
- LeoPanthera 3y ago
  Label your buttons "Save" and "Discard".
  - JonathonW 3y ago
    "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.)
    - happytoexplain 3y ago
      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.
- _moof 3y ago
  That's not a cancel.
LeoPanthera 3y ago
"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.
- happytoexplain 3y ago
  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-guidelines/alerts https://developer.apple.com/design/human-interface-guideline... > Always use “Cancel” to title a button that cancels the alert’s action.
  - kccqzy 3y ago
    > 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.
    - happytoexplain 3y ago
      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.
isodev 3y ago
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-guidelines/alerts https://developer.apple.com/design/human-interface-guideline... More on navigation: https://developer.apple.com/design/human-interface-guidelines/navigation-and-search https://developer.apple.com/design/human-interface-guideline... https://developer.apple.com/videos/play/wwdc2022/10001 https://developer.apple.com/videos/play/wwdc2022/10001
- threatofrain 3y ago
  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.
  - isodev 3y ago
    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).
    - deleted 3y ago
      [deleted]
    - threatofrain 3y ago
saagarjha 3y ago
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.
- happytoexplain 3y ago
  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.
  - saagarjha 3y ago
    I went into this discussion with the suspicion that despite your ALL CAPS exhortation your opinion was not actually all that disagreeable or controversial.
    - happytoexplain 3y ago
      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).
xpe 3y ago
> 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".
xpe 3y ago
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.
deleted 3y ago
[deleted]
fingerlocks 3y ago
I believe the author used “destructive” because that’s the name used by UIKit to style a cancel button with the system defaults.
deleted 3y ago
[deleted]

alain94040 3y ago

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?

happytoexplain 3y ago
> 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.
- mcbits 3y ago
  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.
lawgimenez 3y ago
Give the user an option to save it as a draft. Fantastical does this, not sure about Apple's own calendar.
- systoll 3y ago
  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.
  - lawgimenez 3y ago
    My understanding is that if the navigation bar style starts with large then it should have the drag indicator.
LeoPanthera 3y ago
Label your buttons "Save" and "Discard".
- JonathonW 3y ago
  "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.)
  - happytoexplain 3y ago
    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.
_moof 3y ago
That's not a cancel.

LeoPanthera 3y ago

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

happytoexplain 3y ago
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-guidelines/alerts https://developer.apple.com/design/human-interface-guideline... > Always use “Cancel” to title a button that cancels the alert’s action.
- kccqzy 3y ago
  > 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.
  - happytoexplain 3y ago
    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.

isodev 3y ago

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-guidelines/alerts https://developer.apple.com/design/human-interface-guideline... More on navigation: https://developer.apple.com/design/human-interface-guidelines/navigation-and-search https://developer.apple.com/design/human-interface-guideline... https://developer.apple.com/videos/play/wwdc2022/10001 https://developer.apple.com/videos/play/wwdc2022/10001

threatofrain 3y ago
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.
- isodev 3y ago
  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).
  - deleted 3y ago
    [deleted]
  - threatofrain 3y ago

saagarjha 3y ago

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.

happytoexplain 3y ago
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.
- saagarjha 3y ago
  I went into this discussion with the suspicion that despite your ALL CAPS exhortation your opinion was not actually all that disagreeable or controversial.
  - happytoexplain 3y ago
    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).

xpe 3y ago

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

xpe 3y ago

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.

deleted 3y ago

[deleted]

fingerlocks 3y ago

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

deleted 3y ago

[deleted]