Introduce the concept of "read" and "unread" comments for better workflow in the admin

[markjaquith]

The Moderation Queue is a great way to manage your comment workflow. All comments go in there, and you approve, spam, or delete them. At the end you get a nice little "0" and you know you've dealt with all new comments. This doesn't work for people who don't moderate every comment. They have no idea when they are done, and which comments they have or have not looked at.

I'd like to add a comment_read column to the comments table. It would be either "1" or "0". There would be a new sub-tab for Comments: "Unread comments (%d)" This page would be just like the Moderation page, except that it would only show comments with comment_read = 0. This could act as "comment workflow central" for both people who pre-moderate and people who post-moderate. Unapproved comments would have the actions: Approve, Spam and Delete. Approved comments would have the actions: Archive, Spam and Delete. Clicking any of these actions would both carry out that action AND mark that comment as read, making it disappear from the "Unread comments" page. ("Archive" only marks it as read).

Enterprising theme developers could even have this status shown on the public blog, so that people know whether their comments have been seen.

For background on this idea, please see ​The Comment Inbox

Note that this has benefits for people who moderate every comment, because they can now store comments in the moderation queue (comments they want to remove from the blog, but not delete) without that getting in the way of their comment workflow.

[filosofo]

Instead of adding an extra column to the comments table, why not handle this in a meta-data table?

• You don't really need a "read" or "unread" status for every comment: "spam" and "delete" are always in "read" status, in that like your Gmail account, they're not part of the inbox. Unapproved comments are "unread." That leaves distinguishing between "read" and "unread" approved comments.
• It would use less disk space, since instead of making every one of thousands of comments have a "read" status, we could assign a "read" status meta-value to just "unread" comments (since "unread" comments should be in the minority). Then we would delete that meta-value once the comment is read. I.e. all unread comments have an "unread" meta-value of "1", and read comments don't have an "unread" meta value at all (which also provides simple backwards compatibility).
• We need that meta-data table anyways, for all kinds of cool things like undo delete, threaded comments, comment voting systems, etc., and we could move the user data there.

[markjaquith]

I'd be fine with that approach. I've long been in favor of comment meta.

[Denis-de-Bernardy]

this should be on a per user basis, ideally. and stored in a user_meta, once that thing accepts multiple items with same keys.

[jane]

3 years! We have comment meta now. :)

I would really like to have an "Archive" action to get comments I don't want to delete but don't need in the main list out of the way (like CoTweet had).

[westonruter]

The concern I have with adding a new global commentmeta field for read state is the number of new entries this would add to the database. Presuming all non-spam comments all get eventually read, this means an extra commentmeta entries would always get added for each, so I do not think there would be a space savings for not adding a new column to comments. Assuming that the read state would be normally queried so that the read state could be displayed with each comment when rendered, this would require an extra JOIN in comment queries, definitely slowing down the performance of commenting in general. With this consideration, I think adding a new column to the comments table could be a better approach.

[westonruter]

Something else that came to mind. Should there be a separate comment read state for each user, instead of (or in addition to) a global read state for each comment? Having user-specific read data would be useful on the frontend to allow each user to keep track of read/unread comments on all blog posts. Having user-specific read states would definitely require commentmeta (or usermeta). User-specific read states is probably better for plugin territory, beyond the global read state proposal introduced by this ticket.

[mordauk]

Andrew Norcross, Tom McFarlin and I played with this kind of idea in our ​Comments Not Replied To plugin. We took the comment meta approach, though I'd personally be more in favor of adding a new column to the main comments table.

One concern I can see popping up is how to handle multi-author sites. A read column is great, but it might be useful to know who read the comment. Would it be limited to the post author? While that could work well in some scenarios, it would break apart in others.

[Offereins]

Perhaps set the read column value to the user's ID of the user that first read it. The default unread status would than be indicated with 0. If one would like to have a per-user read status, this would be way more difficult.

[wonderboymusic]

This is perhaps plugin material for now.