Additional, optional barriers before commenting on an article?

feature
1

:mega: This scenario is mostly relevant when Discourse is used for embedded comments on a parent website, not necessarily when Discourse is used as a completely standalone discussion community site.

For sites like bbs.boingboing.net and discourse.codinghorror.com, where Discourse is used as a de-facto system to comment on blog entries, you have the classic Ars :banana: problem:

:question: Did people even read the article before commenting on it?

It’s tough, becase as you will learn from that experiment, for many, many people, the answer is, sadly, no.

I’ve been floating some ideas to combat that effect for quite some time now, and I noticed that one of the ideas – a literal quiz you have to answer before you’re allowed to comment on the article – was finally implemented by someone, somewhere!

Of course this does not scale at all, unless you fancy the idea of writing a custom quiz for every single blog entry you post. But it’s a fun concept to explore!

I think table stakes here are to visually indicate new users in some way. Discourse has done this since forever using a light grey “dim” username to indicate the new user is sort of ghostly and not fully substantiated because they just arrived.

image

In addition to the mandatory quiz, some other ideas I had that I think might also work:

Show, for new users, how much time they spent reading the article next to their username when they comment.

Steam does this to great effect. For every review of a game on Steam, you’ll see a small indicator next to the user indicating how much of that game they actually played. This is quite brilliant! When you see a negative review from someone that spent 10 minutes with a game, that is a very different thing than a review from someone who spent 10 hours with it.

image
image909Ă—931 179 KB

This is a little hairy because it requires the parent site to reliably track read time somehow.

Show, for new users, how many other posts they read in the topic next to their username when they comment

This is a related technique that’s a bit more meta, since it is about the discussion and not the original article. It would certainly let you know how interested commenters are in listening to other commenters (and not potentially duplicating or rehashing old topics) before chiming in with their own comments.

Of course you could do both #1 and #2 to cover all your bases; show both article read time in minutes, and comment read time (plus count) in minutes.

image

Require users to read every comment (or a percentage of comments) before posting their own comment

This is certainly more draconian than the quiz, but also doesn’t require a custom set of content for every blog post. The only thing that gives me pause here is that, as the discussion gets bigger and bigger, this is an almost impossible bar. If there are 500 comments, is it realistic to expect a new commenter to read all 500 before posting? So perhaps a cap is in order; read at least 100 comments before being allowed to add a comment of your own, or something like that?

image

Require users to rate a few random comments (by other new users?) before posting their own comment

This is the path of Civil Comments, but it’s unclear how dedicated they are to this approach as they appear to have pivoted pretty hard away from being a commenting system. I still love this approach overall, and I think it might scale better than the other 3 options above. I like the idea of being forced to introspect a bit about what others are trying to say before commenting, and you could cleverly get new commenters to vet each other in this manner, by restricting the rating to just other new commenters versus long time veterans who are unlikely to be doing anything untoward.

image
image691Ă—461 26.9 KB

Magical Mystery Machine Learning

There is also the “magical machine learning” path here, where services can vet a comment to see if it’s somehow toxic.

https://www.perspectiveapi.com/#/

This is more akin to the spam filtering we do with Akismet, but conceptually it’s very similar.

Your thoughts?

What do you think of these ideas? How else can we combat the Ars :banana: problem, where people write comments without spending any time reading? Any other concepts I’ve missed?

11 Likes
2

I think the concepts mentioned are certainly interesting, and worthy of discussion.

I think there’s also a certain element of “if you build a system, people will game it” involved. With that in mind, I think it might be worth considering how systems could be constructed that A) nudge people in the right direction, rather than outright demand things, and B) encourage and reward “good” behavior.

4 Likes
3

The Civil Comments thing seems the most Discourse-like gatekeeper, with reading other comments second. (I’d put a cap at 20 to 30, with both the first five and last five required for comment reading.)

It’s funny you call it the “Ars banana” problem, all they did was prove it with an inflammatory story. I hardly ever read the comments at Ars, and have commented myself under ten times. But I had one of my few picked as a promoted comment by the story author, which speaks to reading before posting.

The read-the-headline and blather mentality always seemed strongest at slashdot long before Ars. Their format of a headline, very brief summary and then all that space for comments really encouraged the post-without-reading interaction.

(And the skim/misread and attack mentality has been on the Internet since early Usenet days, predating the web.)

4 Likes
4

Demanding that people read things at a basic level before commenting on them is hardly much of a “demand”… the question is how much enforcement there should be?

4 Likes
5

What about asking new users how much of the article they read?

So before commenting you need to fill in how much of the article you actually read, with predefined options: 0/20/40/60/80/100%. This will then be shown in the comment. Of course people can lie but I think:

  1. It is hard to lie for most people or at least a bit uncomfortable.
  2. If someone filled in 100% but obviously did not read the article I think it’s easier to give some kind of warning.
1 Like
6

I can’t really see each topic having a comprehension test. Simplest would be to have a minimum “read time” based more on “in the browser” than any guarantee that any was actually read.

