In my application, I am providing a ticket form that the users can go back and edit. I had designed it so that they can change one to many fields without real-time saving by providing a save and discard changes buttons. It is obvious to the users if they are viewing a modified form by providing an obvious asterisk.

I am second-guessing this approach and wondering if it might be better to save after each inline edit? By doing so, it seems like the only effective way of accomplishing this would be to provide a save/cancel option on a per field basis during the editing process -- similar to what JIRA does.

enter image description here

Is the above way the only effective way of doing real-time editing? Or is simply saving the new fields on blur good enough (so long as the user expects this behavior)? The only issue I can see saving in real-time would be if the user assigns the ticket to someone on mistake and email notifications are mistakenly sent out as a result.

Am I overthinking this, or is one way truly better to the end user?

1 Answer 1


You can save on blur and provide an undo function to return to the previous state.

Auto-save states

There are scenarios where you want the user to be very certain they want to change things (like admin panels). I think an explicit save command with "draft" save is appropriate there.

  • Thanks for your comment -- I really like that idea. To clarify -- would it be necessary to provide an undo button next to each control that was changed? Also, if they change an input two times, should the undo button persist all the way back to its original state? Commented Dec 2, 2015 at 20:14
  • The details depend on your context. You could hold the aggregate changes in memory while the form is open and allow a total reset to "last commit" to use an excessively technical term. Field-level undo is nice, but might be overkill. Commented Dec 2, 2015 at 20:47
  • +1 always save anything a user inputs because we are thankful they took the time to input anything. Just make sure there is a undo recent changes button so users have a way back to the original state of the page when it first loaded. super granular undo/redo can be very tedious or very helpful depending on the context. I would start with a page level undo unless there are a ridiculous number of fields all of which the user expects to be there and wants to edit. Each input is a barrier so it should be very clear to the user why you are asking them to enter anything at all.
    – DaveAlger
    Commented Dec 3, 2015 at 1:29

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.