| a sense of history |
May 30th |
| Submitted by Michael Bayne <mdb@go2net.com> to UI. | |
An increasing number of people who claim to know a thing or two about user interface design are clamoring for the widespread use of what they like to call memory in an application. The essence of this is that things stay how you left them. If you had selected portrait orientation the last time you brought up the print setup panel, it should still be that way next time you next open that panel. In fact, it should be that way whether you open the panel again 20 seconds later or 2 months later.
The motivation behind such a view is that whatever you did before, you're likely to do again. There is nothing more annoying than having to repeatedly adjust a senseless set of default settings time and time again when performing a common task.
Most people stop at this point and don't feel the need to go beyond the whining stage. I would like to look a little deeper into the issue. Why don't people write applications with memory? It's not really that hard. You have to initialize most everything anyhow. Why not initialize it with the last used setting? The reason it is not commonly implemented is because it's a pain in the neck to do this stuff by hand and no simple framework exists for storing and restoring settings.
I contend that if such a framework existed, people would make use of it and with nearly no effort at all, Mozilla would be a veritable elephant when it comes to remembering how it was last used. Let me describe the desirable characteristics of such a framework:
- There should exist a single call to store or restore any of a useful
set of the common datatypes (integer, string, double, array of integer,
array of string and so on). For example:
int width = SETTING_GET("width", 25); /* do do do */ SETTING_SET("width", width); - The get/set calls should be macros so that they can store the settings scoped to that source file. This prevents potential name collisions between use of the settings services in one source file and another. A version of the macros could exist where the scope was specified explicitly for cases where settings would be stored or restored across different source files.
- No explicit saving mechanism should be necessary. The design assumption here is that these calls are not frequent. Values only change when the user changes values via the user interface (which is an infrequent action by any measure). Either every call to the set macro can result in the storage of the settings to disk, or a background thread (or other periodic mechanism) could be used to flush the settings to disk after a few seconds of inactivity.