UI Design / Flow - what should "Save" and "Cancel" do?

Question

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:

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.