Daniel's Perspective

The Laymen know preferences as simply that: "preferences".This is so since they literraly prefer one thing over another.

The problem as I see it is not semantic but of finding quickly and easy the user preference that the user wants to change. Taking this into acount, if we put instead of the menu item "preference" some other word like user data, styles, metadata, I strongly believe it will be the last place where people would go to find that preference they want to tweak.

But everyone is right, and should be taken into account:

• The least the better Only put preferences if there is no way to tweak the form and display it as a default.
• Design the preference panel so that preferences are easily findable.
• Putting Examples Explain in the Preference panel what that preference will do when changed and how to change it acordingly.
• Group preferences into subgroups like: User Data, Styles, etc. maybe having subgroups of those eg.: User Data or Accounts:(mail, IRC, etc.).
• Have an accesible Default button whenever it�s aplicable in each sub panel independtly from the rest.
• Have a walk through the first time one uses Chandler to set up your preferences (don�t know if this are the correct words and or expressions).

To design preference menu item is in fact boring, but as it�s evident from the discussion it IS part of the experience. Although at first I might have sounded too far apart from Philippe, I believe he is right in every word he says, idealy speaking a program would not have preferences at all, or it would learn from people habits, but now, still, is not the right time for this. A concious designed GUI is welcomed on the other hand, it should be inevitable!

-- DanielVareika - 16 Nov 2005