Our web application has three different operations that proceed as follows:

  1. The user is presented with a popup where different settings are selected.
  2. The user can click on a button labeled with the operation (ex: "Merge") or "Cancel".
  3. If the user goes forward the application processes the operation which can take a few moments and another popup is presented which summarizes what will happen. At this point, the operation is not committed and the user can choose to proceed or cancel.

This is where our three operations are not aligned. In one case the choice is Continue/Cancel, in another it is Done/Abort and finally we have Finalize/Cancel.

Which of these is best? Is there a better alternative? If so, any supporting arguments?

  • 1
    Other possibility: Commit and Rollback. – carrier Oct 5 '10 at 16:05
  • Rollback isn't really the opposite of Commit, though. Rollback implies something has already been committed. (Also, nitpick: as a verb, it would be "roll back"; rollback is the noun) – Rahul Oct 5 '10 at 16:31
  • Roll back also implies some action will be taken to reverse a prior action. In the case of cancelling, no action is taken. – Nick Bedford May 19 '11 at 0:51

I usually try to stay away from generic button labels like these and be as specific as possible. Your labels feel very "database-y" to me and remind me of programmer-designed tools for very abstract domains (like ... database editors).

See this related question about OK/cancel button positioning for some more discussion:

OK/Cancel on left/right?

In my answer there, I linked to Jakob Nielsen's research on OK/cancel buttons, where he notes that:


For instance, some examples:

Also, you could consider leaving out the alternative. In some cases, this can make sense. I think a "cancel" option is good to include if the user is about to make a significant commitment, such as purchasing something or a CRUD operation involving a lot of data.

But for something simple, like tweeting, especially when there is an easy rollback available after the commit operation, it should be okay to leave out the explicit "cancel" button since it's usually obvious that not continuing will not commit anything.

A great example is StackExchange's comment form, which just has an "Add Comment" button and no way to hide the form or cancel. Don't want to add a comment? Don't click "Add Comment"!

| improve this answer | |
  • thanks for your answer. In this case we are in fact talking about "a CRUD operation involving a lot of data". – carrier Oct 5 '10 at 16:58
  • 1
    Then you could still use an "abort" button, but try and make it as specific as possible. "Merge these mailing lists" - "Don't merge anything" – Rahul Oct 5 '10 at 17:08
  • +1 great answer, being specific with the labeling helps a lot to the user's understanding of the procedure and how their actions will affect its flow. – Pam Rdz Oct 5 '10 at 18:44
  • your "StackExchange's comment form" example is dead-on but I regret that it doesn't revert back when I click outside (if the field is empty) – Knu May 19 '11 at 7:17

It sounds like a wizard. Here's an example:

  1. The user initiates the Merge function
  2. A popup appears, entitled Merge.
    It contains settings for the command, and Next > and Cancel buttons.
  3. The user changes the settings and clicks Next >.
    The application processes the operation for a few moments.
  4. The next page of the wizard appears. It has Finish and Cancel buttons.
    If the user clicks Finish then the operation is completed; Cancel cancels the whole thing.

Another approach is to make it a one-step process, but allow undo. This may or may not be possible, depending on the operation.

  1. The user initiates the Merge function
  2. A popup appears, containing settings for the command, and Merge and Cancel buttons.
  3. The user changes the settings and clicks Merge.
    The application processes the operation for a few moments and completes it.
  4. The screen shows the results of the operation, and includes an Undo button. If the user clicks Undo then the operation is reverted.
| improve this answer | |
  • I like your answer. I have to sell it to members of my team though, any chance you have some article or something I can use to back it up? – carrier Oct 6 '10 at 14:59

Two points I would like to make:

1) If the actual merging process is initiated after second screen (with summaries), then the "Merge" button should be on that - second - screen. Which leads me to say that on the first one, the button should say something like "Preview Merge results" or similar because this is the next result the user will get, in the process flow he/she started.

2) This is a kind of feature-creepy suggestion but maybe it would make some sense to have three buttons on the first screen: "Preview merge", "Cancel" and "Merge without preview". This would save some time for the user who knows what he/she is about to do and does not want to wait for the stats and then commit to his/her decision. Just an idea...

| improve this answer | |

If you aren't actually performing the "merge" after clicking Merge then you shouldn't call it Merge.

Often what is used in a multi stage form is a Continue/Submit convention. Continue implies that you must continue to the next stage, but it doesn't imply some commitment is placed yet.

In the case of an online store, checking out often requires the user to proceed through a few forms, providing address & payment details. Not until the page where they can finally confirm the order is a "Place Order" or "Commit To Buy" button used.

I would either use a "Preview Merge" or a "Continue" button then on the page where they commit, use a "Perform Merge" or "Submit" button.

| improve this answer | |

Your Answer

