Manually mark new comments as read

[xaur]

Governance discussions are serious and I'd like to not miss anything. I'd like to avoid an unintended loss of the "unread" marks by e.g. an accident page reload. This can be prevented if the "unread" marks are removed manually, e.g. with a click on the comment area (similar to reddit admin feed).

[xaur]

Just had this problem yesterday. I opened a proposal to read new comments and had them highlighted. Then I couldn't finish due to interruptions and closed the browser. As all new comments were marked as read automatically, today I can't continue my reading of unread comments because I lost track of them.

I think the unread -> read transition should happen by click anywhere in the comment box since it's a common operation. Also there must be a way to read -> unread something I'd like to re-read tomorrow, but this is less common and can be done with tiny mark unread link-buttons near the permalink and reply.

[xaur]

I'm destroyed. I opened a proposal to read newly highlighted comments. Suddenly a paralyzing "your session will expire in less than a minute" and I couldn't do anything. Now all highlighting is gone and I need to do the scrolling and looking at comment IDs again to figure out what I didn't read.

Filed a bug to not do any disturbing automatic view changes as #1031, but manual read state management would prevent state loss too.

[xaur]

Insight: proposal owners can benefit from this feature. Current UX does not fully facilitate replying to all questions. Unread state is lost on page reload. Email does not solve it fully either: email notifications do not contain comment body and do not allow to reply via email.

With manual read state control, proposal owners have an extra tool to never miss a question. They can keep unread markers on comments until they are fully answered.

[xaur]

Another insight: manual "read" marks can yield interesting data for analysis. For example, count how many people read a given comments and compare it to its score (suggested here).

Upvoting or downvoting a comment should set the "read" mark.

[victorgcramos]

I can work on that!

[xaur]

@victorgcramos some thoughts on your question in chat.

Storage: As Politeia gets more and more proposals, I expect most users will have much more unread comments than read ones, hence I would store (user_id, comment_id) pair for each read comment. I would not store it in Git because a) privacy, b) the data is not critical. Still, losing read state data would be painful for users so it must be backed up periodically.

Usage: When user requests proposal page it should contain a set of all comments in that proposal that are read by the user. Then the js shall mark all comments not in that set as unread. Clicking anywhere in the comment area marks it as read and sends a small request telling "I've read comment_id". Obviously that request shall not specify user_id. Ideally, sign it with user's key as all other requests. "I read X" request is similar to an upvote request in its frequency and size. Also think about possible load on the server, perhaps it is worth accumulating and batching these requests.

Consider "Mark all as read" button somewhere on the proposal page.

[xaur]

Forgot to add - I'm not one of Politeia devs, just jumping in some topics where I have ideas.

[victorgcramos]

I'm doing exactly what you said hahaha, it looks like you read my mind lol.

[xaur]

I think setting comment read marks should not be locked when proposal is closed (approved/rejected/abandoned) so e.g. new user could investigate old stuff.

[lukebp]

I don't support this feature for the following reasons:

1. We already highlight the comments that the user has not read. Accidental reload of the page is an edge case that does not deserve an entirely new feature.

2. Even if you do accidentally reload the page, why can't you just order comments by "New"? If there is an issue with ordering comments by "New" then it should be addressed by improving the "New" comment ordering, not adding a whole new feature.

3. I don't like the UX of marking a comment as read by clicking on it. This type of UX might be appropriate for admins since they are responsible for censoring comments and its important that they see every comment, similar to the reddit admin feature, but not for everyone.

[marcopeereboom]

Agree.

[xaur]

@lukebp I disagree:

We already highlight the comments that the user has not read. Accidental reload of the page is an edge case that does not deserve an entirely new feature.

I hit this edge case multiple times and lost my reading state. Some reloads were accidental, while in some cases I just had to shutdown the browser before I could finish reading the new comments.

(And some were due to #1031 which is addressed by #1183.)

Even if you do accidentally reload the page, why can't you just order comments by "New"? If there is an issue with ordering comments by "New" then it should be addressed by improving the "New" comment ordering, not adding a whole new feature.

Ordering by "New" only helps to spot new top level comments. For nested replies it will only sort them under their parent which might be old. Therefore sorting the tree is not too helpful to quickly identify comments that I did not read.

I don't like the UX of marking a comment as read by clicking on it. This type of UX might be appropriate for admins since they are responsible for censoring comments and its important that they see every comment, similar to the reddit admin feature, but not for everyone.

This is exactly how the old Reddit modmail works and for me it feels very fast and simple because the click area is large (full comment box).

I agree that is not needed for everyone but admins alone make this feature worthwile. Besides, I disagree that only admins need it. Politeia is not a casual forum, it is a place where important stuff is discussed and posted and where investigator-types are more likely to dwell. I read comments very carefully to form my opinion and voting choice.

[lukebp]

Ordering by "New" only helps to spot new top level comments. For nested replies it will only sort them under their parent which might be old. Therefore sorting the tree is not too helpful to quickly identify comments that I did not read.

Right, so why can't the sorting be improved to make it possible to view all comments by "New" and not just top level comments.

I don't disagree that this would be useful, I disagree that this should be added to the API. The API should be kept as small and simple as possible. If it doesn't absolutely have to be handled at the API level, it shouldn't be.

[xaur]

Right, so why can't the sorting be improved to make it possible to view all comments by "New" and not just top level comments.

Never thought of that. Filed as #1209.

I don't disagree that this would be useful, I disagree that this should be added to the API. The API should be kept as small and simple as possible. If it doesn't absolutely have to be handled at the API level, it shouldn't be.

Right, ideally such things are stored on the server which requires to add an API to store and load the read marks. As a half solution, the read marks can be stored on the client too. That would be still way better than not having them at all. The implication of storing them on the client are either accept their loss in case of a browser wipe, or implement an import/export tool to store/load the (proposal id, comment id) tuples.

[lukebp]

Right, ideally such things are stored on the server which requires to add an API to store and load the read marks.

My point is that if you have improved comment sorting, you don't need this feature anymore. The marginal value that it provides is not worth the API bloat that it would add.

politeiagui already shows you unread comments. The original issue on this thread dealt with the scenario where the page gets refreshed erroneously and the unread comment highlights go away. If we have improved comment filtering, you can just order comments by "New Flat" and make sure that you've read them all. No need to add anything to the API.