Suppose that I, the proud president of Universal Widgets, get an email from Al, one of our loyal clients. Al wants to know whether our widgets can work under water.
I think so, but am not sure. So I send a reply, copying Betty who runs our R&D lab, suggesting that she follow up.
Meanwhile, I also blind-copy Cecil, our patent lawyer. After all, if satisfying this customer will involve inventing some new capability, I want Cecil in the loop.
What’s wrong with this picture? Well, for one thing, Betty doesn’t know that I copied Cecil. While I may not want the customer to know we’re copying our patent lawyer on this exchange, I probably do want our head of R&D to know.
As far as I know, there isn’t any graceful way, with a single email, to do what I really want: Send a reply to Al, copy Betty on my reply, and copy Cecil in such a way that Betty (but not Al) sees that I have copied Cecil.
Yes, I could one email to just Al and Betty, and then send another email to just Betty and Cecil. But that seems inefficient.
Shouldn’t there be a way to do this in one step?
Unless Al knows who Cecil is and why you’ve CC’ed him, is there any harm to having him visibly copied?
Of course, any message to the lawyer is ideally done by phone, so you can both innocently shrug your shoulders and say “I don’t remember anything about that” when you get deposed a decade from now.
If I trust my lawyer, and he tells me that he wants a paper trail for some things, and that he also wants to be a discrete observer from the wings, then I am going to follow his advice.
In any case, this scenario was just an illustrative example. My question is about a general principle of email capability.
I read this last night in passing, and thought (in my sleepy state) there has to be a simple solution to this.
And now it haunts me that I can’t think of something.
What I have so far: this would definitely need to be a semi-serverside mechanism.
We invent a new field called PCC (P for Private). Repeat Betty’s address along with Cecil’s in the PCC field. It would be treated as a BCC by the server as far as the To and CC lists are concerned. But if a person is mentioned in the main fields (To, CC, or BCC) and PCC, then the PCC list is preserved in that email just as CC would be in a normal scenario.
Anyone not one the PCC list are still blind to the BCC and PCC fields. However, all PCC recipients have it preserved. So a reply-all from them, especially if they’re on the To or CC list, would allow them to keep the silent observers appraised of the conversation. Yet at the same time, remove the annoying and inefficient step of having to add the BCC people back on the list every time you reply.
This is just a working concept. I can already see several flaws with this system. But it can be made to work with not too much effort.
Without an industry standard becoming available, it can be implemented by a set of small plugins on the mailserver and the email client. But with the advent of smart devices, it would be necessary to implement the mechanism on mail client on phones and tablets as well.
A forced server-side mechanism can be made where the incoming email has a special field which automatically populates the PCC list in the BCC list on unsupported devices or applications.
Now that I think about it, I wouldn’t mind writing up a small concept paper on this.
Interesting that there are two separate questions here: (1) What should it look like to the user, and (2) how best to implement it.
Of those two questions, I find (1) far more interesting. After all, we already know we can implement it, one way or another. But if there isn’t a clean, clear and simple way to a user to access it, then it will never become widely used.
The easiest method I can imagine is to simply have it be an additional field just like BCC. If the person receiving it is in the PCC list, then their email code would carry the PCC list as well.
Cecil and Betty would both be able to see themselves listed in the PCC field.
The email client could show a color or icon to warn the PCC recipient that they are a private copied individual, to prevent a potential faux pas.
The input behavior would be the same as a CC/BCC list. This would reduce the learning curve for the typical user. Perhaps the PCC line would carry a small note that warns them that only the people listed in the PCC will be able to see each, and if anyone on the BCC, CC, TO is to be allowed to see the PCC list, they should be added to the PCC list.
While straightforward, I am not satisfied with this method. It would cause many users to think it would send two copies. So there might be an additional warning added to the one above (and written by a wordsmith much wiser than I, I beg).
A better approach that just came to me:
A different mechanism would be to have a toggle icon next to each recipient’s name in the TO/CC/BCC fields. If you check it, that particular individual would be shown the BCC recipients.
The whole PCC paradigm would still be used to make this work, but quietly, and without bothering the user.
From a UX standpoint, this method appeals to me.
Afterthought: This does not need to be a complex server implementation.
The email client adds the extra field in the email header to the BCC/PCC recipients. The receiving client would be required to recognize it, otherwise it would be treated as BCC if you’re not in TO or CC.
It is tempting to prototype this. It would be quite straightforward.
Awesome! When you’ve implemented it, please send me a PCC.
😉
Ken, you’re soaking in PolySocial Reality again! posr.org