DRAKON Editor does not have a “Save” button. The changes are saved automatically right after they have been made. It means that the reflex of pressing Ctrl+S every three seconds is not needed any more. The horror of losing your long hard work is gone.
The only reason why this “no save” principle is still not widely followed by desktop software is tradition. A long, long time ago, when hard disks were slow, saving was a major undertaking that required an explicit command from the user. Nowadays, when computers have become fast, it is easy to make the machine grasp every little input from the user and save it permanently.
Saving must be done automatically after each action of the user. In order to make saving unnoticeable and fast, a few guidelines could be followed:
Save only the interesting things. A program might have huge amounts of data in its working memory but only a small part of it contains the original information. The rest is a reflection of that original part and can be rebuilt from it. Let us take an ellipse on the diagram as an example. The ellipse is stored in memory as an array of vertices in order to be drawn on the screen. The vertices occupy a lot of space but they functionally depend on the relatively compact logical representation of the ellipse. Saving could be made much faster if the representation of the shape is written to the disk instead of the vertices.
Don't save the whole file. Save only the latest change. Normally, large documents take a long time to save because the whole file gets rewritten. This is obviously redundant work. The user does only one thing at a time and it is that little thing that needs to be saved. Of course, the file format must support partial saving. Zipped XML, for instance, is not particularly good for that. DRAKON Editor uses Sqlite for persistence and there are good reasons for that. Small partial saves can be easily implemented with Sqlite using inserts, deletes and updates. Another useful thing about Sqlite is transactions. Even if your software crashes, the user's work will be preserved.
Save when the user stalls. No matter how fast users work, once in a while they make pauses. Sometimes they need to stop in order to see what they have done, sometimes they concentrate and think about what to do next. These short breaks are natural points when saving can be carried out without interrupting user experience. For example, each time the user drags something with the mouse, there is a brief pause after the user has released the mouse button. There is no need to save the document at every mouse move event, but no one will notice if the program saves the result of the drag-and-drop operation right after its completion.
The “Save” button is obsolete. Pressing “Save” is boring and stressful work. Boring work must be done by the machine.
Posted: May 30, 2012
Copyright 2012 Stepan Mitkin