The only thing that I can think of that I ever needed to do that was even remotely related was a type of CAPTCHA
“The fourth word of the second sentence in the third paragraph is ____”

Maybe a “the last longest word in the OP is _____” wouldn’t be too severe? (substantiated?)

7

I feel the CAPTCHA one would be very brittle in real usage. The quiz idea is not really scalable, just interesting.

8

why doesn’t this exist here in meta (or discourse)?

9

Definitely a customizable cap number with option to require first and last or top good/bad question along that cap. The second option could be set if a post have more comments than certain threshold.

This way though, you will not be demanding so much, as enforcing some baseline interaction before replying. But this is not a direct fix for not reading the article, rather for not reading the comments.
How would you account for someone, who is clicking yes/maybe/no until a counter is hit? By setting reading timers based on the length of the comment itself?
Or someone who is just scrolling the comments until a reply button shows? By setting minimum reading time for a given comment to be set as read (not sure how Discourse handle this in general at the moment)? You could also autoincrease that time based on several metrics like negative replays and/or reporting.

10

The time spent on site is one of the most reliable options given here, but this is easily gamable. What could be done instead, is copy Ars’s method. Put a specially crafted sentence randomly in the article after the 50% mark, and require a word in it or derived by it, before posting your first comment. This could be automatically disabled for trusted users.
The issue is, that it requires integration with the parent platform, or at least preloading custom JS that could do this in the browser side.

But none of those fix the fundamental issue of someone wanting to post for post’s sake. Also it does not fix the problem if someone posts are consistently good/likable, but not on topic or maybe just tangentially connected to what is being discussed.
What those solution do is to put hurdles before you post so you’d really have to be invested or interested in posting comment, but not necessarily possessing the knowledge of the topic at hand.

Instead, those two groups should be hit where it would really hit them - post count and post visibility. I am sure there are other threads where those options are being/were discussed, but I haven’t been on this site for quite some time.
So instead I’ll just spitball some quick ideas:

  • Prevent negatively rated comments after a certain customizable amount of downvotes/reports from counting towards a users overall post numbers. Hide it altogether after a second threshold.
  • Maybe implement a relevancy button for separating bad comments from irrelevant ones, if there is such distinction even :slight_smile:
11

Strategies that require tracking the user have a fatal flaw. For public articles and public comments, the user can be logged out while reading and only log in to comment. This happens to be what I have done just now for this post.

Additionally, the user might not even be on the site at all while they spend 10 minutes carefully reading the article, or dozens/hundreds on the site. I almost exclusively read web sites via rss, but your scheme doesn’t know that. Consider also instapaper.

In these cases, it’d appear that I arrived fresh to the discussion and started posting, but that’s not true.

1 Like
12

Agreed, that’s a good way of looking at it.

13

I feel that a lot of this is a :dollar: :dollar: rich people’s problem.

For my modest and not so popular blog, if anything, I want to reduce barriers not raise them, I do not have a comment problem.

If we are going down this path we would need to build a component into the “embedded js” that also tracks read time on the OP article. (which would help to a degree - but keep in mind stuff like twitter app will default to reader mode so you get no tracking)

10 Likes
14

Of course you could do both #1 and #2 to cover all your bases; show both article read time in minutes, and comment read time (plus count) in minutes.

It would be complicated to read/understand quickly when reading through a large volume of comments.

Any “quality” metrics need to be turned into something that another reader can quickly understand as they skim down the posts, to help guide them to what may actually be worth reading. Or you just don’t show them at all, either by option or default.

But anecdotally from my own experience: the most prolific, and therefore possibly highest scoring posters, with a lot of time on their hands for reading articles, might not always have something worth reading.

15

My interest is having this threshold used very stringently but also sparingly on a weekly News Letter’s articles, with commenting restricted to paid memberships.

16

I think you might need to more clearly define the problem you are trying to solve. You start off talking about a specific case of users commenting before they have finished reading the article.

I don’t think measuring engagement with other comments nor other articles on the same site really helps with that.

Also, are you trying to persuade the crash-commentator to give up or to go back and read the article?

If the crash-comment gets submitted, and you are somehow able to identify it as such, what are you hoping to achieve by flagging it to other commentators?

The root of the problem is that article headlines are intended to provoke a response from people who have not yet read the article. The decision to crash-comment may well occur before the reader even clicks on the link.

Personally, I would add a “Jump to Comments” button at the top of the article to allow people to self-identify. Any subsequent comment is then visible only to its owner. They get to vent but no-one else has to listen.

17

I remember mentioning that sometime back Discourse comments need to be able to fully replace the commenting systems of blogs. You know, with full ability to sign up/in from the blog post comments section.

With that I’d have dropped Disqus for my tech site. But I was told there is a reason that won’t happen in this lifetime. I didn’t buy it but had to live with it, because that’s not the reason I got Discourse in the first place, just thought it would be a good idea to get a community signed up when sign up is easy from the Wordpress plugin at the end of a blog post.

18

One version of this is now being developed here:

3 Likes