[Dev] persisting a preference

[Philippe Bossut]

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