Dev here. Our team has grown to love the GitHub pull request workflow. We built Prune to solve one issue we consistently run into: how to QA on the various branches before merging. Happy to answer questions and thanks for any feedback!
We haven't considered making it non-linear. It's an interesting suggestion, though I'd hesitate to go that way only because the user then lacks a clear 1:1 model of how the slider directly affects their rating (without explanation). We haven't received enough ratings yet to prove your assumption. When we do and if it does hold true, our assumption now is that we have _enough_ of a scale to expose meaningful differences.
You've given us good food for thought, thanks. My general feeling now is that I think it's important to leave the negative portion of the slider intact (however less it's used) to maintain a solid mental model. Might be something to test down the road though.
It will be interesting. It's important to note the nature of our community and whom we expect to contribute. Generally, we're geared toward a more passionate user who we find to be more than willing to contribute at this level of granularity. So we've made the choice to cater toward their needs while still trying to remain accessible.
But, this is a good point, and I think an important one to consider when evaluating the mechanic that works best for your community/site.
Yeah, sorting is an issue we're still looking at (and is still very much in transition considering the new rating system). Appreciate the suggestion! We'll add it to our list of potential solutions.
2. It is too early to tell, but we're definitely planning to share a follow up. As mentioned in the post, we had a simple thumbs up/down for ratings and were seeing a greater than 90% positive average, so we were definitely experiencing that bias. Just today, albeit with a much too small sample size, we're starting to see a more diverse mix of averages. We still expect to have that positive skew but because we're now operating with a 100 point scale in the UI, we hope the granularity will help users distinguish subtler differences in rating.
Hi, I'm Mike from Steepster. We thought we'd share our new ratings system we just deployed with HN as we think it's relevant for products with customer reviews, ratings, etc. It's our attempt to combat the 4.3 dilemma (discussed here recently: http://news.ycombinator.com/item?id=883890).
Background: Steepster is a community site for tea drinkers to share their tasting notes, get recommendations, and discover new teas.
Great mix of more general advice (like the previous set of bullet points), combined with specific context around your experience. It's a nice change of pace from the "your startup has to do this" blend of articles because it acknowledges your biases with the appropriate context.
In retrospect, I feel bad submitting this. It was my first submission in the two years or so I've been here (~1 with an account), which makes it worse.
In my defense, I had no idea it would be upvoted so highly.
Yeah, and I think it's a shame because, while getdropbox.com works great as a marketing site, getdropbox.com/home doesn't feel right for their Web interface.
Only redesign when you have a measurable goal or set of goals in mind. It helps if they're quantifiable, but they don't necessarily have to be.
There are many dangers in redesigning prior to establishing a goal (particularly with commercial sites) -- principal of which is never knowing when and if you've succeeded.