When do you save an editable form when some of the information has been saved?

Question

I'm designing a webapp that basically is patient tracking. We are in a claimant's "clip board" and it has all of the patients information. There are forms and there are some grids.

We currently cannot autosave.

This is an example of our health history screen. You can edit the grid, without being in edit mode. When you click the edit icon next to a field, you can edit that field.

When you press cancel, after you have edited a grid, do you expect changes to be lost in the grid and the form, only in the grid, or only in the form? See the example on YouTube.

Answer 1

For a good design giving feedback to user is most important. You can give a message with timer like

Your Changes will be Auto Saved in 58 Sec..(Timer keeps on decreasing)

On the header bar along with the Save button. User can click the Save button any time but the auto save will be done after every 1 minutes. This way you are not forcing user to keep on saving also he can see visually what he is writing is backed up.

Answer 2

With regards to your question "When you press cancel, after you have edited a grid, do you expect changes to be lost in the grid and the form, only in the grid, or only in the form? "

Since the action is inline and specific to the row in the grid, your cancel or negative action should only revert back the changes made to row in the grid. So if you edited a particular row and then pressed cancel,the changes made to the row should only be discarded. This is becauses users have a cognitive understanding that the actions they are performing are specific to the particular section and undoing every change on the page or the entire grid can cause confusion. To quote this article about inline editing

The Inplace Editor pattern allows for localized editing of elements on the fly. The pattern provides ease of editing by placing the controls right next to the elements they affect.

Also since your edit icon is next to the row, due to the law of proximity, users assume that the elements are related. To quote this article on Gestalt principles.

The Law of Proximity indicates that elements that are near to each other tend to be perceived as a single unit.

That said, there are some UI changes you can make to ensure your experience is more obvious

1. Your top edit gives the visual understanding that I can edit the whole page with it while it allows me to only edit patient details at the top. If the objective of that edit functionality is to only allow users to edit the top section, ensure that is obvious

2. If you want to allow users to edit at a grid level, you should section your grid and allow user to edit at the grid level and not individual items.

Facebook does this by placing the edit functionality inline with the title allowing users to form the correlation between the title and the action

Answer 3

I'm not sure that I fully understand your question but my interpretation of it is "When should an autosave enabled page trigger the autosave mechanism?"

If this is the case then it depends on your use case and the amount of processing power your users will have access to:

Ideally, you would work like Google Docs where every single keystroke triggers an autosave.

However, this may be processor intensive depending on how it is implemented and where and how you are storing the data.

An alternative might be to save every time the user switches focus away from the current field. This means that the save mechanism will be triggered less often and therefore will be less processor intensive but it will only capture completed fields.

The most processor-light option might be to trigger autosave only when a complete section has been completed although, with this method, you would have to be sure that your users would always complete in full sections and not be distracted and leave something half completed (I suspect distractions would be very common in a medical/health setting so do not recommend this course of action.

One thing I would add is that I have noticed that, in some cases where the autosave is completely invisible, users still want a 'save' button to reassure them that the form/document is definitely being saved - I would suggest including this in your testing.