The difficulty in removing software artifacts
As software advances, programmers become more aware (and less apt to include) artifacts of past programs. My favorite example of this evolution is the “save” button. There’s no intrinsic need for it anymore—developers have been building software for years that saves every keystroke—but there’s no denying that I’ve developed a behavioral reliance on the button. If I don’t see it when navigating away from a page I’ve changed, I feel uncertain. I worry that my changes are gone, and sometimes I even will go back to check that my changes were in fact saved.
Why does this happen? Logically, I know my computer can save without my telling it to. But I’ve developed a mechanical association here: I hit save, the computer writes. To my mind, save (digital) = put it in the drawer (analog). Leaving a page without hitting save feels to me pretty much the same as leaving my desk without putting away a page of handwritten notes.
So for me, at least, adding the ability to save a document in real-time (without my direction) doesn’t streamline my experience, it makes it more uncertain and slow, what with the hesitation and additional checking that it was saved). But removing the save button is progress. The button is, at least technically, unnecessary. How, then, can developers replicate the feeling of security I get from hitting “save” without, you know, having me hit “save”?
My suggestion (and it’s not a great one, it may not even be original, but I think it’s the right idea): include a small piece of text in the bottom-right where the save button usually sits. This text will say (in red) “Changes not saved” when the user is typing, and a second or so after the user finishes typing will switch to (in green) “Changes saved”. Yes, it’s technically unnecessary, but it’s behaviorally reassuring, and that’s what matters to actual users. Streamlined engineering does not always equal enhanced usability.