Definitions: (the discussion that follows tries to be strict to these.)

• A setting is any parameter on an application. For example, there is a setting in the tracker's window menu for how you want the view to look.
• An option is a particular potential value for a setting. In the tracker's window menu, "Icon View" is an option. "List View" is another, different option. Both are potential values for the above setting.
• A preference is any setting that can be expected to persist from one application invokation to the next. A preference defines the default option for a setting. This is the value used when the application begins. Some applications have settings that do not persist, these have no preferences corresponding to them.
• A configuration is a complete set of preferences. A configuration defines the default options for all of an applications settings that persist. Some applications have default options for settings which could have corresponding preferences but aren't required to. In this case, the preference may or may not be in the configuration. If it is, then the option in the preference will be used for the setting. If it is not, then the default option that is stored within the application will be used.

Examples of current practice

Here are a few examples of different preference editing modes in beos:

• BeShare - no preferences dialog, all preferences edited through menus, saved in a single file: /boot/home/config/settings/beshare_settings
• SoundPlay - some preferences on a Settings menu (repeat, smooth pitch changes), others in dialog at Settings->Preferences. The dialog uses a tree widget at the left and varying panes on the right. SoundPlay also has a Skins menu which could be construed as a preference.
• Gobe - File->Preferences dialog. The dialog uses a tree widget at the left and varying panes on the right. The dialog also includes 4 buttons: "Factory Settings", "Revert Panel", "Cancel", "Save".
• The kernel - /boot/home/config/settings/kernel/drivers/kernel text file lines are commented in or out and variables changed. comments in the file explain the options. third party applications are available to change at least some of these preferences. BeTweak or PrimalToys, for example.
• OpenTracker - mount related preferences on File->Mount Settings... dialog. Dialog contains 2 radio button sets and two buttons: "Mount all disks now", "Done". Other preferences on Window->Settings dialog. This dialog uses a list widget on the left and varying panes on the right. There are two buttons in the dialog: "Defaults", and "Revert".
• Mouse preferences app - One dialog, no varying panes, no multiple tabs, two buttons: "Defaults", and "Revert"
• StyledEdit - settings are not persistent. possible one could consider the default font, line wrapping, and alignment as potential preferences, but they are not stored. these are all changed directly on menus.
• Network panel - multitabbed dialog, one tab includes a configuration management system (backup, restore, delete), the dialog includes buttons for "restart networking", "revert" and "save". revert reverts all tabs, save does similarly. using the close box prompts for a save before quitting. this dialog also includes a nested preferences dialog for each network card.

Comments on existing practice

It is obvious off the bat that there are a lot of different metaphors at work here. Aside from the obvious distinctions between hand-editing files, preferences on menus, and dialogs, there are also more subtle issues.

Some of these dialogs are "live". If you change a dialog setting, it is instantly applied. An example is the mouse dialog. Change the "Focus follows mouse" drop down box and instantly the mouse behavior changes. There's no need to click an "apply"/"ok"/"confirm" button. There isn't even a need to close the dialog.

Some dialogs have buttons to change the settings to some sort of "safe" standard. This may be the original settings that the application shipped with, like "Factory settings"/"Defaults". It may alternately be some past set of settings, possibly the ones that were in place before the dialog was opened, like "Revert"/"Revert Panel". Sometimes there are even both types of buttons.

On some panels there are "cancel" buttons, which could either mean "discard all interactions with this dialog and go back to the previous state", or "discard all interactions on this dialog since the last 'apply', 'confirm', etc.". "Cancel" buttons generally close the dialog as well. (contrast to "revert", which leaves it up.)

All of these different mechanisms are attempts by various developers to address the need for various different kinds of functionality when manipulating preferences. By looking at these I have come up with a starting set of InterfaceConsistencyInPreferencesIssues to be considered.