So knowing vote difference (= score) and vote ratio (= percent positive) is the same thing as knowing #up and #down—except in the special case where the vote difference is 0, in which case you’re always exactly 50% positive and you can’t tell the total number.
It seems to me that making the hover-text say something like “+5 −3” would be strictly more informative, and at least as user-friendly, as having it say “63% positive” or whatever it says right now.
Of course there are any number of other changes it might be good to make to the code, and approximately zero effort available for code changes. But this one’s a one-liner. (Actually, I think it’s a two-liner; there are two things in strings.py that look like they’d want the same modification.)
Thanks for making it way clearer than I did. And yes, I forgot the 1:1 edge case.
As for modifying, a minor edit or bug similar to this is always 60% formulation and specification, 10% code modification, and 30% testing and making sure you’re not breaking half the project. It sounds like you’ve already done around 75% of the work.
(deployment not included in above pseudo-figures, since the proportional deployment hurdles varies enormously by setup, environment, etc.)
If you have up-down=d and up/(up+down)=p—these are the two pieces of information you get—then:
(up+down)/up = 1/p
(up-down)/up = (2*up-(up+down))/up = 2-1/p
up = (up-down) / [(up-down)/up] = d / (2-1/p) = dp / (2p-1)
and then down = up-d = d(1-p) / (2p-1).
So knowing vote difference (= score) and vote ratio (= percent positive) is the same thing as knowing #up and #down—except in the special case where the vote difference is 0, in which case you’re always exactly 50% positive and you can’t tell the total number.
It seems to me that making the hover-text say something like “+5 −3” would be strictly more informative, and at least as user-friendly, as having it say “63% positive” or whatever it says right now.
Of course there are any number of other changes it might be good to make to the code, and approximately zero effort available for code changes. But this one’s a one-liner. (Actually, I think it’s a two-liner; there are two things in strings.py that look like they’d want the same modification.)
Thanks for making it way clearer than I did. And yes, I forgot the 1:1 edge case.
As for modifying, a minor edit or bug similar to this is always 60% formulation and specification, 10% code modification, and 30% testing and making sure you’re not breaking half the project. It sounds like you’ve already done around 75% of the work.
(deployment not included in above pseudo-figures, since the proportional deployment hurdles varies enormously by setup, environment, etc.)