[Dev] persisting a preference

[John Anderson]

Philippe Bossut wrote:

> 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... :) )

+1. I don't think I've ever seen a successful application that has made 
it past 4 or 5 releases, or one designed by more than 2 people that 
didn't have too many preferences. Maybe we should impose a rule that if 
you propose a new preference when there is no room left in the 
preferences panel (without tabs or an advanced button), then you need to 
include a proposed panel layout -- where deleting and rearanging 
existing preferences is far game.

>
>> 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.

Traditionally, preferences is often implemented so that if you delete 
one, a default value will be reinstalled

>
> 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.

I think it's difficult to come up with a rule. Often, it's only after 
looking at the specific case that it becomes clear.

>
> Other ideas?
>
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev