PM Read Receipts Version 2.0

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Download: PM Read Receipts 2-0-1.pbp (7.06 KB)
Library Link: www.proboards.com/library/plugins/item/1082

Features:
*MOBILE SUPPORT* -When a mobile message is detected, it will prompt the user to update the inbox
This will report when a message has been read.
Shows current views on inbox/outbox/archive/labels page
Shows current views on conversation page
Inescapable popup to set key
Minute timer to preserve key freshness (removes all message data at end and lets you proceed) Time can be adjusted.
This will then display a message about the auto remove process.
Set on Command to show Viewed status as Message/Posts are made
Works with multiple participants.
Staff Only Option - If you don't want users using this plugin (Users will NOT Be Monitored) (Keep track of your staff)
Key Permissions if you want to kick certain people out of the key.
Works when you Change Pages and Search
Works with Moderations: Such as archive/unarchive/labels/leave conversation
Hyperlinks User's Name to Profile Page
Has a status indicator on where it was viewed: Message was Ignored, Read, Mobile
Has the time of when it was viewed
Shows who has viewed the last post
Shows who has read the original message
Marking a message as Read will add a read status of: Ignored
Custom Image label option for unread messages
Blurs Text Until Saved.
If canceled the message area will disappear and a message with a link will appear to refresh the page.
Color Selector for Initial Hiding Background's Color


Security Function :
Screen to block view before page load.
Blur Effect to text and removes background screen when ready.
Hides image, links, etc. elements when blurred
Disables Select All Keyboard Shortcuts (Standard and Mac)
Modal Popup Background Disables Text Highlight of Page
Disables Text Highlight  Altogether (Two css codes to support IE9 and up) - Not Even Necessary With Other Codes
Reloads Page if important attributes are changed to circumvent these alterations
30 Minute Timer on Quick Reply and Reply buttons

Version 2.0
This one should work with pre-existing versions. Please let me know if this is not the case.
Defaults
Background Color: ffffff
Unread Image: images.proboards.com/v5/stars/star_red.png
Seconds Till Auto Close: 60

Feature Request: Add user name where the last post viewed was. Requires sorting proboards.messages, reading created_on comparing to user timestamps and post with support for multiple pages.
Add Staff Only PM's option. To activate for staff to and froms.

Reminder: PM Read Receipts will not be available on mobile, but the messages on mobile will still be tracked.

[dillonk47polik]

Finally had a chance to test out this plugin. Firstly it has one bug in which the popup moves partially off-screen. I'll put a video demo of it below.

Untitled.mov (1.75 MB)

And, I'm not sure I understand how the staff-only feature works. Does it make the plugin only work for staff to staff messages?
On that note, the only suggestion I have as of now would be the staff only option to make read receipts only show for staff members, regardless of the other recipients (meaning, staff members will see when their recipients have opened the message, but the recipient [if not staff] will not get a receipt from the staff member).

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Aug 27, 2015 18:39:26 GMT -8 dillonk47polik said:

Finally had a chance to test out this plugin. Firstly it has one bug in which the popup moves partially off-screen. I'll put a video demo of it below.



And, I'm not sure I understand how the staff-only feature works. Does it make the plugin only work for staff to staff messages?
On that note, the only suggestion I have as of now would be the staff only option to make read receipts only show for staff members, regardless of the other recipients (meaning, staff members will see when their recipients have opened the message, but the recipient [if not staff] will not get a receipt from the staff member).

I find as an admin its better to keep track of staff. If u want users to not know when staff read ur request then your a jerk. This way if u mass pm u can tell who has viewed and know when staff are inactive. If members have to save on every message so should staff. Ill have to see vid when im on laptop. I appreciate the input

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Aug 27, 2015 18:39:26 GMT -8 dillonk47polik said:

Finally had a chance to test out this plugin. Firstly it has one bug in which the popup moves partially off-screen. I'll put a video demo of it below.



