[wp-trac] [WordPress Trac] #33627: In-Context Comment Moderation

[WordPress Trac]

#33627: In-Context Comment Moderation
-------------------------------------+-----------------------------
 Reporter:  chriscct7                |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Comments                 |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch ux-feedback  |     Focuses:  administration
-------------------------------------+-----------------------------

Comment (by StephenCronin):

 Replying to [comment:10 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?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33627#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform