[kmail2] [Bug 431984] New: Request feature: recipient-specific tags in multi-recipient emails

[bugzilla_noreply at kde.org]

https://bugs.kde.org/show_bug.cgi?id=431984

            Bug ID: 431984
           Summary: Request feature: recipient-specific tags in
                    multi-recipient emails
           Product: kmail2
           Version: unspecified
          Platform: unspecified
                OS: Unspecified
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: kdepim-bugs at kde.org
          Reporter: fredgib at free.fr
  Target Milestone: ---

Hi there,

I am sorry if this is not the appropriate place for this feature request, but
that's all I have found. (Please consider that English is not my mother
tongue).

This is an idea that comes from years working in offices where everyone is
overwhelmed by the high number of emails, including ones that are legitimate
but of little interest to them specifically, just because they were "CC'ed". On
the contrary, some might have overlooked the last email of a conversation they
were not really interested in, while that last email contained a document they
had to sign quickly. Etc.

Presently, one has to open an email and at least have a glance to it before
they know how they should process / classify it, how much they should care or
worry about it. Adding tags like [URGENT] or [PROJECT XYZ] in the email's
object might be fine when there is only one recipient, but when someone is put
in CC, just for their (possible) interest, they still see [URGENT] in the
object and have no idea that they might as well read that email the next day.

So here is the idea from a GUI user point of view:

In front of the various recipient fields in the email composer, there is
currently a drop-down list offering options "To", "CC", "BCC" and "Reply To". I
think it would be great to be able to invent as many options as we want in that
list. It would allow to specify how and why I intend to send my email to the
recipient(s) in the corresponding field of the composer. For example, options
could include "FYI", "Signature requested", "For review", "To be shared in your
team", "Project XYZ".

Each recipient would then receive the email with the tag that was specifically
intended to them by the sender. That tag(s) could be prepended to the email
subject or appear at a dedicated spot in the email list item layout (KDE's
tradition of high customisability could even enable users to choose). For
example, for the same email (sent only once to multiple recipients, of course),
one recipient would receive it tagged as "FYI" (and would then not worry to
much about it); another recipient would receive it with the tag "Signature
requested" and they would instantly know what is expected from them without
even opening the email (some "email rule" might even be designed by the user to
move such emails in a "To be Signed" folder), end so on.

More shortly: the idea is that it is the sender who suggests how the email
should be handled/classified/considered. Plus, the suggestion is specific to
each recipient. Although, obviously, the sender may enter several email
addresses in a recipient field of the composer, thus assigning the
corresponding tag equally to those several recipients. By the way, a recipient
could also be in more than one recipient field (with some limitations regarding
BCC, see below).

In the GUI, "To", "CC" and "BCC" would seem to be relegated to regular tags
among the other ones, although they would probably be provided by default and
"To" would be the default option of the drop-down lists.

>From a UX perspective, tags could be managed by an option "Manage tags..." in
the drop-down list in front of recipient fields. Clicking on it would lead to a
very simple pop-up window allowing to enter a new tag, and delete or modify
existing ones.

The special case of BCC: as said above, nothing prevents a given recipient from
being entered in more than one recipient field. However, entering a recipient
in a field tagged "BCC" and in another field would defeat the purpose of BCC.
My opinion is just that, when the email composer validates the "form" it should
refuse (and pop an error message) recipient addresses that are at the same time
in BCC and in any other recipient field.

Here is now the idea of how it could be implemented (please consider I have
only basic notions of computer programming and TCP/IP protocols, but the only
things I know about email headers are from the Wikipedia page and a quick look
at rfc5322):
It seems that there is no restrictions in the number and name of fields (other
than character set). So each new recipient tag could be a new email header
field with its own name. However in order to avoid mess with every email client
developing their new fields, possibly identical for different purposes, I would
opt for appending the tag label to "to-". For example, the tag appearing as "To
be signed" in the composer would match the header field "to-To_be_signed".
Another option could be to use the already existing email header field
"keywords", for example by adding the pairs "To_be_signed:alan at smith.com",
"Urgent:alan at smith.com" (again, refraining to include BCC), but I don't see any
advantage of this method over the first one.

So far, I haven't seen any reason to take special care of CC; it could be
handled just as it has always been, just being now presented in the composer as
a regular tag among many others.

Of course, at first, only Kmail/Kontact would be able to interpret those tags
in received emails and make use of them, either by displaying their label in
the email list, or prepended to the email subject, or by proposing to use them
for email rules etc. But I think this would be so useful and long-awaited that
it could increase the speed of Kmail/Kontact adoption. Then other email clients
would kind of need to be able to interpret the "to-..." fields initiated by
KMail in email headers if they want to keep up.

Last consideration I could think of: what if Alice has created a tag "To be
signed" in her composer and Bob has created a tag "For signature"? They will
write to me, and in my email list, their emails may appear with two different
tags for the same purpose.

First: I think it's not a deal breaker; you might have two different wordings,
you as a recipient are still able to know what to do and how much to care about
those two emails. So the purpose of the feature and the energy, focus and time
gain is still actual.

Second: in case of email rules relying on such tags, we can imagine rules based
on regular expressions including "sign" (or just tag patterns with "?" and "*"
wildcards, for users that are not in love with regular expressions).

Third: it might be the start for further development (not only by KDE, but in
general) in two directions:
- standard tag sets (like emoticons/emoji/smileys) that could be provided by
email clients or deployed by a company to all its employees' email client (in
this case, I guess the tag management pop-up mentioned above should have an
option to indicate a file, possibly on a network drive, listing the "corporate"
tags);
- custom tag set included as a field in VCF cards; in this case, when you
receive the a VCF card for a contact, you already know all the labels with
which they may tag emails sent to you, and plan accordingly (rules, colours
etc.).

The second option leaves unaddressed the issue of people updating their custom
tags; it would be a hassle to send the update to all their contacts, then for
them to update their rules etc.

A trade-off could be large standard tag sets shared across the world and email
clients (like the large sets of emoticons/emojis/smileys in messenger apps)
with the possibility to mark some of them as favorite, hence having those
favorite ones on the top of the list when tagging a recipient field in the
composer (or having only those favorite ones, the others being accessible
through an additional click on, for example, "See all tags...").

Anyway, there will be some minor use glitches, like there are with any feature,
but the job of telling the recipient in a blink how the email was intended
specifically to them will be done.

I asked to maybe a hundred of people in my 13 years career in high-paced
offices (I have worked in e-business for 3 years, then in field humanitarian
action for 9 years), what they thought about this idea, and they all answered
something like "it would be soooo greeeeaaaaaat, to have this!!!". I have never
had the skills, time or will to push that further. But I have discovered the
KDE paradigm like a year ago and I have been loving it since, starting with
Kontact. And then I thought that this old idea I have kept in my head would fit
well in it.

I am at the same time grateful and sorry if you have read until this point.
Cheers!

-- 
You are receiving this mail because:
You are the assignee for the bug.