And, I'm not sure I understand how the staff-only feature works. Does it make the plugin only work for staff to staff messages?
On that note, the only suggestion I have as of now would be the staff only option to make read receipts only show for staff members, regardless of the other recipients (meaning, staff members will see when their recipients have opened the message, but the recipient [if not staff] will not get a receipt from the staff member).

I HAVE TO ASK: What browser is that? I try and test things in other browsers. I am currently relying on proboards auto placing feature to center the popup when the page is opened. If this is not working for insert_browser_here perhaps I can write my own code to center it in view. Version 1-0-1 should have an auto scroll to top after 4 seconds in case anchors are used. Also that black screen is big. Double the size of your current viewing window plus an extra 3000 pixels. 

[dillonk47polik]

Aug 27, 2015 22:21:56 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

I find as an admin its better to keep track of staff. If u want users to not know when staff read ur request then your a jerk. This way if u mass pm u can tell who has viewed and know when staff are inactive. If members have to save on every message so should staff. Ill have to see vid when im on laptop. I appreciate the input

Well my reasoning was for situations such as staff members messaging regular members about important things and staff having the privilege of knowing when the recipient has read the message, for instance, if a staff member messages a member about something controversial the member posted, the staff member will know when the member has read the message and therefore understands what they did was wrong. My reasoning wasn't really for casual messaging in which staff members are basically just like any other member, but for situations in which staff members are acting as staff.

Aug 27, 2015 23:07:59 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

I HAVE TO ASK: What browser is that? I try and test things in other browsers. I am currently relying on proboards auto placing feature to center the popup when the page is opened. If this is not working for insert_browser_here perhaps I can write my own code to center it in view. Version 1-0-1 should have an auto scroll to top after 4 seconds in case anchors are used. Also that black screen is big. Double the size of your current viewing window plus an extra 3000 pixels. 

The browser I am using in the video is Safari; however, I did experience the same thing in Chrome as well.

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Aug 28, 2015 22:09:04 GMT -8 dillonk47polik said:

Aug 27, 2015 22:21:56 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

I find as an admin its better to keep track of staff. If u want users to not know when staff read ur request then your a jerk. This way if u mass pm u can tell who has viewed and know when staff are inactive. If members have to save on every message so should staff. Ill have to see vid when im on laptop. I appreciate the input

Well my reasoning was for situations such as staff members messaging regular members about important things and staff having the privilege of knowing when the recipient has read the message, for instance, if a staff member messages a member about something controversial the member posted, the staff member will know when the member has read the message and therefore understands what they did was wrong. My reasoning wasn't really for casual messaging in which staff members are basically just like any other member, but for situations in which staff members are acting as staff.

Aug 27, 2015 23:07:59 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

I HAVE TO ASK: What browser is that? I try and test things in other browsers. I am currently relying on proboards auto placing feature to center the popup when the page is opened. If this is not working for insert_browser_here perhaps I can write my own code to center it in view. Version 1-0-1 should have an auto scroll to top after 4 seconds in case anchors are used. Also that black screen is big. Double the size of your current viewing window plus an extra 3000 pixels. 

The browser I am using in the video is Safari; however, I did experience the same thing in Chrome as well.

well i designed some safety checks. if this does not fix your problem i will need to register on your forum. Also do you need for staff not to count as a feature or are you suggesting? Try version 1-1

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

dillonk47polik I could also add a security feature that would detect when an inbox message has been viewed while javascript was not active. This would add a popup on the inbox page if detected just like the individual message page. Also maybe adding timestamps of when it was last viewed is an option if that's something you are interested in.

[dillonk47polik]

P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ Sorry for the late reply. I upgraded the plugin to 1-1-1. I think I like the white background better; but maybe instead of releasing two versions of the plugin (white and black), you could add a feature that allows the admin to choose the background color themselves, that way you'd only need to release one plugin and each forum could choose a color that matched their theme.

