I had a discussion with a co-worker earlier today about a design pet peeve of mine, and after some searching regarding UI design principles I can't really find anything regarding this particular scenario.

In many applications (mostly web, but windows as well) I see a form that allows the user to add/edit/delete rows of data. This form has "Save" and "Cancel" buttons that only affect the editable fields - record addition/deletion occurs the instant a user clicks "Add" or "Delete".

Example: Sorry, I'm not an artist

In this case, what should the "Save" and "Cancel" buttons do?

  • My position is that the "Save" and "Cancel" buttons should affect everything (every editable field and every add/edit/delete action) on the form since contextually there is nothing to indicate that they only affect a particular set of actions and/or fields.

  • My co-worker's position is that it's completely understandable that the "Save" and "Cancel" buttons only affect the fields, and that users won't really notice that additions/deletions are persisted without clicking "Save".

I realize some of this may be "what do the users want/need", but I'm curious what other developers think.

5 Answers 5


I feel an ambiguous design is a bad design.

Make it clear to the user what will happen. Perhaps an 'add' link in the row you're modifying. Or use ajax like functionality to add it on the fly (this becomes harder when you require data for certain fields).

Or color the row a different color when it's unsaved. Or fade from green to the normal color after it's been added. The cancel button, if clicked, should alert the user that unsaved data will be lost (whatever that actually means in this scenario). It might say "the following records will not be saved..."

The fact that both of you disagree means users will also. And a surprised user is an unhappy user.

  • Out of the answers provided, this seems to make the most sense - there are times where this approach may be the best, but the interface should always be clear about what's going on. Right now, my concern is that it isn't clear and the users (notably the CEO, President, and Board of our mid-size company) will end up fighting with the interface instead of getting their work done.
    – Paul K
    Commented Jun 29, 2012 at 0:46

Your coworker is right; Save and Cancel should only affect field edits, not additions or deletions. Additions and deletions are perceived by the user (and generally implemented) as separate operations.

Conceptually, a record must be added to the database before you can perform an edit on it, so to implement a save in the way that you propose requires that you wrap the entire thing in a transaction.

Remember, the user can always undo a record addition by deleting it. So conceptually, the "Cancel" is the Edit undo, while the "Delete" is the Add undo.

  • What is wrong about wrapping all of the edits in a transaction (not necessarily a DB/distributed transaction, but using some sort of marker for what needs to be committed when the user clicks "Save")? It sounds like this is a case of differing POVs - I see the form as a set of actions that should be handled together, while you and my co-worker see them as individual actions that aren't necessarily related. Maybe this even calls for different button placement/notification much like what Mike suggested. Does that sound like a fair assessment?
    – Paul K
    Commented Jun 29, 2012 at 0:06
  • I'm not comfortable with undoing that much all in one shot. If a user does a whole bunch of work, and then hits cancel by mistake, he's going to be pissed. Regardless of what others are saying here, data grids are almost always designed this way; they are "record-centric," and this is how the general public has become accustomed to using them. Commented Jun 29, 2012 at 0:09
  • I understand your point about accidental data loss, but I wonder if we sometimes hold the users' hands a little too long. I agree that many grid-based entry forms are implemented as you describe...but it seems like a lot of times users will accept what they're given to use unless it is extremely user-unfriendly. I mean, we're not all user experience gods, but the first answer surely shouldn't be "I've got a grid for that". In any case, I think Mike hit the nail on the head - it's not so much a bad overall approach as much as the intent isn't very clear.
    – Paul K
    Commented Jun 29, 2012 at 0:43
  • @PaulK Why don't you just run a test to find out what makes the most sense to your users? Commented Jun 29, 2012 at 1:14
  • @superduperfly Let's just say where I work some of the project managers like to design in a bubble. In this case, I asked my co-worker what the users thought of the interface and they showed me a sample screen that looks nothing like the current iteration; the users have signed off on what was proposed to them but haven't seen what's actually being implemented. This means that a lot of our developers' designs become a "best shot" at what we think the users will like/want. I've tried changing the mindset to encourage more end-user interaction, but have failed so far :(
    – Paul K
    Commented Jun 29, 2012 at 11:14

My take is that tables should not be used for editing data in the first place. They should be used for displaying data and selecting records. Forms should be used for editing data. If you really need to do some serious data manipulation in table form, you want a full featured spreadsheet application like Excel, where you can rapidly edit columns of data. But for any sort of typical user interface, tables are just not used to edit data. Think about the web apps you use every day, whether it's social networking, email, Q/A sites, banking, etc., I can think of no examples where a user is asked to edit data inside a table. And except for Excel or apps used by programmers, I can't think of any desktop applications either.

