One way to think of email accounts as a preference as opposed to user data is that the email account is not actually your content. The emails you get through the accounts is the content. The accounts themselves just tell Chandler where to look to go find your data. In that way, if you created collections for each of your email accounts, you can think of the email account as a "rule" telling Chandler where to go find data to put into that collection.
Similarly, you might create specific collections for specific mailing lists or RSS feeds. Your "Friends" collection might contain multiple RSS feeds from Flickr and Delicious and various blogs.
Is this a preference? or user data? I tend to think of it as metadata about the collection or the user's content. (This email came from this account.)
I think I would still make it separate from the Preferences dialog...if only because we'll have so many more kinds of accounts than the average mail app, but if we were only doing mail, it would be tempting to just put it all in preferences.
Mimi :o)
On Nov 11, 2005, at 1:25 PM, Alec Flett wrote: Grant Baillie wrote: The issue of preferences UI is interesting. I agree the current model is frequently abused (in the email world, the extreme case is Eudora, where the sheer number and variety of preferences panes is overwhelming), I personally think that a preferences dialog is inevitable, mostly because there are ultimately some basic behaviors that "advanced" users might want to change.. (really I think of them as "one step past beginner") but for more that the obvious reason of mere preference over the default behavior.
I applaud Apple's effort in particular for making a pretty obvious effort to minimize the number of preferences in their Apps. I remember when iTunes first came out, how surprised I was that there weren't more preferences, but impressed that there wasn't any one in particular that I needed at the time. But at the time, iTunes was mostly just an MP3 player that synced with your iPod
However, iTunes has become a much more complex app since then. There is a store, people's iTunes collections have gotten larger than their iPods, it supports Podcasts, you can burn different kinds of CDs, it plays videos, etc. Even though each of these features has added 2-5 preferences each, the iTunes preference panels have gotten complex. But guess what? Every time I sit at a new computer and install iTunes, I go through each tab because I have about 10 personal settings that I like to have "just right" that vary slightly from the defaults.
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.
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!
Alec
and in most cases a direct manipulation model is better. In defence of a preferences UI, I should say I think it can sometimes _help_ discoverability: when I'm trying to figure out how a new app works and what it does, I typically go through the menus, and then the preferences. But maybe I'm just weird :).
--Grant
On Nov 11, 2005, at 12:22, Philippe Bossut wrote:
Hi,
First, I'd like to say +1 on this proposal though I'd like some things to be clarified.
In general, a problem I always had with preferences is that it's an amorphous aggregate of info without much semantic attached to it. It rapidly becomes a clutter of everything no one knows exactly where to fit. Preferences were invented to persist data between sessions for document oriented applications that lacked a way to persist their own data. In the context of Chandler, it's not a problem we really have though we still need to persist things (I won't call them preferences...) that are not user data per se (see Jeffrey initial example in this thread).
Also, I know no one is advocating having UI for preferences (under a "Preferences..." menu item), but, in case anyone has doubt, I advocate against having a "Preferences..." menu item at all. Preferences menu lead to countless discoverability issues. I'm of the opinion that if a function foo is dependent of data "x", data "x" should be available in the UI of function foo, not buried in some obscure preference panel (you can tell I suffered through that one, can you?... :) )
In general, I see 2 big types of preferences:
- state info: info that we want to persist between sessions (last selected item, options chosen by the user in dialog x, prefered behavior for action z...). Jeffrey's default folder for instance falls in that category.
- style info: info that relates to how things are displayed (font types, font size, colors, border info, etc...). Having a clear and simple way to modify those in Chandler would indeed be a god send.
There may be other types.
User data (like account information for instance) are not preferences but, well, user data. The criteria between preferences and user data is that preferences can be purged or reset without the user loosing anything or having to reconfigure anything. The worst that could happen is that states and styles are lost. We don't need for instance to implement schema evolution for preferences but we do need to implement it for user data. That's another criteria to semantically discriminate one from the other.
It's not always obvious. Consider that Mail.app for instance has its UI to set up accounts under a Preferences... panel. Admitedly, nixing accounts in an e-mail app is not semantically the same thing that nixing the default e-mail font. Still, those 2 things are at the same UI level. Bad, bad...
So I guess that my vote is +1 for having such a general mechanism, assuming we don't call them indiscriminately "preferences" but something else semantically meaningful (like "config" and "styles" for instance, so that we really think about their semantic when creating them) and that we don't take advantage of this to bury important UI controls in hidden preferences panels... :)
Cheers,
- Philippe
Alec Flett wrote:
I think there's something to be said for exploring a somewhat generic preferences architecture, or at the very least a set of conventions - duck typing for preferences if you will (if it looks like a preference, and acts like a preference, its probably a preference)
In the mozilla project (full disclosure: I was the owner of the preferences backend) we developed a system where all prefs are stored in a central place, and each pref has its own name within the a private namespace, such as "browser.cache.memory.enable". 3rd party plugins/extensions can "register" new prefs. This allows for a particularly useful feature in mozilla, 'about:config' - go ahead - type this into the URL bar in FireFox. What you'll get is a UI to edit all global prefs across the system. Neat, huh?
However, I personally don't think that kind of system is quite appropriate for a project like ours, especially given the dynamic nature of both python and the repository.. but there are a few things about the mozilla prefs system that were useful specifically for preferences:
1) a global list of 'all preferences' so that they could be reflected into the UI dynamically like about:config.
Of course, all of our repository can be reflected into the UI, but I think there is value in distinguishing those values in the repository that give some obvious, useful, and predictable change in the behavior of the application.
2) the ability to register for changes to a preference, or a set of preferences. This is useful because any one of a number of actions could change the value of a preference, not just a preferences dialog box.
For instance, you can register a callback for when the value of "network.protocol-handler.external.mailto" changed, or for "network.protocol-handler.external.*" to capture all sub-changes.
Both of these features are almost trivial given the repository.
I like philip's PrefsForMyParcel, and in fact I think we could accomplish most of 1) and 2) by making a base Kind/class, ParcelPrefs (or something..maybe just 'Preferences') that each parcel could derive from, and declare new schema attributes to store individual preferences. The KindCollection for ParcelPrefs would then be the 'registry' of all prefs in the system.
the only trick at that point is the notification when preferences change... but we have a number of systems for notifications, so I'm willing to bet that would be fairly easy and we can address it when there is actually a need.
Alec
Phillip J. Eby wrote:
At 08:57 PM 11/2/2005 -0800, Jeffrey Harris wrote:
Hi Folks,
What's our current thinking on how a developer should go about
establishing and using what I'll call a preference, essentially a single
persistent value with a well-known name (in this case, I'm wanting to
persist the last directories chosen for import and export)?
We've got lots of well-known collections living in
parcels/osaf/app/__init__.py, perhaps that's the appropriate place for
preferences? It doesn't feel quite right to me...
I'm sending this question to the list instead of asking one person or
another because
A) I think there might be different opinions, and
B) I'm hoping someone will write up a detailed example so that knowledge
can live on in the list, not just my brain :)
The simplest thing that would work:
class PrefsForMyParcel(schema.Item):
some_pref = schema.One(sometype, defaultValue=something)
# ... other preferences
def installParcel(parcel, oldVersion=None):
PrefsForMyParcel.update(parcel, "prefs")
Accessing preferences can then be done via:
schema.ns("my.parcel", view).prefs.some_pref
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
|
