Is the save button still needed in modern web applications? In this article I take a look at a case study to find out.
The Problem: Where to Put the Save Button?
A few years ago, I developed a web application for a Residents Management Association. Volunteers handled the administrative work of this self run estate. A husband and wife team dealt with all letters, mailshots and billing. The problem with this setup was if the husband and wife go away on holiday. They couldn’t access their files while away but estate management doesn’t take a break.
The solution was to create an online system they could use on their PC and their phones when out. The design process was simplified by the fact that the number of properties they manage are static. There will never be more or less properties on the estate than there are now.
An important factor was the UX (User Experience), especially when viewed on a mobile platform. Where do you put the controls, especially the Save button? The majority of the controls went on a sidebar, always displayed on larger screens but hidden behind the familiar hamburger icon for smaller ones. However, this did not feel like the right place for the Save button. The Save button shouldn’t be hidden behind a pop-out sidebar.
The Solution: Remove the Save Button
The Save button became quite an important consideration for me. I then had a moment of inspiration. Every field on screen could be directly related to an already populated field in the database, in a preexisting record. So why is a Save button needed? Why not immediately post changes back to the server as soon as the user has finished making them?
I had to give this more thought, what were the implications? The normal convention is to always press save after making a change. But by eliminating the Save button, the user is saved the task of locating the button – which can be a chore on a mobile phone – and clicking it. I could see a bonus to this: by sending changes to the server as they happened, smaller packets of data would be sent. This would happen asynchronously too, the user wouldn’t even have to wait for a response from the server before moving on to their next task.
Could This be Reused?
All this might seem irrelevant to other applications, where the number of records are dynamic. Is the save button still needed? Surely the answer is yes? I started to think about how the same methodology could be implemented in more conventional systems. I came up with the following methodology:
- Create a blank record before starting the editor.
- The database record stores who started to create the record, along with an unfinished status flag.
- Data in it is posted back to the server per field.
- As soon as the last mandatory field has been populated, the record is marked as finished.
- Lists do not included unfinished records.
- If there is already an unfinished record, the user is presented with it.
- You can even play housekeeping by storing a creation date on the record, and removing unfinished records over a certain age with a cron job.
So, have I convinced you that the Save button is redundant? Well, to be honest, I have yet to convince myself. Save buttons could still have their place in dialogue boxes. Then again, perhaps that is another convention that could face change in the future.
SAMWare UK creates bespoke solutions and websites. Contact us to arrange a chat to discuss your needs and for a free no obligation quote.