This is the reason the Save/Cancel buttons in your example don't really have an obvious function. What's really going on is that the table is allowing the user to view/select records and edit new or existing records. If instead of editing the data in the table, clicking the Edit button took you to a new page with a form for filling out/editing the data, the Save/Cancel buttons would make perfect sense (technically, I'd recommend "Save" for editing and "Submit" for a new record, but you get the idea).

Anyway, if you're going to insist on using a table for editing data, I'd say your coworker is probably right: Save/Edit refer to the editing of the record only. But it's likely to be clunky and confusing to the user either way, so I'd recommend going with the tried-and-true form interface if you want to ensure usability.

  • The (internal LOB) application in question is dealing with tabular data that needs to be looked at and manipulated as a set. I'm also not one for in-line editing in tables, but in my opinion there are definitely times where it is not only permissible but necessary.
    – Paul K
    Commented Jun 29, 2012 at 0:19
  • It sounds like you've given this some thought. I may have oversimplified. Just out of curiosity, can you provide a specific example of something a user might need to do where the table is the better editing tool?
    – devuxer
    Commented Jun 29, 2012 at 0:24
  • One example (not this application, though) would be a statewide system for annual financial reporting - basically take a 17-page financial report on which a municipality or county must provide details about their income and expenses and put it on the web. The UI should be designed so that it doesn't make data entry any more laborious than it already is due to the sheer amount of data involved (~1000 points of data). I think clicking back and forth between pages would getting annoying somewhere around the 90th line of data on section four...and only four more sections to go! ;)
    – Paul K
    Commented Jun 29, 2012 at 0:39
  • When it comes to massive data entry tasks, you're definitely right that you want to minimize clicks. I still wonder, though, if the table format is the best way to achieve this. I could see optimizing a form interface by including a button that lets you save the current record and immediately start a new one with a single button click. The advantage of a table is to the see the context of the surrounding rows while editing. If this isn't needed, I think it's still not worth it. Even if it is needed, there may be ways to include some context on the same page as the form.
    – devuxer
    Commented Jun 29, 2012 at 0:55

I disagree with @Robert Harvey, specifically the statement.

Remember, the user can always undo a record addition by deleting it

Whilst new records can be 'undone' by deleting the record there is no way to revert the delete action. You can include a standard "Are you sure you want to delete this record" but imagine this user experience.

  1. User deletes a record and confirms the delete.
  2. User freaks out as he/she was editing the "wrong" record and wants to cancel their action.

In the above example it is too late and cannot be undone as the delete (or add) action has already been persisted to the database.

I agree with your position from a view of transactionality. The record is not complete unless all of the information is persisted.

  • What you described might be true but consider this scenario: 1. User adds multiple records 2.User accidentally clicks the Cancel button If the entire form is a single transaction, the user just lost all the added rows as opposed to one. Commented Jun 29, 2012 at 1:07
  • That's why a single Cancel action is not what you want. You want a real Undo that works for all modifations: additions, deletions and row edits.
    – André
    Commented Jun 29, 2012 at 8:34
  • @André This crossed my mind as well, and what I was alluding to in my responses to Mike and Robert Harvey above. Think of an application like Word - you can lose a LOT of work that can all be lost by clicking "No, I don't want to save" when exiting - Word gets around this via autosave/recovery. If the data is THAT important and/or time-consuming to enter that it simply can't be lost via a single action then the application should account for this requirement (in a manner that doesn't get in the users' way).
    – Paul K
    Commented Jun 29, 2012 at 11:21
  • @superduperfly The implementation of a "transaction" doesn't necessarily need to be a true transaction. It could be a record (or set of records) in "pending" status - you still persist data to the database so the user gets the security of not losing anything but it also give them the ability to re-start from scratch (by dropping out all "pending" records). This was the point of my response to Robert Harvey - we assume the users simply can't stand to lose "that much" data, but how many times and in how many ways do we really need to ask someone if they are sure they want to continue?
    – Paul K
    Commented Jun 29, 2012 at 11:33

I would propose the following scheme:

  1. Wrap all edits in a transaction at the interface level, so save means save and cancel means cancel.
  2. Add undo/redo functionality for all changes at some suitable granularity (probably not individual characters).
  3. Persist the changes on the server, even if they haven't been saved. If the user wants to go back to the previous version, they can always click cancel.

This scheme would work with tabular editing, as well as the single item editing proposed by DanM.

I base this on my recent experience with a similar UI, where I was supposed to enter grades and feedback for students. The system did not persist the feedback on the server as it was being edited, which meant that I had to either publish incomplete feedback or store it locally. It seems as to me that there would be similar issues for a user who enters many data items and would like to retain undo functionality. Having to save/publish the changes after each item defeats the purpose of having undo or cancel.

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.