Open Bug 151638 Opened 22 years ago Updated 2 years ago

[RFE] sort inbox by tag (request for more labels, views, category based on addr book)

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: ducky, Unassigned)

References

(Blocks 1 open bug)

Details

There needs to be a way of organizing messages in the inbox by rough priority. I don't think the Priority and Label fields are finely-grained enough AND resetting the Priority field loses whatever Priority the sender has given it. One solution is to set up a View; another is to add more Labels. WHY DO I THINK THAT? In the course of writing a pair of books on how to get through email faster (the _Overcome Email Overload_ book series), I talked to hundreds of people about how they used email. I was shocked to find that very few people -- even some hard-core hackers! -- used filters. Over and over, I heard variations of, "If it's not in my inbox, I won't look at it." The fabulous paper by Whittaker and Sidner at http://www.lotus.com/lotus/research.nsf/a1d792857da52f638525630f004e7ab8/14c206be32b672b4852563bf00666339/$FILE/sw_txt.htm explains why: people use their inbox as sort of a "to-do" list. They like to see what messages are still active -- that then need to read, respond to, or act upon. When messages move into folders immediately on arrival, it's hard for many (most?) people to keep track of their active messages. (Note that it's just fine to move messages that are not likely to become "to-do" items: spam and most mailing lists can move without hampering someone's ability to see their "to-do" messages.) Yes, some people can use folders to manage incoming messages. Heck, *I* use folders. But many (most?) people don't have the skill (memory?) to be able to pull that off. SOLUTION PARAMETERS To organize messages in situ, in the inbox, means being able to sort the inbox by something meaningful. One way to do this would be to have a View that groups messages by which Address Book the sender is in. If you can rank-order your inboxes, then you can have messages sorted e.g. like this: spousal unit bosses immediate co-workers family friends others inside company strangers (i.e. not in address book) If the user can't rank-order the address books easily, all is not lost; simply put an ordinal letter at the beginning of the address book name, so Aunt Mabel would have address books named e.g. a-Sweetie c-ChainOfCommand h-Payroll i-FlossRecyclingIncInternal j-Familiy m-Temple n-Parachuters o-RoseGardeners p-OtherFriends z-BlockedAddresses Creating a View to sort first by sender's address book (second by date) is relatively clean (and has the advantage that Aunt Mabel doesn't have to touch filters) but gets kludgy for mailing lists. Either you have to shunt mailing lists off to folders or you have to have a special Address Book for mailing lists. I'd also like this View to rank messages from strangers by score (see bug 151622), so conceptually that View gets a bit kludgy. You could also use Priority to order your messages, but it seems poor form to override the sender's Priority. Yes, yes, I know, senders lie about the priority, but *some* people are going to want to keep Priority intact. Labels and Priorities both have the disadvantage few numbers. Aunt Mabel has ten different groups, and I wasn't even trying hard. I also didn't make groups for her mailing lists. I think that an unlimited number would be nice, but 16 is a bare minimum. 32 would probably be adequate for most people. Labels are bound with color, and I'm not sure that the grouping field -- I'll call it "category" for now -- should be bound with color. Many people like using color to denote how they were addressed (To, CC, Bcc). In a perfect world, we'd have a separate field for color and for category. PLEA When I advise people on getting through email faster, there are three things that make people's eyes really light up. (Coloring by To/Cc/Bcc is the second.) Prioritizing messages *in the inbox* by sorting by category is the number-one way to light them up. People who get a lot of email and implement this strategy tell me they get through mail between 25 and 75% faster than before. I realize that this would be tough to implement with IMAP, but that's no reason to deny it to the POP users.
We already have a request for allowing an arbitrary number of labels -- bug 114656. And we have some existing bugs about filters based on address books, and requests for filters on just about everything under the sun.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [RFE] sort inbox by category → [RFE] sort inbox by category (request for more labels, views, etc.)
Summary: [RFE] sort inbox by category (request for more labels, views, etc.) → [RFE] sort inbox by category (request for more labels, views, category based on addr book)
Whoops, sorry -- this is very similar to (but not identical, alas) to 33296.
mass re-assign.
Assignee: naving → sspitzer
Product: MailNews → Core
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: laurel → filters
Product: Core → MailNews Core
Bryan, does this fit into the grand scheme? (not blocking 432710 yet in case this goes wontfix) This is a bit all over the map, but summarized as "Prioritizing messages *in the inbox* by sorting by category is the number-one way to light them up." And, presumably, would require ORDERED list of tags, which we don't currently have. xref the bug about hierarchical tags => Front end
Component: Filters → Mail Window Front End
Product: MailNews Core → Thunderbird
QA Contact: filters → front-end
Summary: [RFE] sort inbox by category (request for more labels, views, category based on addr book) → [RFE] sort inbox by tag (request for more labels, views, category based on addr book)
Version: Trunk → unspecified
I like the ideas, but this is a bit all over the map so it's hard to know where to start. Also, being this deep into our release cycle likely means that items without lots of clear definition won't get enough traction to make it. Perhaps with more focussed effort on breaking this down into pieces that can be worked on or if this was done as an extension we would have a talking point to move forward with.
Blocks: tb-tagsmeta
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.