13

On Stack Overflow (and related sites) you have:
8 kviews http://img138.imageshack.us/img138/1802/38582706.png
Meanwhile on Stack Exchange sites you have:
1k views http://img215.imageshack.us/img215/1102/75469353.png

(Minus the hastily drawn arrows in MS-Paint, of course.)

Personally I think the latter looks better, which is why I bring this up.

So, in the same vein as these two questions, and now that it's already been implemented on SE, will this change ever make its way here? Thank you.

EDIT:
I see the precision argument. Though I'd argue that at a quick glance while scanning a list of questions precision is less important than more easily comparing adjacent questions. And that the k next to the number makes it clearer that that question has had more views. But that's just me.

I created a Greasemonkey script to force the k where I like it, and I guess one thing to look at is that Stack Exchange sites haven't had to deal with questions with nearly this many views yet:

226k views http://img215.imageshack.us/img215/7830/sok.png

Which personally I'd call an edge condition, and still prefer the k next to the number. But I understand others seeing it differently, and I think Pollyanna, and in related previous questions, Jeff, made a good point about maintaining precision.

EDIT:
Well, here's a script for the rest of us: install view source

Improve this question
3
  • This change was done after the port to SE. Details here: meta.stackexchange.com/questions/14581/…
    – BinaryMisfit
    Mar 23, 2010 at 11:27
  • 1
    I know. Which is why I'm asking now if the change can be back-ported.
    – Matt Blaine
    Mar 23, 2010 at 11:49
  • Could be marked as a dupe of 14581, but I suppose it's a new request that may merit its own question.
    – Pollyanna
    Mar 23, 2010 at 13:21

1 Answer 1

Reset to default
2

We had quite an extensive discussion on this originally:

100 thousand views or more: "thousand" comes below "views"

Jeff was of the opinion that by adding the k in the number, you would lose precision, or had to make the font smaller, or make the field wider, and the page layout was already set.

So on SO you can have 10.1 kview but on SE you can only have 10k view.

If you want to have this change made, you'll be swimming upstream against the idea of more information vs less information, as I understand it.

Further, numbers like 949m would be too long, so there's a whole group of numbers that cannot be displayed with m as the postfix without making the font smaller, enlarging the box, or doing horrible things like 0.9m

I'm curious to know how stackexchange has or will resolve this last issue.

Improve this answer
10
  • 1
    Or you can simply have it display "kview" only if there are > 10k, and display the k in the number in all other cases, but that would make too much sense
    – Andreas Bonini
    Mar 23, 2010 at 13:25
  • 2
    @Kop - it still loses precision. 9.98 kview is more precision than 9.9k, but "m" is even wider, so it needs to be 9m which would lead to a significant loss of precision, compared to 9.98 mviews. Further it would be terribly inconsistent, and lead to confusion. If people see 1k-9k views most of the time, then when 10 kviews comes along they won't even notice the small print views has changed to kviews. If they always have to look at the small print to determine the magnitude (ie, consistent user interface) then there will be no confusion.
    – Pollyanna
    Mar 23, 2010 at 13:32
  • 4
    Does the difference between 10.1k and 10k really matter? Seems clarity and usability concerns should dominate rationale for this part of the UI. (And it's a coin flip for me, they both seem about the same. But for non-technical people, "10k views" is probably better than "10.1 kviews".)
    – Gnome
    Mar 23, 2010 at 13:32
  • @Pollyanna I had looked at the previous threads, but I guess not close enough. Hadn't though about the precision issue. Hmmm...
    – Matt Blaine
    Mar 23, 2010 at 13:33
  • @Gnome - Jeff was pretty set against losing any precision. Beyond that, though, the code to make sure that it'll all fit (including the wider m) isn't trivial. It's not terribly difficult, either, but it's more effort to get it to fit consistently.
    – Pollyanna
    Mar 23, 2010 at 13:39
  • @Pollyanna, if one of the questions on my SE site starts wrapping because it got 949m views, trust me I won't be complaining
    – Rich Seller
    Mar 23, 2010 at 14:31
  • So far, the most-viewed question on SO has 400k views. Four other questions are over 100k. Four of those five questions have since been locked; the other is the question that sparked bobince's epic regex answer. And now I can't remember why I brought this up. Maybe I was pointing out how rare an edge case this is.
    – mmyers
    Mar 23, 2010 at 15:00
  • 1
    @Polly: Jeff's opinion carries more weight than mine, obviously, but I can still call it wrong. :) news.cnet.com/google-designer-leaves-blaming-data-centrism
    – Gnome
    Mar 23, 2010 at 15:22
  • @Gnome - Sure, and I'm not necessarily defending his position, just explaining it here so others can understand why the status quo is the status quo. I think that since the information can be found elsewhere in the perfect level of detail, then the number can be 2 or even 1 significant digit, and those curious can follow up for a more precise number. Thanks for the link to the article - it's always fascinating when the subjective clashes with the objective. I love to compare Apple and Google in these terms...
    – Pollyanna
    Mar 23, 2010 at 15:40
  • @Pollyanna @Rich Seller - I acccidentally posted a duplicate question to this on the main StackOverflow, and appreciate the deeper background into this. I just wonder that the difference in size between a k and m could be easily handled by bringing the font-size down a half point. No one would really notice that detail, and users can still hover over a number if they are curious about the precision.
    – Michael
    Feb 4, 2011 at 13:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .