Suppose a new popular question comes in and has 20 views on it before the first answer is submitted. The first answer is pretty good, so when the question hits 120 views it has 20 votes: 1 vote for every 5 views...not bad! Also, several other answers have been submitted, but the other answers don't really add much and are thus all sitting at 1 or 2 votes, so sorting by votes works wonderfully at this point and brings the best answer to the top.
However, at the time of the 119th view, Jon Skeet was eating his last bite of lunch with Bill Gates (who unfortunately does not allow Jon to log into SE when they are eating out together because it intimidates him). Thus, Jon sees the question while he's washing his hands and types out and submits his answer while he's drying them with a paper towel. At this point, the question has 120 views (Jon was the 120th viewer).
As always, Jon's answer is stupendous, and so his answer has 10 votes by the time the question has 150 views*, while the first answer now has 26 votes. Thus, the first answer is still sitting at 1 vote for every 5 views, whereas Jon's answer is sitting at 1 vote for every 3 views, meaning a greater percentage of people like Jon's answer over the first answer. Herein lies our problem that sorting by votes will not always put the best answer at the top of our list.
*You may be asking yourself, "Why doesn't Jon's answer have 30 votes at 150 views?". The answer to this excellent question is that 20 of the 30 viewers were lazy and didn't read past the top-sorted answer.
Add "Weighted Votes" as an additional (default?) sorting option. This would essentially allow users to sort on the percentage of people who thought the answer deserved an up-vote.
numberOfVotes / answerViews //If answerViews > 0 0 //If answerViews == 0
numberOfVotes = The number of votes on the question
answerViews = The number of views after the answer was submitted. This value of this could range from the question's current view count minus the view count when the answer was submitted (which would miss returning users) to a count of the distinct users who viewed each question (for a completely accurate view count).
At 150 views from our use case, the first answer's sort would be .2 and Jon's answer's sort would be .333, so Jon's would be sorted to the top.
Now, the real question is how quick would Jon's answer float to the top? Let's say that viewers 121-129 don't read the zero-voted answers, so they don't see Jon's answer. However, viewer #130 reads all the answers, and thus gives Jon the first up-vote. At this point, Jon's answer will have a weighted vote score of .1, and will thus still appear below the first answer. Similarly, viewers 131-134 don't read answers with fewer than 2 votes, but the 135th viewer reads Jon's answer and gives it another up-vote, leaving it still below the first answer at .1333. In viewers 136-140, his answer gets 2 more votes to put it at 4 total votes, which puts the weighted votes count at .2, which is when his answer would overtakes the first answer. Thus, in this case it would take 20 viewers before Jon's answer would get sorted to the top spot using this method.
Option 2 (More Involved):
numberOfVotes / answerReads //If answerReads > 0 0 //If answerReads == 0
numberOfVotes = The number of votes on the question
answerReads = Come up with a mechanism to determine when an answer is actually "read". This would be similar to Google Reader, where when a user hovers their mouse over an answer or scrolls past it, the answer is marked read for that user.
At 150 views from our use case, the first answer's sort would be .2 and Jon's answer's sort would be 1, so Jon's would be sorted to the top.
How long would it take Jon's answer to get to the top spot? His answer would be at the top after the first reader up-votes his answer, which would be the 130th viewer. Thus, it would take 10 viewers for his answer to get on top instead of 20.
Note: I also considered sorting unread/unviewed answers to the top, which would mean that 121st viewer would see Jon's answer and vote it up, and so his answer would immediately take the first position. However, if that were done the worst answer could be at the top for one unlucky viewer, so I don't think this would be a good decision. Instead, I think it better that the truly interested "130th" viewer get the first vote on it.
To see this in action, here is a sample query using option 1 to sort questions with over 50,000 views by popularity.
Points to consider:
- "Be careful with what 'views' means": For option 1, view counts on answers would have to be tallied similar to how view counts on questions are tallied.
- "Massively overwrought system": Up to you.
- "Involves a huge change to how the data is stored": This is an incorrect assumption, as answers are stored in
postswhich already have a
viewCountcolumn. This column is currently unused and would need to be populated for answers, but no data change is needed.
- "huge change to how the UI works...": The only change would be to add a "popularity" tab next to "active", "oldest", and "votes".
- "Debatable gain": Up to you, but I definitely see the merits of this.
- "A vote is a vote": Yes, and sorting by total votes would not be removed. This would just be an additional sort.
- "The smaller population won't always represent the larger population" & "What if the first viewer of a new answer upvotes it? Does that make a 1 vote answer shoot up to the top over a 50 vote answer?": This could be solved by modifying the query so that answers with less history will stay at the bottom longer (thanks blahdiblah for the link).
- "Drastically skewed when...thousands of external visitors...do not have voting accounts": To avoid this, the "view" count for the answer sort should only count viewers able to vote.