"Labels" feature
Jennifer Glick
Mozilla Mail/News spec page. Feedback wecome.
Stefan Norman
> A draft proposal spec for a "Labels" feature has been posted to the
> Mozilla Mail/News spec page. Feedback wecome.
>
> http://www.mozilla.org/mailnews/specs/labels/index.html
Looks good, looking forward to see it and use it "for real"
Matthew Thomas
>
> A draft proposal spec for a "Labels" feature has been posted to the
> Mozilla Mail/News spec page. Feedback wecome.
<http://mozilla.org/mailnews/specs/labels/>
There are already two ways of marking up a message to distinguish it
from other messages.
The first method is to set its priority. Currently this can only be done
by the author of a message, but there is an RFE to allow the recipient
to do it as well <http://bugzilla.mozilla.org/show_bug.cgi?id=84274>.
This would be better than a `Labels' feature in five respects.
1. Unlike labels, the interface for changing priority would be very
simple -- you wouldn't need Yet Another Pref Panel for it, just a
`Change Priority to' submenu in the `Message' menu.
2. Unlike labels, changing priority would be compatible with other mail
clients and previous versions of Mozilla -- an IMAP message with
priority changed to `High' in Seamonkey, for example, would also
show up with High priority when viewed later in 4.x or in any other
mail program which understands the Priority header.
3. Unlike labels, the Priority of a message could be negotiated between
the author and the recipient. Someone may trust particular authors
(e.g. managers, family members, or sysadmins) to set message
priority appropriately at composition time, while using a filter to
apply Normal priority to all other incoming messages. (A
fill-in-the-blanks example of such a filter could even be provided,
turned off by default, when a mail account is set up.)
4. Unlike labels, Priority is not likely to be confused with the Labels
feature in the Finder. (Another way of avoiding this confusion would
be to make the Finder labels and the Mozilla labels one and the same
thing, but I can't imagine that happening in a hurry.)
5. Recipient-side priority changing would be considerably simpler to
implement than labels would.
The second method of marking up a message is to flag it. Currently (as
in 4.x) this is just a boolean toggle, which is not very expressive. But
this could be easily extended to (for example) add a note to a message,
or to add an alarm reminding the user to reply to the message at a
certain time. (Such features would not be available to authors, only recipients.)
Again, this would be more interoperable than a Labels feature would; if
you flagged an IMAP message to remind yourself to reply to it in a week,
but in a week you happened to be reading your mail via Webmail at an
Internet kiosk in Costa Rica, the message would still appear flagged in
the Webmail display. (You just wouldn't get the exact reminder that
Mozilla would give you.)
So I think adding a Labels feature would be misguided, when there could
be other less complex, more interoperable, and (in the case of flagging)
more useful mechanisms for achieving the same purpose.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
Gervase Markham
What advantages does this have over setting the priority of messages?
Gerv
Ben Bucksch
> What advantages does this have over setting the priority of messages?
It is more than priorisation. You can classify messages by arbitary rules.
Gervase Markham
Classifying messages by arbitrary rules is a function of filters, and
they work already. Labels are about what happens after classification.
As I understand it, Labels allow you to say "All mail from X becomes
labelled Y (and goes green)" instead of what can currently be done,
which is "All mail from X becomes priority Y (and goes red)". I am
trying to have the advantage of one over the other explained.
Gerv
Ben Bucksch
>> It is more than priorisation. You can classify messages by arbitary
>> rules.
>
>
>
> Classifying messages by arbitrary rules is a function of filters
Folters must have an action. "Mark it with label green" is such an action.
> As I understand it, Labels allow you to say "All mail from X becomes
> labelled Y (and goes green)" instead of what can currently be done,
> which is "All mail from X becomes priority Y (and goes red)". I am
> trying to have the advantage of one over the other explained.
In the latter case, I am changing a property of the message as the
sender sent it, right? What, if I want to still see the Priority as the
sender sent it?
What about the average user, who doesn't like "senders being able to
make messages red in their INBOX" (using the priority), and who don't
know how to use filters to undo it?
Gervase Markham
>
> Folters must have an action. "Mark it with label green" is such an action.
So it "give it Low priority". Your point?
>> As I understand it, Labels allow you to say "All mail from X becomes
>> labelled Y (and goes green)" instead of what can currently be done,
>> which is "All mail from X becomes priority Y (and goes red)". I am
>> trying to have the advantage of one over the other explained.
>
>
> In the latter case, I am changing a property of the message as the
> sender sent it, right? What, if I want to still see the Priority as the
> sender sent it?
As mpt says, the Priority it arrives with is what the sender thinks its
priority should be to you. If that isn't your priority, then you change it.
> What about the average user, who doesn't like "senders being able to
> make messages red in their INBOX" (using the priority), and who don't
> know how to use filters to undo it?
How does the labels feature solve this problem? By removing the colour
hint from the Priority? Yes, the problem goes away if you break the
feature. So? :-)
Gerv
Ben Bucksch
> As mpt says, the Priority it arrives with is what the sender thinks
> its priority should be to you. If that isn't your priority, then you
> change it.
Again: Labels are not (only) about priority. I might label mails about
implementation issues blue and design/interface issue green.
Also, if I change the priority the sender sent, I lose info - I alter
the original msg. I don't want to.
>> What about the average user, who doesn't like "senders being able to
>> make messages red in their INBOX" (using the priority), and who don't
>> know how to use filters to undo it?
>
> How does the labels feature solve this problem? By removing the colour
> hint from the Priority?
Yes. That's what triggered this proposal - marking red based on
pripority was a bad idea and we needed something more user-friendly.
Jen's proposal is a superset of what we have today and much more flexible.
> Yes, the problem goes away if you break the feature. So? :-)
huh?
Gervase Markham
> implementation issues blue and design/interface issue green.
Would you really do this? You have too much time :-)
> Also, if I change the priority the sender sent, I lose info - I alter
> the original msg. I don't want to.
Do you have control of your own priorities or does someone else?
Gerv
Ben Bucksch
>> Also, if I change the priority the sender sent, I lose info - I alter
>> the original msg. I don't want to.
>
> Do you have control of your own priorities or does someone else?
That's not the point. The fact that the sender markekd it as priority
high is an information in itself. It doesn't necessarily mean that the
mail important for me. But I may still want to know.
Matthew Thomas
Some messages (e.g. the `Mailbox size limit exceeded!' message I get
from my Webmail provider occasionally) arrive in my Inbox already
flagged. If I unflag it, I `lose info' -- the flagged status is no
longer what it was when the message was sent.
Using the same argument as you are using for Priority, then, my ability
to change the flagged status of a message is a bug. Who wants to file it?
Justin H.
One point. Priority is there for a purpose. Using it as a filing
system would be much like using the ALT attribute as a tooltip. It
would be a hack and nothing but a hack. Mozilla will either have this
feature or not, there's no point in pretending that some other feature
does this job already.
I can find all sorts of uses for labelling. In fact, I have several
subfolders that would become completely useless if I tried to subdivide
within them the way I *really* want to. Labelling would make it much
easier to work with some of my folders that have 1000+ (or 2000+ for
that matter) messages in them. And, note, I want to be able to
subdivide without changing the contents of the message. Priority is
part of the contents - especially as relates to work emails.
If my boss sends me an email as high priority, I don't want to change it
- but I want to be able to group all the emails from my boss (work and
home accounts) as one. Yes, I could create a folder just for my bosses
emails, but if I start doing that, as I said, my mail folders would
quickly become unmanagable.
About the only objection I had to the document specified at the
beginning of this thread was that the menu items would be toggles, in a
way (i.e., choosing an already selected label would turn off labelling
for that message). It would make more sense to have a "None" menu item,
or similar.
As for the color hint of Priority, who says that has to go away?
There's nothing here that stops the Priority column from having it's own
coloring separate from the rest of the header info.
Justin H.
--
"If it's in stock, we've got it!"
-slogan for a tire store
Justin H.
Matthew Thomas wrote:
>
> Jennifer Glick wrote:
> >
> > A draft proposal spec for a "Labels" feature has been posted to the
> > Mozilla Mail/News spec page. Feedback wecome.
>
> <http://mozilla.org/mailnews/specs/labels/>
>
> There are already two ways of marking up a message to distinguish it
> from other messages.
>
> The first method is to set its priority. Currently this can only be done
> by the author of a message, but there is an RFE to allow the recipient
> to do it as well <http://bugzilla.mozilla.org/show_bug.cgi?id=84274>.
>
> This would be better than a `Labels' feature in five respects.
>
> 1. Unlike labels, the interface for changing priority would be very
> simple -- you wouldn't need Yet Another Pref Panel for it, just a
> `Change Priority to' submenu in the `Message' menu.
Priority has nothing to do with any kind of labelling system. That's
not it's purpose, nor IMHO, should it be. Also, how do you make a
feature like this customizable without a prefs panel of some sort?
> 2. Unlike labels, changing priority would be compatible with other mail
> clients and previous versions of Mozilla -- an IMAP message with
> priority changed to `High' in Seamonkey, for example, would also
> show up with High priority when viewed later in 4.x or in any other
> mail program which understands the Priority header.
(Most) IMAP users don't expect to sit down at home and see the same
setup as they have at their work computer unless they've specifically
set things up that way. As for changing priority on IMAP messages, do
the various IMAP servers allow you to make changes to messages that
way? I know you can file messages and create folders, but I was unaware
that you could make changes to the actual headers.
> 3. Unlike labels, the Priority of a message could be negotiated between
> the author and the recipient. Someone may trust particular authors
> (e.g. managers, family members, or sysadmins) to set message
> priority appropriately at composition time, while using a filter to
> apply Normal priority to all other incoming messages. (A
> fill-in-the-blanks example of such a filter could even be provided,
> turned off by default, when a mail account is set up.)
That's fine, but labels are strictly a recipient option. They have
nothing to do with the sender. Once again, Priority is and should be
totally separate from a labelling system.
> 4. Unlike labels, Priority is not likely to be confused with the Labels
> feature in the Finder. (Another way of avoiding this confusion would
> be to make the Finder labels and the Mozilla labels one and the same
> thing, but I can't imagine that happening in a hurry.)
Fine, then come up with a different name. Or be more precise for the
Mac platform - i.e., Mail Labels. I'm sure that someone can come up
with something catchy. As a side note, do you know anyone that uses
Finder labels? I'm actually curious about this one, as I've never seen
anyone that does.
> 5. Recipient-side priority changing would be considerably simpler to
> implement than labels would.
That doesn't mean that both shouldn't be implemented.
> The second method of marking up a message is to flag it. Currently (as
> in 4.x) this is just a boolean toggle, which is not very expressive. But
> this could be easily extended to (for example) add a note to a message,
> or to add an alarm reminding the user to reply to the message at a
> certain time. (Such features would not be available to authors, only recipients.)
This also has nothing to do with a filing system. What you're
suggesting here sounds more like an Enterprise type feature, perhaps
linking the "Flag" to a Calendar.
> Again, this would be more interoperable than a Labels feature would; if
> you flagged an IMAP message to remind yourself to reply to it in a week,
> but in a week you happened to be reading your mail via Webmail at an
> Internet kiosk in Costa Rica, the message would still appear flagged in
> the Webmail display. (You just wouldn't get the exact reminder that
> Mozilla would give you.)
And again, I was unaware that you could make changes to message headers
via IMAP. If I'm wrong, I'd sure like to know, because this is a most
handy feature. If you're talking about Webmail, of course, that's
something completely different - but then, you knew that. :-)
> So I think adding a Labels feature would be misguided, when there could
> be other less complex, more interoperable, and (in the case of flagging)
> more useful mechanisms for achieving the same purpose.
Adding any feature would be complex given the right perspective. I talk
to people 5 days a week who don't know how to use an Enter key, or what
their username is, or how to forward a message, etc... How do you mean
"misguided?" What's complex about this? What's difficult to figure
out? One prefs panel, one menu item, probably a context menu entry
(optional), and one column. I won't even mention the filter entry,
because anyone that found this system complex wouldn't be able to use
filters.
Comments appreciated.
Gervase Markham
Absolutely. That purpose is assigning priorities to your messages. And
that's basically what the labels feature will do.
> Using it as a filing
> system would be much like using the ALT attribute as a tooltip.
Labels are not a filing system. Your IMAP folders are a filing system.
> If my boss sends me an email as high priority, I don't want to change it
> - but I want to be able to group all the emails from my boss (work and
> home accounts) as one. Yes, I could create a folder just for my bosses
> emails, but if I start doing that, as I said, my mail folders would
> quickly become unmanagable.
Why? If our search UI doesn't easy allow searching a subset of folders,
we should fix the search UI, not force people to group messages in the
same folder just to be able to search them easily.
Gerv
Ben Bucksch
>> One point. Priority is there for a purpose.
>
> Absolutely. That purpose is assigning priorities to your messages. And
> that's basically what the labels feature will do.
No.
> Labels are not a filing system.
They are.
> Your IMAP folders are a filing system.
Yes, they are another filing system. But
- Some people don't like a lot of folders.
- Folders are a strict hierarchy, while Labels add another dimension.
Peter Lairo
> About the only objection I had to the document specified at the
> beginning of this thread was that the menu items would be toggles, in a
> way (i.e., choosing an already selected label would turn off labelling
> for that message). It would make more sense to have a "None" menu item,
> or similar.
I agree that this would be more user friendly (to have a "None" menu item).
> As for the color hint of Priority, who says that has to go away?
> There's nothing here that stops the Priority column from having it's own
> coloring separate from the rest of the header info.
Great idea. Although I rarely see anybody use the priority feature nowadays.
--
Regards,
Peter Lairo
Justin H.
>
> > One point. Priority is there for a purpose.
>
> Absolutely. That purpose is assigning priorities to your messages. And
> that's basically what the labels feature will do.
Yes, if that's what you want, go for it. That's not it's primary
purpose, though. I can use labels to highlight all my bugzilla mail
without having to make separate subfolders for everything. Plus I can
sort the folder by Label making it a lot easier to manage if I need to
find a specific email.
> > Using it as a filing
> > system would be much like using the ALT attribute as a tooltip.
>
> Labels are not a filing system. Your IMAP folders are a filing system.
Labels are most definitely *part* of a filing system. Ask anyone who
works for a doctor's office. Priority, however, isn't. That fact that
you can sort on Priority is simply a matter of convenience.
> > If my boss sends me an email as high priority, I don't want to change it
> > - but I want to be able to group all the emails from my boss (work and
> > home accounts) as one. Yes, I could create a folder just for my bosses
> > emails, but if I start doing that, as I said, my mail folders would
> > quickly become unmanagable.
>
> Why? If our search UI doesn't easy allow searching a subset of folders,
> we should fix the search UI, not force people to group messages in the
> same folder just to be able to search them easily.
What does search have to do with it? I haven't said a word about
search. I don't use subfolders because, in quite a few cases, I'd end
up with a huge amount of subfolders with almost nothing in them, making
things an unmanagable mess. It would be *much* easier simply to make a
way to subdivide *within* a folder. And, no, using Priority as a hack
isn't an option.
Matthew Thomas
>...
> Matthew Thomas wrote:
>...
> > 1. Unlike labels, the interface for changing priority would be very
> > simple -- you wouldn't need Yet Another Pref Panel for it, just
> > a `Change Priority to' submenu in the `Message' menu.
>
> Priority has nothing to do with any kind of labelling system. That's
> not it's purpose, nor IMHO, should it be.
Why not?
> Also, how do you make a
> feature like this customizable without a prefs panel of some sort?
You don't. That's the whole idea.
> > 2. Unlike labels, changing priority would be compatible with other
> > mail clients and previous versions of Mozilla -- an IMAP message
> > with priority changed to `High' in Seamonkey, for example, would
> > also show up with High priority when viewed later in 4.x or in
> > any other mail program which understands the Priority header.
>
> (Most) IMAP users don't expect to sit down at home and see the same
> setup as they have at their work computer unless they've specifically
> set things up that way.
Sure, but that's irrelevant to this discussion.
> As for changing priority on IMAP messages, do
> the various IMAP servers allow you to make changes to messages that
> way? I know you can file messages and create folders, but I was
> unaware that you could make changes to the actual headers.
Yes -- you can delete the message, then APPEND a copy which differs only
in its Priority header.
> > 3. Unlike labels, the Priority of a message could be negotiated
> > between the author and the recipient. Someone may trust
> > particular authors (e.g. managers, family members, or sysadmins)
> > to set message priority appropriately at composition time, while
> > using a filter to apply Normal priority to all other incoming
> > messages. (A fill-in-the-blanks example of such a filter could
> > even be provided, turned off by default, when a mail account is
> > set up.)
>
> That's fine, but labels are strictly a recipient option. They have
> nothing to do with the sender.
Yes, that's exactly the problem.
> Once again, Priority is and should be
> totally separate from a labelling system.
Why?
> > 4. Unlike labels, Priority is not likely to be confused with the
> > Labels feature in the Finder. (Another way of avoiding this
> > confusion would be to make the Finder labels and the Mozilla
> > labels one and the same thing, but I can't imagine that
> > happening in a hurry.)
>
> Fine, then come up with a different name.
I did. `Priority'.
> Or be more precise for the
> Mac platform - i.e., Mail Labels. I'm sure that someone can come up
> with something catchy. As a side note, do you know anyone that uses
> Finder labels? I'm actually curious about this one, as I've never
> seen anyone that does.
I do, occasionally. I imagine that mail labels would only be slightly
more popular, due to the ability to apply them automatically using filters.
> > 5. Recipient-side priority changing would be considerably simpler
> > to implement than labels would.
>
> That doesn't mean that both shouldn't be implemented.
True -- the fact that implementing both at once would be quite confusing
was a reason I didn't even mention.
> > The second method of marking up a message is to flag it. Currently
> > (as in 4.x) this is just a boolean toggle, which is not very
> > expressive. But this could be easily extended to (for example) add a
> > note to a message, or to add an alarm reminding the user to reply to
> > the message at a certain time. (Such features would not be available
> to authors, only recipients.)
>
> This also has nothing to do with a filing system.
That's because we're not talking about mail folders.
> What you're
> suggesting here sounds more like an Enterprise type feature, perhaps
> linking the "Flag" to a Calendar.
That would be a possible enhancement, yes.
> > Again, this would be more interoperable than a Labels feature would;
> > if you flagged an IMAP message to remind yourself to reply to it in
> > a week, but in a week you happened to be reading your mail via
> > Webmail at an Internet kiosk in Costa Rica, the message would still
> > appear flagged in the Webmail display. (You just wouldn't get the
> > exact reminder that Mozilla would give you.)
>
> And again, I was unaware that you could make changes to message
> headers via IMAP. If I'm wrong, I'd sure like to know, because this
> is a most handy feature.
Changing the flaggedness of an IMAP message is even easier than changing
its headers.
> If you're talking about Webmail, of course,
> that's something completely different - but then, you knew that. :-)
Nope. My mail account works with both Webmail and IMAP.
> > So I think adding a Labels feature would be misguided, when there
> > could be other less complex, more interoperable, and (in the case of
> > flagging) more useful mechanisms for achieving the same purpose.
>
> Adding any feature would be complex given the right perspective.
Sure, but that's not what I was complaining about. I was saying that
adding a Labels feature would be misguided, when there could be other
less complex, more interoperable, and (in the case of flagging) more
useful mechanisms for achieving the same purpose.
> I
> talk to people 5 days a week who don't know how to use an Enter key,
> or what their username is, or how to forward a message, etc...
So do I.
> How do
> you mean "misguided?"
adj. led or prompted by wrong or inappropriate motives or ideals.
> What's complex about this?
It's not particularly complex, but it's about twice as complex as the
more interoperable and (in the case of flagging) more useful mechanisms
for achieving the same purpose.
> What's difficult to
> figure out? One prefs panel, one menu item, probably a context menu
> entry (optional), and one column.
As opposed to zero prefs panels, one menu item, zero extra context menu
items (other than those already in the spec), and zero columns.
> I won't even mention the filter
> entry, because anyone that found this system complex wouldn't be able
> to use filters.
>...
Novices aren't the only people who benefit from simplicity. Experts
often have better things to do than wade through excessive amounts of
UI, such as Mozilla already has in many places.
Justin H.
Matthew Thomas wrote:
>
> "Justin H." wrote:
> >...
> >
> > Priority has nothing to do with any kind of labelling system. That's
> > not it's purpose, nor IMHO, should it be.
>
> Why not?
I wouldn't use Priority as a basis for a filing system because the
Priority has nothing to do with the contents of the message. Most
people don't file information based on Priority (except in very specific
cases). You file it based on content or who wrote said content. For
instance, I have a folder for each of the mailing lists I subscribe to,
a folder for bugzilla mail, and a folder for any system generated email
I get, but I don't have a single folder for high, medium or low priority
items.
>
> > Also, how do you make a
> > feature like this customizable without a prefs panel of some sort?
>
> You don't. That's the whole idea.
Exactly.
> > (Most) IMAP users don't expect to sit down at home and see the same
> > setup as they have at their work computer unless they've specifically
> > set things up that way.
>
> Sure, but that's irrelevant to this discussion.
It seemed to be since your argument was that Priority would be better as
it would cross mail programs. The only case where that would be
applicable would be in IMAP (as relates to mail-news) and those systems
that offer IMAP as part of their mail system. If you don't think it's
relevant, then I'm not going to worry about it. :-)
> >
> > That's fine, but labels are strictly a recipient option. They have
> > nothing to do with the sender.
>
> Yes, that's exactly the problem.
How is that a problem? If I'm going to create a filing system, I don't
want just anyone throwing stuff in random drawers (so to speak).
> > Fine, then come up with a different name.
>
> I did. `Priority'.
That was you?! Wow, you're older than I thought.
> > That doesn't mean that both shouldn't be implemented.
>
> True -- the fact that implementing both at once would be quite confusing
> was a reason I didn't even mention.
Why confusing? They serve two distinct and separate functions, with the
exception of those that use priority as their filing criteria.
> > If you're talking about Webmail, of course,
> > that's something completely different - but then, you knew that. :-)
>
> Nope. My mail account works with both Webmail and IMAP.
Either you're referring to Netscape's Webmail, or you're referring to
someone that offers web access to their mail server. In the first case,
you're correct - I cede the point. ;-) In the second case, you're
talking about something different than what I am. Webmail to me is
something like Hotmail that doesn't offer standard email protocol
service, not a service that offers POP/IMAP service and a web-based
interface.
> > Adding any feature would be complex given the right perspective.
>
> Sure, but that's not what I was complaining about. I was saying that
> adding a Labels feature would be misguided, when there could be other
> less complex, more interoperable, and (in the case of flagging) more
> useful mechanisms for achieving the same purpose.
Well, then if you know what they are, tell us. However, given the
arguments so far, I'm not convinced that Priority is the answer. If the
type of extended flagging you're talking about could be sorted on in
some way, I might accept that as a solution, however, from what you've
said and what I'm envisioning, it sounds more like an arbitrary data
type than anything that could be sorted on in any meaningful way. And,
no, sorting on a boolean value isn't very meaningful. :-)
> > What's complex about this?
>
> It's not particularly complex, but it's about twice as complex as the
> more interoperable and (in the case of flagging) more useful mechanisms
> for achieving the same purpose.
But it's no more complex than it needs to be to achieve the purpose it's
designed for. An extensible, user controlled way of extending the
current folder-based filing system without making it overly ponderous
(much like that sentence was). It also does so without
replacing/duplicating existing functionality.
> > What's difficult to
> > figure out? One prefs panel, one menu item, probably a context menu
> > entry (optional), and one column.
>
> As opposed to zero prefs panels, one menu item, zero extra context menu
> items (other than those already in the spec), and zero columns.
Less control, less expandability, more inherent limitations.
> > I won't even mention the filter
> > entry, because anyone that found this system complex wouldn't be able
> > to use filters.
> >...
>
> Novices aren't the only people who benefit from simplicity. Experts
> often have better things to do than wade through excessive amounts of
> UI, such as Mozilla already has in many places.
I fully agree. However, I don't agree that this has as much of an
impact on the UI as you seem to be implying. I realize (despite what it
sounds like) that the UI is the sum total of ALL the parts and their
various entries in menus, buttons, prefs panels, separated windows,
etc... Again, I'm curious (one of my failings, I'm afraid), what kind
of criteria are you using for a cutoff? Are there any numbers you use
as a basis for deciding if a feature has too much of an impact on the
UI, or is it a subjective decision based on experience?
Just for clarification, let me point out that I'd *like* to see this
type of functionality in the program. I won't cry, however, if it's not
in there - I'll simply limp along the way I always have. I do, however,
object to the idea that the functionality already exists when it
doesn't.
Comments appreciated,
Justin H.
P.S. Please append "IMO" where necessary. :-)
Gervase Markham
> Priority has nothing to do with the contents of the message. Most
> people don't file information based on Priority (except in very specific
> cases). You file it based on content or who wrote said content. For
> instance, I have a folder for each of the mailing lists I subscribe to,
> a folder for bugzilla mail, and a folder for any system generated email
> I get, but I don't have a single folder for high, medium or low priority
> items.
So, what are you saying? You want all your bugmail to be in your bugmail
folder _and_ coloured green? If you are using folders as a filing
system, why do you need any facility like Labels or Priority at all?
> > Most) IMAP users don't expect to sit down at home and see the same
> > setup as they have at their work computer unless they've specifically
> > set things up that way.
No, but it would be a pleasant surprise if it did :-) But what he means
about portability is that it would be visible in other email clients.
>>>That's fine, but labels are strictly a recipient option. They have
>>>nothing to do with the sender.
>>>
>>Yes, that's exactly the problem.
>
> How is that a problem? If I'm going to create a filing system, I don't
> want just anyone throwing stuff in random drawers (so to speak).
I'm not sure you follow how this would work. You would not filter on
incoming Priority (throwing stuff in random drawers). Your messages
would come in and you would then set the Priority on them in order to
classify them in some way that you liked.
1) Currently, some messages arrive with a Priority field set
2) What other people think my priorities are is of no concern to me. Why
do you think some spam arrives High Priority? Sender priority is dead in
the water as a useful tool.
3) However, all mail clients allow UI for Priority. So, if we implement
client-side priority setting, we can have a classification system for
messages (within a given folder - that's important) which is generic and
cross-platform.
4) This is not a filing system, or intended as a replacement for folders.
Seems good to me.
Gerv
Justin H.
>
> > I wouldn't use Priority as a basis for a filing system because the
> > Priority has nothing to do with the contents of the message. Most
> > people don't file information based on Priority (except in very specific
> > cases). You file it based on content or who wrote said content. For
> > instance, I have a folder for each of the mailing lists I subscribe to,
> > a folder for bugzilla mail, and a folder for any system generated email
> > I get, but I don't have a single folder for high, medium or low priority
> > items.
>
> So, what are you saying? You want all your bugmail to be in your bugmail
> folder _and_ coloured green? If you are using folders as a filing
> system, why do you need any facility like Labels or Priority at all?
Nope. I would like to have PGP bugs green, whitespace bugs yellow,
etc... That's just an example, of course, but it's a valid one. Oh,
and the reason I don't have multiple folders/subfolders is because if I
separated things out the way they deserve to be, I'd spend most of my
trying to find the folder I wanted when looking for a specific email.
> > > Most) IMAP users don't expect to sit down at home and see the same
> > > setup as they have at their work computer unless they've specifically
> > > set things up that way.
>
> No, but it would be a pleasant surprise if it did :-) But what he means
> about portability is that it would be visible in other email clients.
And I was just pointing out that making things look the same for people
that don't expect things to look the same seems a bit weird to me. It's
a subjective and perspective based judgement that you can feel free to
ignore if you so choose. :-)
> >>>That's fine, but labels are strictly a recipient option. They have
> >>>nothing to do with the sender.
> >>>
> >>Yes, that's exactly the problem.
> >
> > How is that a problem? If I'm going to create a filing system, I don't
> > want just anyone throwing stuff in random drawers (so to speak).
>
> I'm not sure you follow how this would work. You would not filter on
> incoming Priority (throwing stuff in random drawers). Your messages
> would come in and you would then set the Priority on them in order to
> classify them in some way that you liked.
>
> 1) Currently, some messages arrive with a Priority field set
> 2) What other people think my priorities are is of no concern to me. Why
> do you think some spam arrives High Priority? Sender priority is dead in
> the water as a useful tool.
> 3) However, all mail clients allow UI for Priority. So, if we implement
> client-side priority setting, we can have a classification system for
> messages (within a given folder - that's important) which is generic and
> cross-platform.
> 4) This is not a filing system, or intended as a replacement for folders.
>
> Seems good to me.
It seems good *if* (most) everyone agrees that Priority is a dead
system. Spam isn't a valid case. Spam is a non-issue because spam
doesn't have a priority, it's just deleted. However, I use Priority in
my work environment. In this environment, changing Priority is data
loss.
I feel like I'm on a door painted on a brick wall here, so, unless you
can think of something new to add to this discussion, I'm going to
consider it ended. I think we've all got better things to do. :-)
Gervase Markham
> etc... That's just an example, of course, but it's a valid one. Oh,
> and the reason I don't have multiple folders/subfolders is because if I
> separated things out the way they deserve to be, I'd spend most of my
> trying to find the folder I wanted when looking for a specific email.
Er... right. So you'd spend more time searching for a specific mail on a
PGP bug if you had a folder called "PGP bugs" rather than one big one
called "bugs"? Uh huh.
>>No, but it would be a pleasant surprise if it did :-) But what he means
>>about portability is that it would be visible in other email clients.
>
> And I was just pointing out that making things look the same for people
> that don't expect things to look the same seems a bit weird to me. It's
Aargh! Consistency! Flee!
Gerv
Justin H.
>
> > Nope. I would like to have PGP bugs green, whitespace bugs yellow,
> > etc... That's just an example, of course, but it's a valid one. Oh,
> > and the reason I don't have multiple folders/subfolders is because if I
> > separated things out the way they deserve to be, I'd spend most of my
> > trying to find the folder I wanted when looking for a specific email.
>
> Er... right. So you'd spend more time searching for a specific mail on a
> PGP bug if you had a folder called "PGP bugs" rather than one big one
> called "bugs"? Uh huh.
Well, if it were an isolated case, that would sound silly, eh? ;-)
But since I also subscribe to several mailing lists that I have folders
for, if I started breaking those out, I'd be in folder hell. Not to
mention my work folders, system folders. The crontab messages alone
would be several folders! Arrrrgh! Whereas a system where I can
separate and differentiate within the folder (without changing Priority
or other essential information) would be much easier to deal with.
> >>No, but it would be a pleasant surprise if it did :-) But what he means
> >>about portability is that it would be visible in other email clients.
> >
> > And I was just pointing out that making things look the same for people
> > that don't expect things to look the same seems a bit weird to me. It's
>
> Aargh! Consistency! Flee!
>
> Gerv
Consistency?!?! Consistency is for the sane.
Gervase Markham
> for, if I started breaking those out, I'd be in folder hell. Not to
> mention my work folders, system folders. The crontab messages alone
> would be several folders! Arrrrgh! Whereas a system where I can
> separate and differentiate within the folder (without changing Priority
> or other essential information) would be much easier to deal with.
So you want labels to make up for the fact that your IMAP server/email
program doesn't support folders within folders?
Gerv
Justin H.
I was going to reply to this, but I can't get up the energy to go over
the same territory any more. You can either re-read what I wrote
before, or you can ignore this subject from now on.
Ben Bucksch
> So you want labels to make up for the fact that your IMAP server/email
> program doesn't support folders within folders?
He didn't say that.
Gerv, you didn't answer to some of the arguments provided.
For example the "second dimension" I mentioned. It means that I can use
Labels for sorting msgs after criteria that appear in *all* (or most)
folders. You could create folders for each of them, but then you'd have
the same folder structure in almost all folders. Also, you'd lose the
time-relation of the messages.
Constructing an example: In a company, I could have a folder hierarchy
for branches, projects, subprojects etc.. I use one label for marking
internal communication, one label for communication with my contact at
the customer and one label for the boss of the customer / contract
issues. I can easily pre-filter the msgs, giving them appropriate labels
and manually adjust the labels were necessary. Then, I have one folder
per (sub)project, where I can sort all the messages in a chronologic
order, but still quickly find a certain type of message. I can even see
the progress visually.
If you sort internal and external communication in different folders,
you have to constantly switch between folders to read about a certain
topic. If you use neither folders nor labels, you need much more time
finding a discussion you had with the customer, because you have to wade
through all the internal discussion. (Or you have to use the search
feature, which also takes time, because you have to enter search
criteria with the keyboard, assuming you can reliably search at all.)
What about the argument that abusing Priority for local storage is data
loss? Sender-Priority might not have been proven useful for *you*, but
Justin says, it were important info for him. (And he is not the only one
- I agree.) So, using Priority is out.
Ben