PM's and Read Status

[thcri]

I don't want to read members PM's or even have the ability to do so.   What I am looking for as an Administrator if I send a member a PM I just want to know if they read the PM or not.   Is there such a plugin for that or is that something available already someplace?

[Pebble]

Not to my knowledge.
I wrote a plugin to do this a while back but got my wrist slapped as it is against the Plugin TOS.

[Chris]

Could you elaborate on which part of your plugin was against TOS Pebble? If you were to change the implementation to give recipients an opt-in option for return receipts I suspect that would overcome any privacy concerns. I would however guess privacy was not the infringing reason but perhaps some unbridled use of resources?

[Pebble]

It's been quite a while but from what I remember was that setting a key on page load to mark the PM as read was against the TOS, obviously.
The option of setting the key when clicking the link to open the PM was also dismissed as it was doubling up on the requests for a click and the user wasn't aware of what was been done.

The idea of adding a button to mark it read would have worked but seemed to make the plugin pointless.
I'll try and dig out the PM info when I have time but the doubling of the requests was the main problem without the user being aware of it..... I think.

[Pebble]

I found it!
Regarding the setting the key before the page change, Part of what Tim said was :

the issue here is that while you would be technically requiring user interaction, you're achieving this through misleading the user. They click one time, and two requests are spawned instead of one. This doubling of requests is the crux of the issue, and unfortunately is one thing we really can't budge on.

So I've stayed away from doing anything like that since. There is a recent request here for logging the profile views which I would put in the same category as this.

[Wormopolis]

That makes nervous about setting keys on post submits

[Chris]

Thanks for the info Pebble!
So basically as long as the user is kept fully informed!

In my view, the very nature of AJAX involves performing multiple actions based on a single initiating action so that cannot be the problem here.  The post like feature ,for example, sends off a packet to the server instructing it to add/remove the user to/from a database in addition notifications have to be sent off to interested parties and then an updated list of who besides you liked that item has to be returned. Finally this returned data is used to update the UI (the only thing the user actually sees is the results from this last action). Although the user may not know all the details that go into that click it is understood that these actions are to be expected  when they clicked that like button.

Someone on the other hand clicking a link to open a private message or view a profile is understandably expecting only the standard link click action and not realizing there is an additional hidden action involved with clicking that link. If they had been informed of this extra action they  may have even opted not to click that link. Therefore disclosing that information is imperative and could be as simple as adding some sort of visible marker to the link, let's say a tiny return receipt CSS icon, to distinguish it from a normal link and inform the user that when they click that link something extra (in this case a notification) will also be sent off and should get around any full disclosure concerns. A popup containing a cancel button with a self-closing time limit could also be useful or maybe even preferred in that situation as well.

By the way, this reminds me of that ping attribute in HTML5 that was so passionately opposed that they had to drop it although to this day there are browsers that support it without the persons using that browser even knowing *cough*.