I have read all the thread regarding "persisting a preference" as a
consequence of this I have put up a wiki
page that gives a short summary (subjective though) together with
my personal experience and opinion.
Please feel free to comment upon, either on the wiki or through mail.
Thanks a lot,
Daniel
John Anderson wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
