Make users read before they vote
blog.hiremebecauseimsmart.com
blog.hiremebecauseimsmart.com
Yes: yourself. Is that really so hard?
I'd like to think that we can manage at least that much responsibility on our own without it being forced on us through technical restraints.
Your argument could be made for many features, like "please don't downvote comments before you have 500 karma", or "rather than protect against SQL injection, I'll ask the users not to do so".
Besides, this could be a way to detect accounts that are votebots -- why would they click on the article unless they know that you're tracking it?
A downside to this change would be that sometimes I'll read an article somewhere else first, and then see it here. I don't always re-open it before voting; I don't think this behavior is bad.
Just like you can't make anyone read a EULA before clicking "I agree". You can force them to scroll through it, but then you sometimes end up with the comical scroll-all-the-way-down button as well. (Can't remember where I've seen that, but it's more than once.)
But the annoyance of having 25 new tabs would dissuade me enough of the time to make the tweak worthwhile.
As for spammers -- you have to take a separate approach with them. What I'm targeting are not the malicious but the _careless_ rulebreakers.
(I didn't go into this level of detail in the article because I thought it would come up in comments.)
Minimalism and simplicity work well for HN, and I don't think there'd be a clear enough benefit here to warrant the added complexity and occasional annoyance to legitimate users.
HN is less simple than you think: you can't vote or make polls until you have a certain level of karma; you may be hellbanned; you can't downvote responses to your comments; comment karma is displayed as the number (max -4, real-karma), but still calculated below that; there's a delay -- not a constant delay, but exponential based on the nesting length -- of time after a comment is posted before any replies can be made. HN is complicated; it just doesn't make it obvious to the user. Going along with other design choices that have been made, pg might implement this by simply dropping votes that are made without loading the page; the user would never even know this happened. It wouldn't make the complexity on the user any greater.
And yes, spambots or human spambots can click the link first: it is trivial. But -- assuming this is a problem; I don't know that -- if some don't know about it, their votes wouldn't count. Problems don't have to be solved in one step; lessening them is useful.
It'd be interesting to see the actual stats on this - what percentage of story votes are made before clicking the link, and do some outliers (spam, or sensationalist titles) get a large enough fraction of pre-read upvotes to justify taking some sort of action? I've assumed that it's low enough to not make much difference, but I could be wildly mistaken.
I believe that other people make the mistake too, and that the bias is in favor of exactly the stuff that HN &friends are trying to keep out of the top.
Otherwise, upvoting is the quick way that I mark an article with an interesting headline for reading. Most articles with a well-written headline do deserve the upvote.
Although I wish there was a way to revoke an upvote if the headline misrepresented the article... maybe I don't have enough karma to revoke an upvote?
I don't think it covers 100% of the upvotes I'm complaining about, though.
Mechanisms are worth a try. Votes from people who haven't clicked the article should be weighted differently. Also worth trying is a timer after you click the article. If the user skims the article in 20 seconds, that vote should weigh less than a vote after several minutes.
Then see if weighing votes differently increases the quality of top stories.
I like the idea of a timer, but there's no way you can set a timer that will equate well to all the links submitted.
Can you explain what you mean?
But most stories are not tweets and not short, so should take over a minute to read.
Hiding / colouring the ^ would tell the users that they shouldn't be upvoting before they read.
But as you say, there are a variety of complicated mechanisms behind-the-scenes that could simply give low weight to votes by non-readers.
You could also mess with the time-mechanics of upvotes with various properties, with the goal of just killing happenstance cascade upvoting. And this could vary with site traffic.
However, there is always a danger to adding more knobs to tweak.
Scroll to the bottom of the blog for credits.
PS I'm rubbish at CSS so the sidebar may not render correctly for you.
That "something" can be clicking through to the article, categorizing or tagging the article, or even betting or spending karma for the privilege to vote.
But site developers know that if they make the user do "something", then they will lose users. To which I ask: is it worth having a user who is going to knee-jerk vote?
I don't think so, but heck if I know anything about growing a huge site like HN.
I don't believe HN would lose users if it required you to click through before voting.
Also -- how come you can't take back an upvote?