22

I noticed that in some cases Apple uses Cancel / Done buttons, and in others there's only the the Back button.

In Calendar, for example, when you choose how often an event should repeat, you have Cancel and Done, which automatically takes you back to the previous screen. However, in Settings, when you choose a ringtone, you have to hit Sounds (or Back) to save your choice.

My guess is if you're creating something, you have to hit Done at every step, but when you're just changing settings, the "Save" (or the Done button) is implied when you hit back.

Are there any official conventions for how and when to use these?

(1) Calendar > Choosing the frequency of an event (2) Settings > Choosing a ringtone

Improve this question

6 Answers 6

Reset to default
5

I think the rule is:

  1. Use Back button when you push the view (the Back button is shown automatically).
  2. Add Cancel/Confirm buttons when you show the view modally.

So the real question is: when I should show a view modally? The question is answered within the iOS Human Interface Guidelines:

Use a modal view when you need to offer the ability to accomplish a self-contained task related to your application’s primary function.

The Calendar example of your question: when you add or edit an alarm you are accomplishing a self-contained task, so a modal view is used. To be more accurate: the screenshot you provided is related to a view pushed on a modal view. But in this situation the push of a view is used to avoid a modal view on another modal view (and Cancel/Confirm buttons are used).

The Sounds example of your question: you are only choosing a sound, so it isn't a real task, it is only a choice. And the push of the view is correct. To be more accurate: why you don't go back automatically when you select a sound? Because in this way you can listen more than one sound without the need of back and forth between views (you only go back a single time, when you have chosen the right sound).

Improve this answer
3

While this looks inconsistent, the reason behind the two different strategies has to do with what I like to call 'the drunken user back door option'.

Cancel buttons are offered for various reasons in UI design. One of them is:

(Offer a cancel button) if the user may not be able to tell the consequences of further actions.

Consider a scenario where you have made a selection and right after received a phone call (which happens to last for 20 minutes) or someone started talking to you on the bus (for 20 minutes). Both will 'take you away' from the screen, but you'll be returning to it.

The cancel/done screen suggests nothing about what event is actually being edited. A user will have this information in mind straight after entering the screen, but possibly not after 20 minutes.

The screen on the right clearly shows that you are choosing the sound for a new mail notification, thus even after 3 days, a user bumping into this screen will quickly be able to gather what will be the result of any actions. Such is not the case with the left screen, thus the 'cancel' option.

Improve this answer
2

Overall, I think if something is easy to undo "Back" and automatic save is sufficient. If it is hard to undo it is good to provide a "Cancel" control.

Popovers in iOS usually don't have "Back" and instead have "Done"/"Done and Cancel"/"OK".

Looking at iOS there are differences even between editing flows and creations flows:

Editing flows: contact edit has has Cancel and Done, reminder edit has Cancel and Done, wifi editing only has back (even though it cannot be so easy to undo).

Creation flows: new contacts (Cancel and Done), new note (Back, done), new reminded (Done).

So I would recommend considering your individual UI flow and see if being able to Cancel is critical.

Improve this answer
3
  • What I meant was that the screens above work exactly the same way by letting you choose from a list (so they're both easy to undo), yet they have different ways of going back. I understand having Cancel/Done for things that let you choose a date or type text, but why such different behavior for simply choosing from a list? That's what I'm trying to understand here.
    – inko9nito
    Aug 8, 2012 at 19:03
  • The cancel of the contant/reminder editing are as A) there are use case scenarios where undo is assumed; B) to allow users to experiment (ie, learn) the various features. The Wifi editing is considered an advanced user feature - the assumption there is that no ordinary user will enter the editor seeking experimenting. Instead users will follow instructions or will have a clear idea of what they wish to change.
    – Izhaki
    Aug 13, 2012 at 2:10
  • Both for new note and a new reminder back or done on an empty record equate to cancel.
    – Izhaki
    Aug 13, 2012 at 2:11
1

I think you're on the right track regards the create vs modify something. In the example provided, selecting the repeat frequency for the alarm is the last step, that's why you get a Done button. If the same steps of setting the alarm were implemented in a convoluted hierarchy of additional settings using hierarchial navigation, it would be most cumbersome.

When you set the ringtone, it's one of the many different settings you can change. So you're not really Done until you change all the other settings you want to change. Personally I think that using a Back button is great for only one or two levels in a hierarchy. I lose interest in applications that make you wade forward and back through extensive hierarchies.

Improve this answer
0

Taking the first route with a Cancel and Done action; You could potentially chain actions together creating workflows. When the only option is back you are creating more of a tree hierarchy. A hub page with multiple single selection options. I think usage would greatly depend on the page before this view. I would make the determination dependent on the complexity of the previous page.

Improve this answer
0

enter image description here

A cancel button gives the user the option to undo all changes made on that screen. This is useful when the user may have made many changes to the settings, and wants to undo because it will be painstaking to change the settings back to how they were.

In the above example, let's say the user had gone and swiped 10 or so of the settings to the "ON" state. If they changed their mind, they would then have to go and make ten more swipes to reset the settings to off. Having a cancel button would allow them to simply use one finger tap to cancel all the changes they had previously made.

In the case of creating something new, e.g. creating a new account, once you have filled out the form, you need a button to confirm the creation of the new account. Having a back button to confirm would be silly, as it gives the user no way to opt out of the process, and also linguistically it makes no sense.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.