Closed Bug 67676 Opened 24 years ago Closed 15 years ago

Distinctively mark messages that are actually addressed to the user

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: tenthumbs, Unassigned)

Details

Attachments

(2 files)

Pine PNG image
5.54 KB, image/png
Details
Forget the last one. This one displays on 4.x browsers.
5.52 KB, image/png
Details
These days opening a mail message can be an adventure. I think it would be good to steal an idea from Pine and distinctively mark messages that are actually addressed to the user. Displaying such messages in a different color or font, or adding some marker image or character could work. This would also be good for those of us who subscribe to mailing lists. Listservers eventually screw up or are changed so that previous filtering no longer works. If you've ever had to sort >100 messages you'll know that knowing which ones are really yours is extremely useful. Just as an example, see the attached image. A user will instantly know which messages are addressed to her. Just an idea.
Attached image Pine PNG image —
Hmmm. Since the majority of messages in a user's Inbox *are* addressed to the user, would it make slightly more sense to give special appearance to those which *aren't*?
OS: Linux → All
Hardware: PC → All
Users often have more folders than just Inbox. There's no reason to assume most of those messages are addressed to the user. Consider bugzilla messages. I suppose it's necessary to decide what the users email address is. I was assuming it would be just the one from the current account, but maybe it should be all the user's email addresses.
Would it not make more sense to have a message filter that could color messages (see MS Outlook for this feature). Then you can create a filter to filter mesages marked specifically for you, or messages not marked for you as a filter option rather than something across the board. That, and colors are cool:)
No, this is about a feature that works without filters or with broken filters. It seems unreasonable to assume that all users will take the trouble to create filters.
It could be made a default filter. I just think color filters in general would be a great idea. For similar reasons, then you could mark mail from bugzilla as red and mail from your egroups list as yellow, etc.
I would suggest spltting that idea off into a separate bug. Let's keep this one focused.
I like the idea to have a 'filter' (don't get confused by the term 'filter' we have one "filter" which sorts incoming mails into folders, marks them read or deletes them; this feature which I will now call view-filter to avoid confussion is supposed to filter the messages in the currently open folder based on some view-filter rules: So if(mail contains 'To/Cc: foo@bar') it might be shown with a red text (instead with a black text) in the message list -- which is exactly what you want. I think we can leave this bug unsplit until a design decision has been made.
I may have jumped the gun, but I created a new bug 67826 and marked it as enhancement.
Let us *never* call this feature a filter again. It will just cause massive confusion. :-)
I wouldn't like this. My main e-mail address has three unique variants. (i.e. you can't make a regular expression that does it) RahmCoff is merely the shortest. I would hate to have something marked as spam, just because they've got a differnt (but still completely valid) address.
foo@bar.baz|zab@far.ofo|rab@oof.bza mind you, \. for correct escaping. you can certainly do it.
Have you tried Labels? It's available in the nightlies.
Labels seems to be an answer for everything, yet they can't be used to solve two problems at once. For instance, I'm now using labels to color messages according to priority (and therefore needed to customize all five labels "very low", "low", "normal", "high", "very high"). This makes it impossible to implement both simultaneously. I appreciate your suggestion, but let's not make labels a cureall, because things will start to get very messy if we try to do lots of things with them at once.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: esther → message-display
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
You can have any number of coloured tags by now → extension fodder.
Resolution: EXPIRED → WONTFIX
Depends on: 1401141
No longer depends on: 1401141
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: