This is a brief question/request regarding LessWrong and AlignmentForum UI and voting buttons.

Uncontroversial (I expect) factual statements

When I read a post or comment which fills more than one screen, I want to consume the whole content before providing any reinforcement or agreement signals.

But the vote buttons are rendered at the top of posts and comments, so I have to scroll back up again[1], and (especially if I'm reading through a thread of comments) it can therefore be tricky to keep track of my place.

A basic request

Could we have additional voting buttons rendered (perhaps optionally configurably?) at the bottom of posts and comments? This would make the above, presumably common, workflow that little bit more straightforward.

Or (more fiddly but maybe better), could the buttons float and follow me down the page, or some other fancy UI trick?

A more controversial normative claim

It seems like the factual statement of my reading/digesting/voting workflow above should be the default workflow. After all, how can you provide a reliable voting signal for something you haven't consumed?[2]

Would it make sense to always have the buttons exclusively at the bottom, to nudge[3] the 'correct' workflow to be marginally easier, and 'aberrant' workflows (like voting based on the author's name or the title or introduction)[4] to be marginally more difficult? What might the downsides be (beside the obvious developer opportunity cost)?

Even more controversial speculation

What if the karma/agreement tallies were also at the bottom? (i.e. unseen until after deliberate scroll)

It wouldn't in principle change my options as a reader, but it would make it easier to avoid anchoring and instead evaluate content on its merit (but I could still readily see the community consensus signal and adopt that information into my all-things-considered opinion).

This seems a lot easier to backfire, because often we filter what to even start reading based on more quickly-digested summaries (probably quite rightly), which include karma and the like, as well as recommendations. It might work better, for that reason, if at all, on comments than on top-level posts.

  1. I almost always read things from top to bottom, at least on a first reading, which I also expect to be relatively uncontroversial. ↩︎

  2. There are of course degrees of what constitutes 'consumed' and 'reliable'! ↩︎

  3. cf Recommendation Features on LessWrong ↩︎

  4. Gasp! Surely not! ↩︎


New Comment
13 comments, sorted by Click to highlight new comments since: Today at 12:12 PM

I actually had the same desire a while back and began a Pull Request that would place vote buttons at the bottom of long comments by detecting whether the upper buttons were still in view or not. Didn't finish it though, though I think it's a very reasonable idea!

I think not having them at the top is probably the wrong choice since many people use the karma to decide what to read or not. I suppose you list the karma at the top but have the buttons only below....

GreaterWrong has "kibbitz mode" that hides names and karma, perhaps we should also have that on LessWrong.

Now that you promote this to my attention again, I'll think about it some more. Good idea, just a matter of prioritization. (LessWrong/Lightcone continues to hire)

Thanks for this response. FWIW I don't say

beside the obvious developer opportunity cost


I didn't know that about GreaterWrong, thanks.

But the vote buttons are rendered at the top of posts and comments

There are vote buttons at the bottom of posts, fyi.

Wait, has this always been?? Thanks Ray!

It's dynamically determined based on the size of the post. Short posts don't have them at the bottom, long posts do.

This is an example of a post for which I wish I could "disagree" without "downvote"ing!

I think I want only one set of buttons and I want them to be next to the current tallies and I want those to be at the top so I can use them to decide what to read. But I of course wouldn't mind if you were able to opt in to a different system.

EDIT: this response is to the second bit about the object level of this OP, not the first bit regarding agree/reinforce buttons on top level posts, with which I straightforwardly agree.

You only want one set of buttons (sounds reasonable to me). And you want the voting buttons to have a tally next to them (I get it, but I'm not sure it's needed). You re-emphasise the importance of tallies for guiding what to invest reading time into, which means a tally needs to be at the top (I heavily agree in absence of some other guide, perhaps a great recommendation system).

Is it important to render only one tally? Or could a tally appear without buttons at the top/homepage/sequence-page and a duplicate tally appear at the bottom alongside buttons?

Interesting. I would be open to trying this.

Why not also have author names at the bottom, while you're at it.

I second the request. I already shared this idea with Ruby and he said he liked it (he might have also thought about it himself before, I don't remember). Probably just didn't get around to it yet.

This seems a lot easier to backfire, because often we filter what to even start reading based on more quickly-digested summaries (probably quite rightly), which include karma and the like, as well as recommendations. It might work better, for that reason, if at all, on comments than on top-level posts.

Without (yet) commenting on the mechanism itself, I'll provide my self-observation that I almost never use top-level post karma for explicit prefiltering, whereas I use comment karma for prefiltering primarily on the implicit level provided by the way they are sorted in the interface but also to a lesser degree on an explicit level. I attribute this retrospectively to:

  1. Top-level posts being fewer and of less variable quality to begin with.
  2. More of the variance in which top-level posts I want to read being based on topic. By comparison, more of the variance in which comments I want to read conditioned on them being on a specific top-level post that I'm already interested in is based on quality. (Quality implicitly includes “on-topic” in that context anyway.)
  3. The positioning of the UI elements in posts versus topics.

(3) is something that I notice is surprising to me now that I think about it. I barely notice the voting elements for posts—why is that? They're not particularly small in size, and while they're lower-contrast than the main text, this is also true for comments. I would guess it's mainly geometry and flow. When I start reading a comment, the eye-catching header in bold leads straight into the time-since and karma display on the same line. But when I'm reading a post from the front page, the karma is part of the second, longer “metadata” line that I skip over as an entirely different group. When I'm reading a post by itself, the voting gadget is off to the side of the title and uses vertical arrows, again an entirely different group that I skip over visually. The second voting gadget between the main article and the comment section, I think, gets subsumed—the gap is what I'm scanning for when I'm trying to scroll to the comments, and then it reads as “a bunch of whitespace (that's the important part) that happens to have a voting gadget in it for ornamentation”. The latter may as well be one of those fancy curly figures that get used as separators in books sometimes.

To be clear, my more controversial speculation does not go up to scanning the user's brain to confirm their ingestion, digestion, and careful consideration of the post's content[1] before allowing them to cast votes.

It does seem important that people be able to sometimes express 'I would like more people to see this (kind of thing) after my superficial read but I don't have time to digest in detail now', but it might be a good thing if this were necessarily at least a tiny bit deliberate.

  1. (if only because I don't know how to implement this and if I did, I find it hard to imagine a world where the most pressing use of this technology was optimising LessWrong karma UI - but well, maybe) ↩︎

New to LessWrong?