1

I have a form with the normal sets of controls (checkboxes, select dropdowns, text input, etc) and i also have a table inside of the form so it looks like this: enter image description here

to Add / Edit items in the table, you click on "Add Person" button and that displays a popup dialog like this:

enter image description here

once you click "Add", it creates a new row on the table.

My issue is that the table is just stored locally and only gets saved when you click "Save Form". This issue is that many users have gotten confused by going into a form, adding a few people (rows on that table) and then leaving the page (assuming that by clicking "Add" in the dialog and seeing the row added to table means that this data is saved to the backend as well). They didn't realize they need to click Save Form to actually persist the changes.

I wanted to get suggestions on what are good UI options to make it VERY clear to the user that until you click "Save Form" you have not persisted any changes?

For those who suggest to save upfront, Note that these "sub records" have a relationpship to this forms main entity so I can't save these subrecords until they have a foreign key of the main entity to align with. I guess i could save a "partial" main entity but that seems like it will get messy result in a lot of unnecessary persisted data.

5

In some cases you may want to reconsider the requirement for explicit saving and go with implicit saving instead. (Counter example is applications where it is important for all the data to be saved at once due to relations between the various records.)

There are various practices that I have seen for indicating that the data has not been saved, which I will list shortly, however, first:

Consider preventing closing the window without first showing an alert that the data has not been saved and providing the user with the options "Save and then exit", "Don't exit", "Exit without saving".

Practices I have seen for indicating that the data is unsaved:

  • An asterix preceding the window title and any unsaved field.

  • Different formatting for unsaved fields and title (e.g. italic).

  • Postfixing window title and unsaved fields with the word "unsaved"

  • Disabled save button becoming enabled

  • Exit/close button becoming "disgard and ..." button

To make sure the users don't miss these indicators, you should probably use as many of them as possible in combination with the alert if closing/exiting when unsaved.

  • I updated the question a bit at the end to note that these sub records need to be related to the main form entity so i can't save them until the main entity exists in the db. – leora Jun 3 '14 at 3:11
  • @leora The result of my answer is still applicable, including the part about when implicit saving shouldn't be done (which is applicable in your case). – Danny Varod Jun 3 '14 at 9:24
0

Perhaps you are asking the wrong question here? Instead of asking how to make it clear the data wasn't save, you should comply with your users' mental models, which I suspect are very logical with such data driven applications.

This type of flow is very common in many applications - to add a particular record users may wish to create an associative record. For example, when users creates a new invoice, it well may be they wish to add a new customer. Invoices and customers have separate stores - each has its own DB table, they have many-to-many relationship, and you can add or access customers elsewhere in the interface, but also 'on-demand' as you add other records.

If a person can exist elsewhere in the system outside a form, and if the list of persons is accessible or needed anywhere else (many-to-many), it seems to me most logical that if users add them, they are added straight away (save to the DB), regardless of whether or not the form is saved.

The only case where you should only save the persons added when saving the form is when those person have association to that form only, and nowhere else. In other words, one-to-many relationship - a person can only be part of one and only one form.

  • in my example the rows only have a relation to this form so i can't save upfront because i dont have the SAVED entity in my db yet . . . I have updated the question to highlight that point. – leora Jun 3 '14 at 3:08
0

How about show a confirm box on cancel or exit of your form

mockup

download bmml source – Wireframes created with Balsamiq Mockups

  • IMO - I would try to only use popups in cases where no other option seems better. They aren't always the best choice since they interrupt the users workflow, and what's worse, often popup to interfere with a command that the user really wanted to perform. Side note - if a popup is used, always try to label the buttons to the action they will perform. In this case, "Yes" could be replaced with "Close without saving" or similar. – Henrik Ekblom Jun 3 '14 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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