Cancel button, reset form or go back?

Question

I'm working on a project where there's a CRUD table, but the editing takes place in an individual page. In this editing page, if the user presses the cancel button, a modal pops up asking for confirmation before redirecting the user back to the CRUD table.

There's also a settings page where it's just a single form. In this case the cancel button works more like reset, where it clears the form instead since there's nowhere to return to.

Is it ok to have two behaviors for the same button?
Or should I just remove the latter's cancel button entirely?

I read that it's best not to have a reset button in case users lose information unwillingly, but would it be weird if some pages only had a save button and no cancel, while some have both?

Answer 1

It's not a good practice to have different behaviours for actions that look similar to the user.

"Cancel" is a way for a user to "Exit" a process or action without making changes.

So your first application of the Cancel button is correct.

If your intended behaviour is to clear or reset a form, you can tell your users exactly that.

You can name the buttons "Clear Form" or "Reset Form".

Answer 2

I see two things here that I think can be improved.

1. You don't need an "edit" button in the rows of your table. I think it's a better flow if you direct your user to a detail page first, and have them there decide to go an edit the contents. So, have them be able to click on the row, and navigate to the resource's detail page.
2. Even if you prefer to have an "edit" shortcut (which it basically is, as you are going directly into edit mode and skip the view version of the detail page), it should be a link and not a button. You are not applying an "edit" action directly on the resource, but are merely navigating to a new page where you can perform the edit action(s).
3. There, once in edit mode, the "Save" (or "Update", as you are updating the resource, REST-ful speaking) is the actual action you're applying. So that should indeed be a button. The "cancel" however is not the secondary action; it is a navigation back to the previous state of your UI, hence why it should be a link.
4. Alignment-wise there are several opinions. I just happen to prefer the right-aligned for small views.

Answer 3

Is it ok to have two behaviors for the same button? Or should I just remove the latter's cancel button entirely?

When you have a critical situation (data loss, delete something, update and important information), the button will have a extra validation.

It's prevent usability errors, but you can do a usability test, to see how your users are affected with this.

References: https://www.nngroup.com/articles/user-mistakes/

Answer 4

I do think it's confusing that the cancel button has different behaviours here.

'Cancel' works on the edit page as a fairly well-recognised way of closing a modal or going back.

'Cancel' on the settings page has hidden functionality, where you empty the inputs. Consider whether there are other ways to offer 'clear' functionality, whether it's a 'Clear all' button or a cross icon (button) in the input on the right-hand side.

Answer 5

Is it ok to have two behaviors for the same button?

No. I think it would be better to rename the [Cancel] button on the settings page to what it's actually doing: [Reset]

If you'd like for users to be able to discard the changes for whatever reason - clicking Reset, or typing something they didn't intend, add a third button [Discard Changes] to the settings page.

The settings page might look something like this:

Settings Page
------------
... contents
...
...
[Save Changes] [Discard Changes] [Reset]

From my understanding of your question, I think the above options would be the most useful. Hope that helps! If I misunderstood something, please let me know!