We currently have an interface pattern that consists of a list of rows; clicking on one row activates "edit mode", where the lables turn into text-boxes, afterwards you can either save or cancel.

hover state

Hovering over an item indicates that you can click it (the cursor is actually a pointing hand)

enter image description here

After clicking on one or more items, you go into "edit mode"

If possible, I'd like to get rid of both "edit" and "save" entirely. You can start editing by clicking on a row, but what is the best way to cancel editing without any controls?

There are now four buttons in two places, only one of which looks different from the rest.

  • These buttons aren't always where you left them
  • Clicking 'save' twice by accident could delete your record (though there is a delay)
  • Users have to be able to edit these in bulk, so closing items when another one is opened isn't an option (also: there should be a way to get the whole page to look like you've just opened it)
  • While the interface can be controlled with keyboard shortcuts, a tablet user needs to be able to control the site just as well.

So to summarise:

I'm planning to get rid of the "edit" button. Is there a nice way of also getting rid of the "cancel" button?

After getting a bunch of great answers, this is what the view looks like:

enter image description here

(the second item has just been edited)

  • 3
    My knee-jerk reaction is that having no "Cancel" element scares me: I feel like I'm unsure what exactly (1) I can do to abort my editing and (2) what will happen if I click or tap outside the edit area (i.e., will it automatically save, or automatically cancel)?
    – msanford
    Commented Jan 11, 2012 at 19:10
  • 1
    Taking up too much space? Maybe switch to icons.. Commented Jan 11, 2012 at 19:23
  • Perhaps, but Stefano has said that he wants it to be usable on tablet interfaces as well, which may make for an unusably small tap target.
    – msanford
    Commented Jan 11, 2012 at 19:33
  • Whichever option(s) you may finally decide upon, one thing I would like you to ensure: Never place the Delete button under or replacing another, which is firstly potential hazard and secondly an irritant for the user. We have an app that's been giving us nightmares with 'Submit' (& forget it) taking the place of 'Save' (& return if needed) when the edit mode changes context.
    – Kris
    Commented Jan 12, 2012 at 10:50
  • Sefano, with your second view, I'd also suggest including an Undo on the second row, in the same column as Save. In addition, after a Save or Cancel, set up a delay before the Delete button becomes available. You can make this "pretty" by using effects. That is, someone clicks Cancel, the "Save Cancel" display fades out in 0.5 seconds, there's a 1 second delay, and then "Delete" slides in from the side. Until the slide has completed, the Delete is non-functional. Should be enough time to foil accidental double-clicks.
    – ghoti
    Commented Jan 12, 2012 at 15:41

4 Answers 4


The standard keyboard command for cancellation is ESC. You should be able to map it with JavaScript to act the same way on your page. However, a) not all users know about it and b) your case calls for compatibility with touch-screen devices that don't have it.

As has been answered on another question, an explicit Edit button isn't always needed as long as it's clear how to enable the editing mode. However, an explicit Cancel is a must and an explicit Save is desirable (users need to be told that saving is automatic). These are especially important when modifying domain settings.

I think you should keep everything as it is except for 3 things: 1) make Save green & see if yellowish works for Cancel, 2) increase the delay in switching from Save to Delete, and 3) add a deletion confirmation (if there's none).

  • I've basically done that now, but I did get rid of the edit button. The fact that it doesn't give you any indication of where you can click on a tablet is a bug that needs to be addressed. I guess that leaves me no choice but to buy a tablet. :) Commented Jan 12, 2012 at 0:09
  • 2
    Instead of the delete confirmation you could try for a Undelete command ... when you hit delete it immediately marks that entry as deleted (greying it out or similar) and puts an Undelete link where the Delete link was just then. (Always better to ask forgiveness than permission a.k.a. offer undo instead of dire warnings)
    – Erics
    Commented Jan 12, 2012 at 3:39
  • If you implement @Erics's version, beware, that you'll need to make some changes in your front-end code (configure the delayed sending of the DELETE command to the server) and to test the new code for compatibility on multiple platforms.
    – dnbrv
    Commented Jan 12, 2012 at 4:00
  • You can try delaying the send, but better would be to have the Undelete act as a Set up a new record with all the values. That way if they [something happens] after deleting something it actually gets deleted.
    – Erics
    Commented Jan 12, 2012 at 4:07
  • +1 for Undelete/Undo. People are far too used to "Are you sure" confirmations. If they weren't sure, they wouldn't have clicked delete. It's only afterwards that they discover they were in error.
    – ghoti
    Commented Jan 12, 2012 at 15:43

One possible solution:

1) Clicking/Tapping on an entry enables edit mode.

2) After clicking/tapping away (and additionally after a short delay) the record is saved and a status message in the row displays the "saved" status and at the same time displays and activates an "Undo" button:

enter image description here

p.s. The hover state you mention using to indicate that a row is editable will not work for Tablet users.

  • I really like the idea of automatically saving after some amount of time (with a clear indication). We also have a "save all" button for the bulk-editing use case (it appears when 2 or more rows are opened, and disappears when all rows are closed). Commented Jan 12, 2012 at 0:10

I'd suggest leaving both SAVE and CANCEL there, and then map RETURN to SAVE and ESC to CANCEL. That would cover most of your user's bases.

Alternatively, do away with SAVE as I think most folks understand return (at least in data-entry scenarios) 'commits' the edits. Then place a small 'x' to the right of the field to cancel (also mapping it to ESC).


What about increasing the depth of the entry while you are working on it and including save/cancel underneath - it gains the advantage of easily seeing what is being edited (maybe a little subtle colour queue). Then the delete can stay on it's own, but as others have said still needs a two step deletion process, unless the impact of deleting it not that serious and it is a repetitive task.

Your Answer

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

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