Configuration
JohnMoser: I think configuration needs to be simple, powerful, and accessible all at once. This can be done in a number of ways; although the only two I can think of are context configuration and a system-wide configuration verbosity level.
Context Configuration involves exposing the user to configurations based on context, using context menus (the pop-up menus you get when you right-click). For a simple example, Gaim buddy lists can be sorted alphabetically by going into Tools->Preferences->Interfaces->Buddy List. An alternate route would be to have a "Configure..." or "Configure Buddy List" entry in the context menu bring up the configuration options for the buddy list. This could be done in a number of ways.
Context Configuration could bring the Preferences dialog up with Interfaces->Buddy List selected; but this has drawbacks. Although it's straight forward, it doesn't allow for scattered, related preferences. The simple fix for this is to discourage such arrangement of preferences; however, this may not be possible for some weird reason. In such cases, it may be interesting to allow the configuration elements related to the context to be highlighted; the tabs or tree entries in which the settings reside could be tinted yellow or such.
Another method of Context Configuration could be to simply collect up all related preferences and create a dialog specifically for that context. The Preferences dialog would still exist; but Context Configuration would bring up a different dialog that was trimmed down to only relavent settings. This could be done by creating a new dialog; or simply by trimming off any unrelated settings. In either case, these goals could be achieved by attributing different configuration options as belonging to different contexts, so that the code to create the dialogs could automatically detect which configuration options were relavent.
The other part of configuration is the difficult balance between complexity and completeness. Having every possible option in the world is not useful, because the most used options get lost in the muck of crud nobody cares about; but at the same time, having only a few key settings may miss important tweaks. For example, Nautilus may be configured to not use the Spatial Browser; but if most people enjoy the Spatial Browser, this option may be removed and left to a gconf setting. This leaves those that hate the Spatial Browser being forced to use the gconf editor to change the setting, which is bad.
To compensate, a system-wide level of configuration complexity could be used. These levels could range from a Very Basic level that removes even semi-useful settings up to an Expert or even Debugging level that puts in whatever the developers could think of. Potential levels are given below.
Very Basic - Anything that's used less than about 50-75% of the time is likely to be distinctly non-essential; hide it.
Basic - The basic essential settings are shown, just like we would normally do.
Extras - Some more advanced settings are used, which are genuinely useful. These should be settings that a typical user could understand, but might not really use.
Expert - The advanced settings are exposed. These settings are things that a typical expert will use on occasion.
High Expert - Useful but very obscure settings are exposed. These settings should be useful for users of great expertise.
Debugging - This should be an additional setting, not a level. This enables debugging settings useful to developers based on the level of configuration complexity selected.
It is notable that the Expert and High Expert settings may be equivalent to Extras in many scenarios. A video encoding or editing studio may react to Expert and High Expert with specific tweaks to the encoding or effects settings that a professional would likely use but an experienced ameture would not; but something like Rhythmbox or Eye of Gnome is more likely to stop at Extras and have very few settings added at that level anyway, while something like Gaim or Evolution might add a handfull of new options at Expert and nothing above there. Because of this, the typical settings would range from Very Basic to Extras, with Expert and High Expert being almost equivalent to Extras in most applications.
Notice Debugging is noted as an additional setting, like a checkbox. This would emphasize the difference between added configuration toys and specific developer options; but it would also allow developers or debuggers to see debugging options pertainent to the current configuration level. It is unclear how this would be useful in general.
LukeHutchison: I seem to remember this getting hashed and rehashed when Havoc et al. were proposing the "Just Works" philosophy. The consensus was that forcing a user to classify themselves as beginners or experts is condescending and counter-productive.
MurrayCumming: User Levels have been tried and have comprehensively failed. It's not going to happen. At best you get 3 versions of your UI, causing confusion, and gradually everyone ends up on Expert because a) If I don't find something at first I switch to Expert in case it appears, b) I use Expert because "I want more cool stuff", and c) I use "Expert" because I'm not an idiot like all the other people. So then everyone is on Expert and the UI is confusing and we have lost.
ThomasKreeger: If the context menu was created, then you could take simple preferences with a context tag and present a menu that cascaded out to the appropriate control, such as the slider, radio button group, or menu list. Checkbox type settings could present a light-switch control or other simple switch. At the bottom of the list could be a menu choice for "Fine Tune" that would present a complete panel of configuration options for the context. So in setting up a buddy list context like the example above, I might have some metadata in my preferences like so:
Show Icon "context:buddylist.simple,control:lightswitch"
Sort "context:buddylist.simple,control:radio;a-z;z-a;off"
Highlight "context:buddylist,control:usercontrolgroup1"
Any entry with a .simple context would render right in the menu, while all entries would be presented in a full panel when the user selected "Fine Tune". One could even provide alternate menu text to display the current state without having to expand out each entry to its control.