The popup box seems to be appearing in the center of the screen now, so I am going to assume it's now working like it should. If another similar problem arises, then I'll let you know The javascript security feature sounds cool; what happens when a read/viewed message is detected? Would the recipient still get a receipt? And I would be interested in the timestamp, like either a timestamp next to each message or a timestamp of just the last view time.

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Aug 31, 2015 19:06:51 GMT -8 dillonk47polik said:

P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ Sorry for the late reply. I upgraded the plugin to 1-1-1. I think I like the white background better; but maybe instead of releasing two versions of the plugin (white and black), you could add a feature that allows the admin to choose the background color themselves, that way you'd only need to release one plugin and each forum could choose a color that matched their theme.

The popup box seems to be appearing in the center of the screen now, so I am going to assume it's now working like it should. If another similar problem arises, then I'll let you know The javascript security feature sounds cool; what happens when a read/viewed message is detected? Would the recipient still get a receipt? And I would be interested in the timestamp, like either a timestamp next to each message or a timestamp of just the last view time.

If a read/viewed message is detected that is not found in the key while navigating to the inbox, a window will pop up that would force you to update the data for those keys similar to that of the message portion. And I was also wondering where the timestamp would be viewable at.

[Quozzo]

Hey P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓. The plugin is looking nice. I never used v1.0 but the white background in v1.1.1 is easy on the eyes. Maybe you could use feature detection to determine if the browser supports bluring, so those not using IE can benefit from CSS3.

It also only seems to record who has viewed the last message. So if a PM is sent to multiple people and they all view it, but someone decides to reply before the sender can see who has viewed it then they won't know who has, only who has viewed it since the last reply. Maybe you could use a... message key lol.

Also, if the user doesn't click on the "Read Message" button within the time limit then they are taken to some random page with the shoutbox, but the same URL for the message appears. It would be best to take them back to the "/conversations" page i think.

All in all, a good plugin

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 1, 2015 8:51:50 GMT -8 Quozzo said:

Hey P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓. The plugin is looking nice. I never used v1.0 but the white background in v1.1.1 is easy on the eyes. Maybe you could use feature detection to determine if the browser supports bluring, so those not using IE can benefit from CSS3.

It also only seems to record who has viewed the last message. So if a PM is sent to multiple people and they all view it, but someone decides to reply before the sender can see who has viewed it then they won't know who has, only who has viewed it since the last reply. Maybe you could use a... message key lol.

Also, if the user doesn't click on the "Read Message" button within the time limit then they are taken to some random page with the shoutbox, but the same URL for the message appears. It would be best to take them back to the "/conversations" page i think.

All in all, a good plugin

Wrong, Wrong, and Wrong. Lol.
It's not as much as that blurring isn't supported but also that it is 10x less secure. Anyone could just copy the message section and paste it in notepad and read their messages. It would also be harder to manage a security function. Since I create a barrier, I know that no other plugins will affect it, thus I know what properties it has and if any properties change, it will refresh the page. That concept would not work with plugins or codes that change styles on the message area. I could write exceptions for blurring, but security would be compromised. I could only blur the content AFTER it was posted. This would give time where it was still viewable. So I would need a white screen anyway. 

