I'm working with some software that uses an HTML form for a user interface to change some configuration information. The back end is a database (loosely speaking).

The front end has a hierarchy of values which can be changed in <input> or <select> fields

When's the right time to push user-initiated changes into the database? There doesn't seem to be a great answer here:

  • when the content of each field changes -- if I go to type the value 1.13e5 into a field, then it will see intermediate values 1, 1., 1.1, 1.13, 1.13e, 1.13e5 written. Those intermediate values are not what the user intends.

  • on loss of focus (typically, user starts working on another part of the form) -- this shields the database from intermediate values during typing, but loss of focus can occur when switching to other applications. Also, it seems weird to use a change of focus to cause a mutation in the database; changing focus seems like it should be a read-only operation where writing values isn't expected.

  • explicit push for each field (editing a field brings up a checkbox, and the value isn't written until the checkbox is clicked) -- this makes it explicit to change values, but somewhat tedious

  • explicit push for entire form (user has to click an "OK" or "Submit" button) -- this makes it explicit, but if there are a lot of values, the user may forget that they've made edits, and could accidentally close the window and lose changes.

Are there examples in the real world where someone has considered these sorts of options and has made a well-reasoned decision? I want to learn from someone else's work.

The admin interface for Discourse uses the "explicit push for each field" approach, along with a reset-to-default element for items that have been changed. This seems like it might be a good idea to mimic but I'm not 100% sure.

enter image description here

  • The back end is a database (loosely speaking). - All a database really is is an information store. That the implementations are generally (relatively) large, slow, and power-loss-tolerant is interesting, but not usually relevant to people on the other side of an API. Apr 13, 2019 at 0:36

2 Answers 2


You cannot save on every change: that puts a strain your resources and might end up with incomplete data. If you need validations, you'll also need to run it after every change, your first option is not good.

Explicit push for each field puts unnecessary work in the user.

Push the entire form at the end is valid, but only for small forms.

Loss of focus is the best approach. This depends on your "save" strategy: you would need a representation of your form in the database and also persist its status (complete, incomplete, valid, invalid...). Don't worry about what you save here, you still need to validate the data. Usually, in these cases, you'll keep the "save" button, but all that'll do is change status and/or validate. Also, this is very good for big forms, or forms that take some time for the user to complete, as you'll have a way to provide a 'resume' or 'continue' functionality.


Your problem description is pretty thin, so it's hard to tell which approach works best for your users. Since you mentioned configuration information, I would assume that user input has to be validated so that you don't store inconsistent data.

Saving the data explicitly with a submit button is probably reasonable. You might use visual feedback in the form to signal changed data and invalid inputs, enabling the submit button only when there are changes and the entered data is consistent as far as your frontend can determine.

In any case, be prepared for a few rounds of implementing a form, testing it with actual users, and analyzing the usage patterns to improve.

Regarding real world examples: Most UX designers will probably have considered the options and made a reasonable decision, but you will still find bad examples all over the place. Use examples such as that of Discourse to learn about options, but don't simply copy them. Find out what works well for your application and users.

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.