Tag Info

Hot answers tagged

278

My suggestion: never use the word "Cancel" in the default action. To cancel a subscription, you can, for example, say "Remove Subscription" or "Unsubscribe." To cancel a download, you can, for example, say "Stop Downloading". To cancel a setting, you can, for example, say "Revert Settings".


139

Here's what Facebook does when cancelling a payment subscription (Facebook subscription API). There's no reliance on Yes/No. There's no misleading use of the word cancel. Clear explanation and buttons that clearly define the impending action. Then they clearly confirm what just happened. Skype on the other hand shows what not to do. Much confusion! ...


35

Name the buttons for what they do. If the default is "cancel", then cancel the cancel should be something simple like "Don't cancel". I know that it's not ideal to use the word 'cancel' in both of them, but it's the clearest option in this unique situation, and clarity is far more important. Edit: Some good suggestions from the comments below are to ...


31

Rewording I would try my very, very best to avoid using the term 'cancel' for terminating the subscription. Cancel is generally considered to be a safe action. Here, you are using it in a more destructive sense, thus causing the confusion you noticed. If you manage to avoid the term 'cancel' for the actual activity, you can resume to use it for the cancel ...


11

I would like to propose a different approach to subscription cancellation. Instead of confirming that they want to unsubscribe, assume that they were acting intentionally: If the user doesn't click on any buttons on the dialog, they should be unsubscribed in an hour or five. If they dismiss the dialog with the "goodbye" or "(x)" buttons, they should also ...


10

Jakob Nielsen said that removing the Reset (or cancel) button helps usability most of the time: Because Back is such a strong behavior on the Web, it is usually not necessary to offer explicit Cancel buttons. If the user asks for something but doesn't want it, then you can be sure that it's Back button time. Offer a Cancel button when users ...


4

I think the rule is: Use Back button when you push the view (the Back button is shown automatically). 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 ...


4

You do realize that you have two almost identical "close" buttons in the screenshot above?! Don't you think that just this issue makes the usage of "close button" absolutely unacceptable? I think it does. Two very similar looking buttons on the same screen and particularly adjacent to each other can affect usability. In your screenshot, the first close ...


4

When someone is creating a new entry, you need a way for them to abandon that entry and not create anything. In iOS apps, there are two ways of doing this: Have a 'done' and a 'cancel' button. This is the clearest option as you are explicitly offering the actions to the user. However, you still have do decide how the 'back' button behaves. Does it act ...


4

I believe "Yes" and "No" buttons would be best, provided that the title of the window is clear. For example: Cancel Subscription? You chose to cancel your subscription, are you sure? "Yes" and "No" buttons would be very clear in this case. Why is this better than other options? The question is short, clear and can't be interpreted in more than one ...


3

No, you don't need a cancel button When you're clicking the "Add comment" button, you're not doing anything. You haven't posted a comment yet, so there is nothing to revert. An undo facility is useful when a user performs an action which has some serious effects. For example, removing an email from your inbox must have an undo, since you may be interested ...


3

A simpler solution would be just auto save the form data at regular intervals so that even if your users accidentally click out and then return they can continue using the form at the state they were at. Smashing magazine has this nice solution on how you could ensure autosaves on forms - Auto-Save User’s Input In Your Forms With HTML5 And Sisyphus.js ...


3

I'll go somewhat against the general flow here and say that it depends on the situation that you are using them in. Remember that de-emphasising the cancel button is in effect making whatever other option that is presented the default. So it is more a question of whether it is a better choice to make that the default or not. If you are asking something ...


3

There is no harm in having more than one action to close, as long as they don't confuse the user. I would consider some alternatives too: Clicking outside the box to close (this is fairly extended with the use of image lighboxes) Having a "Dismiss" button or similar. "Ok" is ambiguous, I wouldn't know what the related action is and would be in doubt of ...


3

If your using the Navigation Bar, then the standard convention is to have the Back button on the Upper-Left hand corner. Toggling the button from Back to Cancel wont make sense at all, your just confusing the user. Even if he made changes and pressed Cancel, he would go back to the previous screen itself. Here is my take, have a Back button in the ...


3

To answer your questions directly: Users expect something to happen if allowed an action, or they may conclude that the system malfunctions ("I press this button, but nothing happens"). If an action results in no change, either its trigger should be disabled, or a message should show, something along the lines of 'nothing to discard' (probably fade div ...


2

I do not like that guideline. Trying to be innovative with important user actions can be dangerous. I don't think there is any doubt that users are familliar with the "ok" and "cancel" options in such confirmation boxes. A flyout with just one option (ie. "Ok") used to be containing information like ie. "You can't do that here." that doesn't activate an ...


2

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


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


2

I had same problem one time. I realized that on iOS, "X" doing action like Delete/Remove. Done or Cancel as exit action are better for two reasons: 1) a lot of iOS apps do so; iPhone user will be familiar with this solution; we are avoiding users confusion like on screen you attached 2) In my opinion, search field do not need great amount of space on ...


2

I would say you need to use 'Cancel' and 'Close' appropriately, and use consistent patterns. I have always used 'Close' and 'Cancel' in the following ways: 'Close': by pressing this you are dismissing something like a dialogue, nothing bad will happen, and there will be no state change in your process. 'Cancel': the user has invoked a process and they are ...


1

I don't find any arguments for placing "Cancel" button on this form. "Cancel" means abandon whole process, not go back to the previous step. I would consider to add some autosave mechanism, user shouldn't think about saving his work, system should display information that all changes are saved. E.g. Google Keep:


1

As it stands, the use of the word 'Cancel' for that button makes it very confusing to understand its function and they way the button works in unintuitive. It might be a matter of changing the button's functionality and changing the wording of the button to clarify what it actually does. Perhaps the button should allow users to exit the process without ...


1

Save & Close and Save & Add New Here's an interesting approach done by Jira. Basically they add a checkbox to Create another similar item, if the checkbox is selected, the dialog will remain open, a new item will be filled with the same information as the one before it. You can see than Cancel is clearly a link (not a button), this helps the ...


1

tl;dr Never use the word «Cancel». Why is the word «Cancel» so problematic?? «Cancel» can be understood differently in different conceptual levels: Cancel the dialog and close it. Cancel the service. What happens when the two levels have contradicting, exactly opposite meanings? Examples: For a dialog to cancel downloads «OK» means canceling the ...


1

Yes, you should de-emphasize the cancel button (resp. style it differently). No, you shouldn't make it look like a link. I think styling it as a link gives a false impression. Some might think they could open that "link" in a tab. Some looking for a way to cancel the input might not recognize that "link" because they are looking for a button. And it's ...


1

I agree with David's answer. If you must have a Cancel button visible, a link would certainly reduce it's hierarchy. However if it doesn't follow your style guide, you can have two button, just have the "Save" button in green for example, while the cancel in light gray (or a slight difference from it's background).


1

In this case, I don't think it matters if you give the user 2 ways to close the pop-up or 1. Usually, I stick to the rule of thumb that actions should be possible in multiple ways in order to accomodate different users and what they expect to see. However, I think the pop-up model is so frequently used that just an "OK" button would suffice. The "X" ...


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



Only top voted, non community-wiki answers of a minimum length are eligible