0

Please don't throw this away

The “Save” command in desktop software is a consequence of hardware design. Because primary storage (RAM) is fast, but expensive and volatile, and secondary storage (hard disk) is slow, but cheap and permanent, there is a trade-off between the choice of primary vs. secondary storage. Hence the “Save” command, which instructs the computer to move your data from primary to secondary storage.

But as Cooper argues, this is idiocy. Why should you as a user be bothered with this? When you enter stuff into a computer, it’s usually because you want the computer to keep it for you, not because you want it to turn around and throw it away.

Thankfully, lots of modern software doesn’t in fact bother you with this. There’s no save command, the software automatically saves your work for you. But this bargain only works if you can be reasonably certain that it will in fact save it for you.

Most software sans Save will only transfer from primary to secondary storage on exit, which means if the software crashes, either because it has a bug, or because some other software has a bug and brings this software down with it, you’re out of luck. You might lose hours and hours worth of work. This is even worse than the Save command, because this forces users to routinely quit and relaunch theirs apps, just to safeguard our data—a Save button, while still idiotic, is certainly less so.

So here’s what I want to ask of software makers: Save our stuff on a regular basis, not just on exit.

Transfer it from primary to secondary storage every minute or so, when there are changes to data, in the background. It should be fairly trivial and computationally cheap to have a dirty flag, so you don’t need to do this when there are no changes, and to check that dirty flag every minute, to write the latest version to disk, so you’re secure in the case of a sudden crash. In the trade-offs involved in software design, keeping your user’s data safe should always take priority. If people lose their data, your app is useless.

6 comments

Branimir Dolicki
 

Lars, As far as I could tell iTunes and iPhoto save pretty much everything all the time. Which applications have you found to save only on exit?
Read more
Read less
  Cancel
Lars Pind
 

I've lost data with iPhoto -- I deleted a bunch of photos before it crashed, and the photos were gone, but the thumbnails were not, and they still showed up in the index; with NewsFire, which will forget new feeds and what I've read in the last session when it crashes; and latest with BurnoutMenu, which admittedly is in Beta, but that should still only be even more reason to make sure your users' data are safe.
Read more
Read less
  Cancel
Christina Wodtke
 

An interesting question is how to do this with webaps. How many times do you compose a long entry in MT or a long email in hotmail only to lose it? There has to be a way....
Read more
Read less
  Cancel
Lars Pind
 

You could in fact do that fairly easily with Ajax. That's an excellent idea! And thinking about it, it would be an awesome thing for Rails to support natively. I like!
Read more
Read less
  Cancel
Lars Pind
 

... turns out there is, and it's a method called "observe_form". Thanks to David HH for pointing this out. Now on to it.
Read more
Read less
  Cancel
Branimir Dolicki
 

This is also an issue of atomicity when dealing with files. A transactional filesystem that would guarantee that deleting the photos, AND thumbnails, AND updating the index either all succeeds or fails seems to be the only solution to what happened to you in iPhoto. Still, it *is* a user interface issue, the transactional technology in such application just doesn't seem to get the priority it deserves.
Read more
Read less
  Cancel

Leave a comment