Alec Flett wrote:
Further, since I've only had to do this maybe 6 times, (i.e. it hasn't become tedious) I actually LIKE that process (much like grant or Jeffrey) - but I don't think we're all that unique. The process makes me feel like the application is "mine" now. Its the same reason that people LOVE themes, LOVE ringtones, LOVE changing the background of their computer. It gives you a sense of ownership.
Well, that's really a matter of personal taste. I do feel exactly the opposite and dislike (lowercase...) having to poke in preferences. When I find what I want I always wonder how I'm supposed to know that data 3.b.ii in subpanel 3.b in preference 3. has an influence on how menu item z will perform (short of reading each pref exhaustively). Looking at users in usability testing labs aimlessly poking around in preference panels is also an awful sight burnt in my memory... (ok, I'm pushing it here, it was not that awful... :) )
This is not to say we shouldn't be VERY judicious about the preference UI that we create though. Avoiding preference creep is even harder than avoiding feature creep!
Which actually brings up the question: which criteria to decide if something is a preference or rather a user data?
I propose one: if the data can be nixed at random and there's no sense of data loss from the user and no loss of functionality, then it's a preference.
Variation: if you had to pass the data to another PIM and there's no way that other PIM would use that data for anything meaningful, then, it's a preference.
Other ideas? Cheers, - Philippe _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
