4 ms·

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

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

by isodev 3y ago

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