If a PM is set and they all view it, but someone decides to reply before the sender can see who has viewed it, only that person will count as viewed. But when the sender sends his, it will overwrite that the other parties have seen it. (Which they haven't seen his lastest message.) So in that it works correctly. The user who overwrote will also be returned to the conversation, which means he's seen all previous messages in the conversation because they are currently displayed on his screen. (Which is correct)

Post Key data would not solve this issue. This is related to stale key data only loaded on page load. So everytime you loaded the page you would have to save to like 10 post keys. But it would STILL overwrite the view data for other users who have not refreshed their page and use the QUICK REPLY only. Using the full reply will load the latest key data because it loads a new page. Not only that, but on the inbox screen you could no longer add who has viewed the message. This is because the post key would only be available for like the first post. (not positive even that it loads the first) So you would have to view page 2, 3, etc to figure out if it's been read.

If the user does not click on the message within 60 seconds, (to prevent stale key data and overwrites as you mentioned in comment two) it will automatically remove the security function, and remove the message area. It does not bring you to a new page. Anything below the message area such as the shoutbox would then be moved up.  So the user can try and refresh or navigate to any of the other links that are always present on the forum. I think it easier, for people who have missed their chance, to hit refresh than try and navigate through their inbox again. The message they opened could be on the archived page, or page 11 on their inbox. I couldn't redirect to that. (...easily) This would prevent them from running up unnecessary data usage. And it might possibly categorized as against TOS as redirect to a new page on page load, (since no user action had occurred)

Why do you think that it would be better idea to redirect to the inbox than to have it remain on the same page? Perhaps I'm missing something.

[Quozzo]

Sept 1, 2015 10:23:01 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

Sept 1, 2015 8:51:50 GMT -8 Quozzo said:

Hey P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓. The plugin is looking nice. I never used v1.0 but the white background in v1.1.1 is easy on the eyes. Maybe you could use feature detection to determine if the browser supports bluring, so those not using IE can benefit from CSS3.

It also only seems to record who has viewed the last message. So if a PM is sent to multiple people and they all view it, but someone decides to reply before the sender can see who has viewed it then they won't know who has, only who has viewed it since the last reply. Maybe you could use a... message key lol.

Also, if the user doesn't click on the "Read Message" button within the time limit then they are taken to some random page with the shoutbox, but the same URL for the message appears. It would be best to take them back to the "/conversations" page i think.

All in all, a good plugin

Wrong, Wrong, and Wrong. Lol.
It's not as much as that blurring isn't supported but also that it is 10x less secure. Anyone could just copy the message section and paste it in notepad and read their messages. It would also be harder to manage a security function. Since I create a barrier, I know that no other plugins will affect it, thus I know what properties it has and if any properties change, it will refresh the page. That concept would not work with plugins or codes that change styles on the message area. I could write exceptions for blurring, but security would be compromised. I could only blur the content AFTER it was posted. This would give time where it was still viewable. So I would need a white screen anyway. 

If a PM is set and they all view it, but someone decides to reply before the sender can see who has viewed it, only that person will count as viewed. But when the sender sends his, it will overwrite that the other parties have seen it. (Which they haven't seen his lastest message.) So in that it works correctly. The user who overwrote will also be returned to the conversation, which means he's seen all previous messages in the conversation because they are currently displayed on his screen. (Which is correct)

Post Key data would not solve this issue. This is related to stale key data only loaded on page load. So everytime you loaded the page you would have to save to like 10 post keys. But it would STILL overwrite the view data for other users who have not refreshed their page and use the QUICK REPLY only. Using the full reply will load the latest key data because it loads a new page. Not only that, but on the inbox screen you could no longer add who has viewed the message. This is because the post key would only be available for like the first post. (not positive even that it loads the first) So you would have to view page 2, 3, etc to figure out if it's been read.

If the user does not click on the message within 60 seconds, (to prevent stale key data and overwrites as you mentioned in comment two) it will automatically remove the security function, and remove the message area. It does not bring you to a new page. Anything below the message area such as the shoutbox would then be moved up.  So the user can try and refresh or navigate to any of the other links that are always present on the forum. I think it easier, for people who have missed their chance, to hit refresh than try and navigate through their inbox again. The message they opened could be on the archived page, or page 11 on their inbox. I couldn't redirect to that. (...easily) This would prevent them from running up unnecessary data usage. And it might possibly categorized as against TOS as redirect to a new page on page load, (since no user action had occurred)

Why do you think that it would be better idea to redirect to the inbox than to have it remain on the same page? Perhaps I'm missing something.

Sorry. I stopped reading the first paragraph when you said security. I don't want to be that guy, but JavaScript and security should not be in the same sentence. You could use a modal popup window to overlay the body which would prevent anyone from selecting the text. If anyone knows how to use the dev console, they know how to disable JS, or use a mobile.

It may function as you intend, but It wont display valid information. If I send a PM important enough to track who has read it and someone replies, I won't know who has read it, only who has read it since the reply and I don't care who has read the replies. I want to know the message I sent has been received. I wasn't sure if the message key could be viewed on the conversations page. Guess not .

I think taking them back to the conversations page would be best if it times out or if they select "Cancel", because they don't have any options on the current page with no PM available. Taking them back would suggest they need to accept the alert (and give the option to do so again) whereas the conversation page is empty, which looks like a bug more than anything. If I click a message and go AFK before seeing the message, I will be presented with a blank screen when I return. Besides, like you said. If they edit the template then you might not be hiding anything. If they were on page 11 or so then you don't need to check which page they were on, just use the history object.

But as always, it's just my opinion.


Edit: On an unrelated note: changing pages on the conversations page causes the "seen by" text to multiply exponentially.

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 1, 2015 11:44:24 GMT -8 Quozzo said:

Sept 1, 2015 10:23:01 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

Wrong, Wrong, and Wrong. Lol.
It's not as much as that blurring isn't supported but also that it is 10x less secure. Anyone could just copy the message section and paste it in notepad and read their messages. It would also be harder to manage a security function. Since I create a barrier, I know that no other plugins will affect it, thus I know what properties it has and if any properties change, it will refresh the page. That concept would not work with plugins or codes that change styles on the message area. I could write exceptions for blurring, but security would be compromised. I could only blur the content AFTER it was posted. This would give time where it was still viewable. So I would need a white screen anyway. 

If a PM is set and they all view it, but someone decides to reply before the sender can see who has viewed it, only that person will count as viewed. But when the sender sends his, it will overwrite that the other parties have seen it. (Which they haven't seen his lastest message.) So in that it works correctly. The user who overwrote will also be returned to the conversation, which means he's seen all previous messages in the conversation because they are currently displayed on his screen. (Which is correct)

Post Key data would not solve this issue. This is related to stale key data only loaded on page load. So everytime you loaded the page you would have to save to like 10 post keys. But it would STILL overwrite the view data for other users who have not refreshed their page and use the QUICK REPLY only. Using the full reply will load the latest key data because it loads a new page. Not only that, but on the inbox screen you could no longer add who has viewed the message. This is because the post key would only be available for like the first post. (not positive even that it loads the first) So you would have to view page 2, 3, etc to figure out if it's been read.

If the user does not click on the message within 60 seconds, (to prevent stale key data and overwrites as you mentioned in comment two) it will automatically remove the security function, and remove the message area. It does not bring you to a new page. Anything below the message area such as the shoutbox would then be moved up.  So the user can try and refresh or navigate to any of the other links that are always present on the forum. I think it easier, for people who have missed their chance, to hit refresh than try and navigate through their inbox again. The message they opened could be on the archived page, or page 11 on their inbox. I couldn't redirect to that. (...easily) This would prevent them from running up unnecessary data usage. And it might possibly categorized as against TOS as redirect to a new page on page load, (since no user action had occurred)

Why do you think that it would be better idea to redirect to the inbox than to have it remain on the same page? Perhaps I'm missing something.

Sorry. I stopped reading the first paragraph when you said security. I don't want to be that guy, but JavaScript and security should not be in the same sentence. You could use a modal popup window to overlay the body which would prevent anyone from selecting the text. If anyone knows how to use the dev console, they know how to disable JS, or use a mobile.

It may function as you intend, but It wont display valid information. If I send a PM important enough to track who has read it and someone replies, I won't know who has read it, only who has read it since the reply and I don't care who has read the replies. I want to know the message I sent has been received. I wasn't sure if the message key could be viewed on the conversations page. Guess not .

I think taking them back to the conversations page would be best if it times out or if they select "Cancel", because they don't have any options on the current page with no PM available. Taking them back would suggest they need to accept the alert (and give the option to do so again) whereas the conversation page is empty, which looks like a bug more than anything. If I click a message and go AFK before seeing the message, I will be presented with a blank screen when I return. Besides, like you said. If they edit the template then you might not be hiding anything. If they were on page 11 or so then you don't need to check which page they were on, just use the history object.

But as always, it's just my opinion.


Edit: On an unrelated note: changing pages on the conversations page causes the "seen by" text to multiply exponentially.

Sounds like a lot of work. 
Good eye on that bug, it seems to be caused by the last minute change I introduced to support the moderations such as mark as read etc. -Fix Change Page on Inbox Bug added to list
Redirect with history object- Instead I will Replace with a Message including a Refresh Button where messages have been removed to indicate user what happened with auto remove.
(still don't like the unneeded data reload but still makes it easier for users with a button)
Add Blur Effect to text and remove white background when text is ready. (considering)

Last Post Viewed - If multi user conversation, adds a Original Post viewed by at top. Do you think that would suffice your concept? Because the only way for things to work out would be by making the key push/pop only and there are not push_on pop_on quick reply and post commands. I wish there were. So that's a no go. A post key added as an array would fix that problem, but that would make this a two key plugin. Which would be a neat extension plugin but I have more pressing matters.

As always thanks for the rebuttal. I really like your point of view and observations. You have presented a convincing argument, helpful solutions, and bug reports. Keep them coming. Thanks for all of the support. 

I realize that from the point of considering this as a plugin I would create, and actually pushing it out here, I spent about 16 hours in the development process. I usually spend at least 20 hours on a plugin before considering release. So it is still a baby with much potential and much needed tender loving care. It really is trying to accomplish a lot for such a small idea. We did argue for 5 pages on how the plugin would be possible without violating terms of service. It may grow and mature into a 'must-have' plugin but for now it's a baby and not too shabby.

[Quozzo]

Yeah its cool. The only thing I would want really want changing is who read the PM before the latest reply. The easy work around is only to send it to one person, because even if they reply, it still records them viewing it. I wouldn't want to mess around with the design too much because I can see how it can be useful, I just prefer the other method I described.

What about this: If it recorded the time it was viewed by each user then it would be possible to determine who viewed which message. Key data by a user would mean they have viewed the original message, you could easily determine what was the last message they viewed by comparing the time stored in the key to the time on each message. It would be possible to put a small notice in the convo stating what messages certain users had read.

The other suggestions were only aesthetics really. I seen the other thread and I think this is a great work around (although I do believe an exception should be made by ProBoards to preserve the users experience but I digress). There are bound to be a few bugs and a few opposing ideas on how it should function, but that's what this board is for

Keep it up.

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 1, 2015 20:31:36 GMT -8 Quozzo said:

Yeah its cool. The only thing I would want really want changing is who read the PM before the latest reply. The easy work around is only to send it to one person, because even if they reply, it still records them viewing it. I wouldn't want to mess around with the design too much because I can see how it can be useful, I just prefer the other method I described.

What about this: If it recorded the time it was viewed by each user then it would be possible to determine who viewed which message. Key data by a user would mean they have viewed the original message, you could easily determine what was the last message they viewed by comparing the time stored in the key to the time on each message. It would be possible to put a small notice in the convo stating what messages certain users had read.

The other suggestions were only aesthetics really. I seen the other thread and I think this is a great work around (although I do believe an exception should be made by ProBoards to preserve the users experience but I digress). There are bound to be a few bugs and a few opposing ideas on how it should function, but that's what this board is for

Keep it up.

I was already going to start recording time.
Use that to create a bar on last viewed showing when someone stopped is a neat friggen idea. 
The only problem with this whole data concept is stale key data. 
If a user was in the middle of a message, ate some supper, came back in a couple hours, wrote and posted.
This would overwrite all views, last seen timestamps, and original message view status (if multiple users).

How would you suggest combating that problem?