3by9

Social Voting Interaction Design

I had a completely different entry ready to rock today but decided to scrap it and get more technical about something I’m currently working on.

Without divulging too many details, we’re currently doing some things with 9rules that no one is expecting. One of those things involves the opportunity to rethink the entire process of how people interact with Clips — viewing them, posting them, and voting on them. The most interesting aspect of it for me is that the act of voting is a full user experience play: you’re acting on something that will be updating to indicate the consequence of your action. Within that interaction scenario many things happen including talking with the server to store and act on your action, which by itself also involves a lot of error checking and error prevention. There’s no “right” way to do the process of voting on an article, and nearly every social voting site out there has their own way that’s been devised and hand-coded by their own engineering team. There’s no prototype function for voteOnThisArticle() that drops all the functionality into your lap, so you’re on your own.

Here are a list of things involved with social voting interaction design:

• Initial display of the voting widget.
• Voting area hover states.
• Displaying the updated tally.
• Protecting against exploits.
• Relaying the vote to the server… when should this occur?
• The “2nd click” scenario… when a user votes and then clicks to vote again, what happens?

All of these things occur in a specific sequence, and this sequence is different across all social voting sites. At Digg you vote and then the page awaits an Ajax response back from the server before fading out the current tally and fading in the new tally. After you click the “digg it” button, the code removes that link from the page and replaces it with text, so you’re not allowed to vote twice. The UI’s updating is driven from the server’s response so a time indicator is needed to show you that the process is working (fade out of tally, fade in of tally).

At Reddit they do things differently. You can vote up or down on an article, and on top of this, Reddit allows you to change your vote at any time which is the opposite of Digg. You can’t UnDigg an article. Reddit’s interaction process is much different as it doesn’t rely on a server response before updating the UI, making it feel a lot snappier. The point count for a given article is modified up or down via Javascript DOM manipulation (or innerHTML) as soon as you vote, so the visual feedback is instantaneous. The UI is updated instantly, and then behind the scenes they send Ajax requests out to the server to actually record your vote. Once the server response comes back nothing needs to be changed because client side code has already updated the UI accordingly, so there’s no sluggishness. This gives the site a quicker feel, but it also leaves the user feeling less satisfied about the voting process as it’s so instant it may leave some people thinking that it didn’t register. At Digg, there are various animated steps showing you that your vote counted so it feels more permanent. Reddit updates so quickly that it doesn’t feel permanent, which works to the site’s advantage because it reinforces the fact that you can change your vote at any time, just as easily as you made your first vote.

I think Reddit has the right idea and it’d be interesting to see what people would think if Digg changed how they handle social voting UI updates. If the design instantly changed to indicate a Digg, and you could click again to UnDigg just as fast, perhaps it’d bring more people to actually vote on articles.