Make WordPress Core

Opened 9 years ago

Last modified 3 years ago

#33627 new enhancement

In-Context Comment Moderation

Reported by: chriscct7's profile chriscct7 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Comments Keywords: needs-patch
Focuses: administration Cc:

Description

One of the more painful points in the comment moderation UX revolves around knowing whether or not a comment is in context. Right now, WordPress says who a person was replying to and offers a link to the frontend of that comment on replies to a comment. However, it can be quite tedious to go view the original comments a bunch of people were replying to to see if the reply was in-context.

An easy fix for this would be to offer a "Show context" link next to the "replying to {name} link on replies, that when clicked, would ajax show the comment the pending comment was originally replying to.

Change History (24)

#1 @chriscct7
9 years ago

  • Milestone changed from Awaiting Review to Future Release

#3 @jeffr0
8 years ago

Thanks Chris for creating this ticket as you beat me to it. Here are two screenshots of the UI I'm using via Stephen Cronin's Show Parent Comment plugin. I've used it for about two weeks and I like the UI. I'm not sure if it will work for millions of other people but it works great for me!

A comment reply with the show more link - https://cloudup.com/iESK6WCPKNL
A comment reply showing the full text of the reply - https://cloudup.com/istq0jRnNJ8

Last edited 8 years ago by jeffr0 (previous) (diff)

#4 follow-up: @quicoto
8 years ago

+1 for this. I find myself visting the post page evertime I need to reply a nested comment

#5 follow-up: @Ipstenu
8 years ago

The problem with Stephen's plugin is that it 'double loads' the content, which means for anyone with wordy commenters, you could make the comments page very slow :/ (I have similar code I've used for a while, but it has the exact same issue)

Maybe a link that pops up on click?

#6 in reply to: ↑ 5 ; follow-up: @quicoto
8 years ago

Replying to Ipstenu:

The problem with Stephen's plugin is that it 'double loads' the content, which means for anyone with wordy commenters, you could make the comments page very slow :/ (I have similar code I've used for a while, but it has the exact same issue)

Maybe a link that pops up on click?

Not sure if it's this what you mean but can't just that content be loaded via Ajax after clicking "See parent comment content"?

That way it wouldn't add extra weight to the page, the extra content would be served on demand.

#7 in reply to: ↑ 6 @StephenCronin
8 years ago

Replying to quicoto:

Replying to Ipstenu:

The problem with Stephen's plugin is that it 'double loads' the content, which means for anyone with wordy commenters, you could make the comments page very slow :/ (I have similar code I've used for a while, but it has the exact same issue)

Maybe a link that pops up on click?

Not sure if it's this what you mean but can't just that content be loaded via Ajax after clicking "See parent comment content"?

That way it wouldn't add extra weight to the page, the extra content would be served on demand.

Loading them via Ajax would work. Though of course it would be slightly slower to load each parent comment via Ajax than if it were already on the page. I can see that for some sites loading it via Ajax would be better (if heavy comments), while for others loading it on the page would be better (if clicking to see every parent).

Typically there are only 20 comments shown on the comment moderation screen (although this can be changed) and only the direct parent comment is loaded when the Show Parent link is clicked (in my plugin at least). In most cases it would be loading 40 comments rather than 20 (assuming all comments had a parent).

That may be too heavy for some sites with long comments or with the default number of comments increased, but most can probably handle it.

But core would need to cater for the lowest common denominator, so Ajax is probably safer. It's worth noting that Chris's suggestion when creating this ticket was to bring them in via Ajax.

If we could fetch all the parent comments in one HTTP request, we could 'lazy load' them after the initial page load. Best of both worlds? Wouldn't be so keen on that if it took 20 HTTP requests though.

What do you think?

#8 follow-up: @Ipstenu
8 years ago

If we could fetch all the parent comments in one HTTP request, we could 'lazy load' them after the initial page load.

Wouldn't that be the same issue though? If you have 20 comments, all with long parents (say 200 words, which is not outside the realm of possibility), it would have to load all that before the comment page loads.

Basically the issue is that 20 comments with 20 parents means 40 comments loaded on a page.

#9 in reply to: ↑ 8 @StephenCronin
8 years ago

Replying to Ipstenu:

If we could fetch all the parent comments in one HTTP request, we could 'lazy load' them after the initial page load.

Wouldn't that be the same issue though? If you have 20 comments, all with long parents (say 200 words, which is not outside the realm of possibility), it would have to load all that before the comment page loads.

Well, the comment page would load without the parent comments and be fully functional.

Then later (perhaps when the user starts scrolling), it makes an Ajax request and loads the parent comments in the background. The user won't notice it happening, but the contents will be there and expand instantly when they click the site parent link.

You don't get held up on page load and you don't get held up on clicking the show parent link.

I could be missing something but it seems like the best of both worlds.

Last edited 8 years ago by StephenCronin (previous) (diff)

#10 follow-up: @chriscct7
8 years ago

I feel like lazyloading all of the comments could be a bad idea. If the display options are set to show say 100 comments (because maybe a site gets a ton of comments each day), lazyloading that many comments could be disastrous. Further on low bandwidth mobile phones, this could cause performance issues. Originally, my idea was that when you clicked on the "show context" link, it would grab maybe the parent comment (if present) and maybe the last 2 on the same hierarchical level, and if that couldn't be done in nice UX then maybe just the one it's immediately replying to.

