Thanks for the reply. Comments inline.
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. :-)
