Validating and (auto)saving data records created by user

Question

My application provides a functionality for the user to add, list & handle (remove/edit) data records which represent address data.

I just had a dispute with my trainer, who I have asked about his opinion on my "address record module".

Each record has 5 properties, each of them is set by the user:

• ID
• Name
• Street
• Postal code
• City

Note that ID is not used to identify the record in the database. It's purpose is to identify the record in the users workflow.

I have made the module like this:

If a new record should be added, the user has to click a button that reads "Add new record". This will add an empty block of address data to the top of the list of records.

Each record provides a removal button on the bottom right corner.

I have neither implemented validation, nor a save button.

Whenever a change is made in one of those 5 text inputs, the record will update in the database and a small notification will inform the user of the succeeded saving of the changes he just made. To avoid annoyance, this message is quite discrete and will show up only when some time has passed since the last update.

My trainer argues that this is bad practice as the user will be able to insert empty records or such that lack "necessary information". He also told me that due to the lack of comprehension for such uncommon experience, the users would rage about the missing save button.

Though, I believe that my approach is actually improving the users experience. If one would add a record that is missing data, they should either have a reason for that (maybe they don't know the street name yet) or the could easily fix the issue by just adding the information or removing the record. Even a missing ID is not a problem, since the database uses an internal one.

The lack of a button to save the record should be no problem due to the visual provided information that a record was just updated.

Should I implement the oldschool method nonetheless?

Answer 1

Should I implement the oldschool method nonetheless?

Consider both a save button and auto-save. If you look at this from the perspective of trust, some users want to be sure that the system accepted their input. The lack of a save button puts doubt in their mind.

This topic reminds me of the question "Why do people clear the screen multiple times when using a calculator?" It comes down to how sure the users are that the system did what they intended it to do.

EDIT:

I should add that Google Docs previously had both a save button and autosave. The save button was eventually replaced with this below text and corresponding hover state:

It's where you expect the save button to be for users looking to ensure their changes are saved. It's a compromise between autosave and save buttons to avoid confusion on the state of the system.

Answer 2

There's two issues here, one is the fact that some users expect a SAVE function, and the second is the validation.

My thinking is that SAVE was a work-around from its beginning: When I write something with a pen on a paper, it's there. Without SAVE. Saving was invented for time-sharing terminals, more generally termed SUBMIT in these times. I guess the user expectation is changing quickly with the rise of mobile apps. And I really like if I don't need to care about saving. Be very sure to add an UNDO if you have no SAVE, however.

Validation depends on the usage of the record entered. If you want to send a parcel, the computer will be hard pressed to print a parcel label... So, yes, it's nice to let the user create drafts to be completed once the information is there, but this very much depends on the process behind the UI.

So my recommendation is to do validation (if any) and saving whenever the cursor leaves a field. If you can hold saving as long as the cursor goes to another field of the same record, you can do so to limit transitional messages.