Hi,
I'm trying to come up with an *intuitive* way of handling "options" as they pertain to run-time operation of "programs".
E.g., in a command-line driven environment, these would be "switches" specified on the command line which would follow the "program name" ("dir /AH /B", 'find . -NAME "*" -PRINT', etc.).
In a GUI environment, they would be checkboxes, radio buttons, listbox selections, etc.
There are several issues that are interrelated.
First, defining the "default" options and conveying those to the user. In a GUI, this could simply be "whatever the controls/widgets *appear* to indicate when you initially open the dialog". In a CLI, usage() can be crafted (by convention) to disclose the default "switches".
Second, differentiating these defaults from the user's "preferences". Depending on the application, it is likely that the "system defaults" are inappropriate for every user's needs. This could involve automatically
*loading* the user's preferences in much the same way as the system "defaults" are "loaded" (e.g., ENVARs and .rc files for CLI's; "registry settings" for GUI)Third, handling the persistence of those preferences. Each invocation can resort to some preset configuration which might reflect the *last* (previous) invocation, the user's preferences *or* the system defaults. Of course, there is also the possibility of "named configurations" (i.e., templates) -- and the whole issue of defining those.
Finally, the interrelationships of options is, perhaps, the trickiest to convey to the user. I.e., making him realize the "consequences" of particular option choices. The 1960's approach is to just squawk after the user has chosen some "unsupported" combination of options. In a GUI, you could automatically adjust *other* options consequential to particular choices as they are made (and hope the user notices these changes!).
[This has a significant impact on how templates are supported and maintained!]A more sinister aspect of this is ensuring that all the affected options are *visible* to the user. I.e., if an option on a different "page/dialog" is changed as a result of a selection made on *this* page/dialog, the user's attention must be drawn to that other page/dialog.
[E.g., imagine changing the "output file type" for an application and then having a whole slew of options PERTINENT TO THAT FILE TYPE that need to be addressed... often on a separate dialog/page that you have to manually explore]The simple solution to this mess is just not to give the user any choices! :> The next less-mindless solution is to only have "system defaults" and force these to be restored each time the "application" is invoked. (Nero takes this approach -- making it far more tedious to use than it *should* be!)
For infrequently used applications, I think simple/mindless solutions are (marginally) acceptable. The user doesn't have to remember *why* he may have changed a particular option from its "system default". OTOH, it may be expensive for him to rediscover why that change *is* desired (arguing in favor of restoring user preferences).
But, for things that are used *heavily*, it seems that you really want/need a means of letting the user quickly and reliably getting to the particular option set that he wants
*without* having to study a series of dialogs, option pages, etc. (This is especially important of conveying the current settings to the user is an "expensive" operation -- remember, these aren't desktop applications!)I'd appreciate pointers to any applications that seem to have addressed this sort of issue successfully. And, any suggestions as to other ways that might improve on this sort of thing!
Thx!