What is the opposite of Cancel?

  • I am working with order page. When the user presses on Cancel Order button, he should choose one of the following:

    1. Cancel order.
    2. (opposite of cancel) order. (this choice means don't do anything with order) by default, this choice on other cases should be "Cancel".

    What is the opposite of cancel on this case?

    Keep in your mind, cancel is usually what you press to decline an action in a UI situation, and here on my second choice, I am trying to do that.

    Is this when an order is already placed? So will the user be cancelling an out standing order? Or is this one of the last steps of the order process?

    first choice,order already placed

    **confirm order?** or am I missing something?

    Process, Proceed, Affirm, Confirm, Action would all be the opposites to Cancel in many cases.

    **Proceed**: to carry on or continue any action or process.

    In Windows, OK is typically the opposite of cancel, in forms, Accept can be the opposite of cancel.

    No one suggested "**continue** this order"? As a marketing bonus, it's quite engaging.

    If I did something (e.g., click a button) to indicate that I wanted to cancel something, and a dialog came up with a "Confirm" option, I would select it to say, "Yes, I confirm that I want to cancel." Something like "Keep processing" ("Keep shopping," if appropriate) seems intuitive. This suggests that we should not be getting to this point via "Cancel"; as Ken Mohnkern says, "cancel" normally means nothing is going to happen.  The first command should be "Discard this Order."

    in addition to @TafT , **Resume order** ?

    @Migz possibly although Resume suggests it was paused or halted, I think most of mine suggest a continuation of a smooth process.

    Buttons should be [OK Cancel] and [Cancel Cancel].

    Continue gets my vote, it suggests you are carrying on the process, rather that starting the process (Confirm, or Proceed)

    'Cancel' is a negating action; it is intentionally broad to apply to whatever your scope/context was previously.

    **Do not cancel order**

    `lecnac` is way more googleable than any of these others.

    I would use "Decancellate", with a hyperlink to a 20-page explanation of what it does.

    Keep in mind, cancel is usually what you press to decline an action in a UI situation, and here on my second choice, I am trying to do that.

    Maybe "commit" (like in commit a transaction)

    I think The question here more specific

    I'd go with 'Proceed'

  • Cancel might be too vague. I always like to be more descriptive when asking users to perform a quite destructive task. This often reduces any anxiety users might have.


    download bmml source – Wireframes created with Balsamiq Mockups

    As LightnessRacesinOrbit made me realise in the comments, mixing up buttons with links that act like buttons (or in this case it's a button styled as a link) might be confusing. This thought might be unsubstantiated, but nevertheless, I'm adding the following mockup:


    download bmml source

    This also stops the users from reacting instinctively to the buttons they were used to, like "OK" or "Cancel", and makes them actually read what this unusual (for a dialog window) sequence of letters means.

    @Ruslan That's key. I can't count how many times I've "auto-clicked" a button because I assumed the meaning of an overly-simple label... only to be wrong.

    In my example, the Yes button draws more attention, just like an OK button would be auto focused to draw attention to it. The revert button is styled down. In my test I've never encountered someone pressing the wrong button. This, however, does not prove this pattern is better or worse than your basic Ok, cancel confirmation popup in that area. I did have some verbal feedback of users saying they liked how clear it was and how they're still unsure whether the action is still performed or not performed when pressing just ok or cancel. IMO, this validates the anxiety reference in my answer.

    Good answer. I'd like to add something... Because "cancel" is so often used to indicate that a state is being left unchanged, I'd suggest not using that word at all. So the button could be "Delete Order," then the confirmation can be "Are you sure you want to delete this order? [Yes, delete the order] [No, keep the order]."

    @KenMohnkern I don't think I agree. Cancel also means to revoke and is in this case applicable.

    That's true, @PaulvandenDool. But I think it's better in general to use words that are less ambiguous.

    Basically, you want the buttons to be self-explanatory, without having to read the dialog box. The one weakness I see here, is that the default should be non-destructive. If "Yes, cancel this order" is focused, a user may accidentally press enter, or autopilot to the focused button, and cancel their order. If the user accidentally selects "No, keep this order", nothing happens, and the user can go back in and select the correct option afterwards. The user will have to recreate the order if they accidentally select "Yes, cancel this order", adding unnecessary hassle.

    @PaulvandenDool: If the order has been issued, but not processed, I would suggest "Issue cancellation request" rather than using the "Cancel" as a verb. Note that in most situations where a "Cancel" request would prompt a conformation dialog box, no action will be processed until the user responds, but in an order-cancellation situation if the user doesn't do anything the order will likely proceed as planned.

    Actually, I use the same one but I write choice number 2 as the following: (No, go back)

    I'd agree with William that this breaks the rule about the highlighted option ( which would be the one you action if you press return ), being the one which saves data not destroys data.

    Mixing buttons and links this way is really terrible, from a semantic standpoint. But from a usability standpoint it can be quite helpful. I'm torn! Argh!

    @LightnessRacesinOrbit "terrible, from a semantic standpoint". How so? You mean that something that looks like a link should behave like a link? If so, you might be quite right.

    @PaulvandenDool: Basically, yeah, but adding to that .. if your system "violates" that principle and makes links act like buttons (or makes buttons act like links) then that's one thing but you should do it consistently. This example mixes it up within the space of two lines! Or does it....

    @LightnessRacesinOrbit The mockup was hastily set up. I didn't know it would get this much traction. I might want to improve on it. But it's not so much as a link that acts like a button, it's a button styled as a link.

    @PaulvandenDool Oh hey I'm not complaining about the mockup. I see this approach all over the web in real life. I'm just thinking out loud, I suppose. I'm saying that buttons styled as links (especially when there is a button styled as a not-link right above it) should theoretically be bad and wrong, but are not only commonplace but (in my experience) fairly user-friendly, which is interesting. Maybe it's just me. :)

    @LightnessRacesinOrbit I get that, but nevertheless, you do have a point. And I thought it worthy to update my answer.

    See, I think the one with the button-as-link is less confusing, user wise haha

    @LightnessRacesinOrbit I've revised my edit to reflect I misunderstood you ;)

    I like the idea of just a single button, with the "No, keep this order" textual link being significantly smaller and offset somehow.

    Red colored cancel button still attracts user attention, which may result in a human error, accidental click. I suggest to swap places, see my reply below.

    @Ades: but it SHOULD attract attention. And also alert. The button is to *confirm* the cancellation of the order

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM