But people won't stop themselves. From a user's point of view: yes, you should stop yourself, but that takes effort to remember to read the article first. From pg's point of view (as this argument goes): no matter how many times you ask, people will still vote without reading the article, so if you don't want people to do so, the website needs to prevent them from doing so.
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.
The problem is that the proposed solution is more of a mild nuisance than a solid block. If spambots or the human equivilant want to upvote worthless links, it's trivial to hit the link first. The same minor workaround would be required of legitimate users that, as you mention, may have seen the article elsewhere and already read it. And it might make impulsive people more likely to read the article before voting, but again nothing is guaranteed (and is that really a serious problem anyway?)
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.
>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.
Good point. I was stuck imagining a clumsy "You must read the article before voting" page rather than pg's silent vote dropping trick. The former would hurt the perceived simplicity of the site, while the current uses of the latter work well enough that I usually forget it's even there.
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.
You can protect against SQL injection, but you can't make anyone read the article. The best you could do is make them click the link first.
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.)
Ideally, you'd want the users to read and understand the article, if understandable. However, as this is difficult to implement, opening the page is a the minimum you'd have to do to understand it. If users voting on articles without reading them is a problem, requiring users to at least click on the article would lessen the problem.
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.
I use voting as a way to mark a story to be read later, so I'm guilty of upvoting before reading. I don't think there should be a mechanism to require a click-through, but I think a way to save a story to a "to be read" later queue would be nice.
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 started upvoting to book mark things as well when I discovered the "Saved Stories" section of my profile. Instapaper is a better solution to this though--http://www.instapaper.com/
What would be more useful IMHO would be a way to flag spam on the New page without needing to hit the 'discuss' link first. Most spam is glaringly obvious, but discuss-flag-back/close is a 3 step operation. I don't think this will be a problem for actual content except for the occasional big news events where everyone races to post 20 links to the same story.
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.
That's an excellent suggestion with different implications than mine.
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.
Sometimes tweets show up as top stories on HN. A tweet takes a few seconds to read and vote on. So the timer idea would not allow tweet stories to get to the top unless the timer knew the story was a tweet.
But most stories are not tweets and not short, so should take over a minute to read.
I've banged my head against this User Generated Content ranking problem several times, and I keep getting back to there being some kind of trade: the user does something, then the site allows them to vote.
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.
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.