If lazyloading all of the comments is the solution that is to be proceeded with, perhaps Cronin's idea about lazy loading the first couple ones and background loading the remainder as scrolling happens is the right path to take.

#11 in reply to: ↑ 10 @StephenCronin
8 years ago

Replying to chriscct7:

Originally, my idea was that when you clicked on the "show context" link, it would grab maybe the parent comment (if present) and maybe the last 2 on the same hierarchical level, and if that couldn't be done in nice UX then maybe just the one it's immediately replying to.

Ahh... My idea was just to show the direct parent and that's it. My thoughts were that's enough to get context in most cases and it avoids the complexity of trying to show any more. Maybe showing the last 2 on the same hierarchical level would be useful without being too complicated. But at some point you're probably better off to use front-end moderation tools, because then you can see the entire context.

I feel like lazyloading all of the comments could be a bad idea. If the display options are set to show say 100 comments (because maybe a site gets a ton of comments each day), lazyloading that many comments could be disastrous. Further on low bandwidth mobile phones, this could cause performance issues.

I did some quick and dirty maths. With 100 comments, perhaps 80 of them will have parent comments. *If* we're just showing the direct parent comment, that's an extra 80 comments on the page. Using Mika's suggestion of 200 words per comment, that's an extra 16,000 words on the page.

I copied and pasted some real comments into MS Word until it reached 16,000 words, then copied them into a text file. That came to 80KB. Let's make it 100KB to allow for markup, etc. We'd probably just be returning JSON with a comment_ID and the comment itself, so not much extra overhead would be added to that. So we could be adding 100KB (unzipped) to the page, which isn't *too* bad if it can be combined in a single HTTP request, although I take the point that on mobile devices this could be a problem.

Because this is happening asynchronously behind the scenes and would presumably fail gracefully, it shouldn't slow the page down or the user's experience down, even on mobile. The biggest impact would be the extra 100KB (although it would be gzipped in most cases) used on your data plan. That could be a problem if you moderated comments on your mobile device a lot.

The JavaScript adding the parent comments would need to be optimised/efficient so it didn't bog things down on mobile, but I think that's achievable. And I don't think the server overhead would be a problem, given this is just happening for admin requests.

To put this into context, when I set WordPress to show 100 comments, I get around 90 HTTP Requests. That is likely to have a greater effect on the performance of the page than a single asynchronous HTTP request, even at 100KB (apart from the data plan argument). If someone is successfully working with the current system, adding the parent comments via Ajax shouldn't affect them.

Or am I missing something here?

Of course, the maximum number of comments someone can choose to display is 999, which would make that one HTTP request very big (1MB). But I tried that (for fun!) on my site and found that there were 700 HTTP requests, so the same arguments above apply (pulling in the parent comments via Ajax isn't your biggest problem!). But that brings me to:

If lazyloading all of the comments is the solution that is to be proceeded with, perhaps Cronin's idea about lazy loading the first couple ones and background loading the remainder as scrolling happens is the right path to take.

I think that would probably be the best solution. There'd be no delay when Show Parent was clicked, but the initial page load wouldn't be affected. There'd be a single asynchronous HTTP request once the page has finished loading, to fetch the first so many (10?) parent comments in the background. Then as the user scrolls there'd be more HTTP requests, but these could be bunched together too (10 parent comments grouped at a time?).

What do you all think about that?

#12 @Ipstenu
8 years ago

One small note: Don't assume only admins. This would be admins and editors. Doesn't change it *too* much, but Editors have the moderate_comments cap :)

#13 in reply to: ↑ 4 @CarltonBale
8 years ago

Replying to quicoto:

+1 for this. I find myself visting the post page evertime I need to reply a nested comment

I agree that this functionality should be added. It's not efficient to go to each post to see the context of a comment response. That context should be shown in the comment moderation view as well.

#14 @Travel_girl
7 years ago

I´m not a big fan from a pop up, but I like the way how it is displayed in the Plugin "Show Parent Comment". Probably it would make sence also to add a "show the conversation" button, no load the while conversation.

I´m just not quite sure about the loading time with that option.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


6 years ago

#16 @dotrex
6 years ago

I like the "accordion" idea to show the parent comment/context. (This UI: https://cloudup.com/iESK6WCPKNL)

Maybe only show the parent comment this way and a "show the conversation" button that would display all the comments. But in this case it would have to be displayed in a modal, or on a separate page due to the large amount of content.

Would love if we could have a quick sketch or mockup to show the UX problem and make it easier for anyone working on it to understand what’s happening.

Last edited 6 years ago by dotrex (previous) (diff)

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


5 years ago

#18 @JoshuaWold
5 years ago

I second the comment from @dotrex. We just chatted about this in our Design triage; it'd be easier to chat about if we could see the problem with a screenshot.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


4 years ago

#20 @nrqsnchz
4 years ago

  • Keywords ux-feedback removed

We discussed this ticket during Design triage today (https://wordpress.slack.com/archives/C02S78ZAL/p1585586822080700).

We agree this ticket needs a screenshot or sketch in order to better understand the problem.

#21 @imath
3 years ago

  • Milestone changed from Future Release to 5.7

This ticket was mentioned in Slack in #core by lukecarbis. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


3 years ago

#24 @hellofromTonya
3 years ago

  • Milestone changed from 5.7 to Future Release

With 5.7 Beta 1 landing in less than 6 days and no activity, we agreed during core scrub today to punt this ticket to Future Release.

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

Note: See TracTickets for help on using tickets.