Run-time "options"/configuration

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!
.

Relevant Pages

  • Re: [Dapper] Mouse
    ... Preferences> File Management> Tab Behavior> Single click to activate ... that it is hard to let go of old behavior, but please: point newbies to ... They are why they use Ubuntu in the ... always use a GUI instead of a command line for my own work. ...
    (Ubuntu)
  • GUI output
    ... preferably to a larger main GUI. ... 'datasource'. ... When the preferences are selected I output them using the code ... i get this error message ...
    (comp.soft-sys.matlab)
  • Re: GUI output
    ... > preferably to a larger main GUI. ... > using varargout within the smaller gui's code. ... > When the preferences are selected I output them using the code ... > so that they are all within one output which is a cell array. ...
    (comp.soft-sys.matlab)
  • Re: Mailbox user limits
    ... It was simply that the preferences for that specific user weren't ... yet when the user had loaded up 1.5Gbs worth, ... I checked the counts from the SBS gui. ...
    (microsoft.public.windows.server.sbs)