Page MenuHomePhabricator

Beta: Y-axis units and rounding issues
Closed, ResolvedPublic5 Estimated Story Points


I've noticed some issues with the Y-axis units in the total page views graphs, but might be present in other graphs too. See both the attached screenshot and

  1. [ALREADY SOLVED BY ANOTHER TASK] The unit prefixes doesn't seem right to me. If using m for million, than I would expect b or bn for billions (although there is some ambiguity in the value of a billion). If instead the SI prefixes are used, I would expect M for mega and G for giga. An alternative approach could be to just use one unit per graph, write it without abbreviations at the top of the Y-axis and just use plain numbers in the labels, but might not work well if some graphs have very large range of values.
  2. When passing to the next scale at least one decimal is needed to provide to avoid to have two labels in the Y-axis with the same value of 1g, at least in this case.
  3. [ALREADY SOLVED BY ANOTHER TASK] [mostly style / usability] I'm not sure that having all the graphs starting from zero helps the readability of them. In particular when the line goes behind the legend with the date and the value of the point when mouse hovering. Not only the line is partially shadowed by the label box, but is also harder to do "mouse hover" on the points behind the label box, as the hover needs to be done outside of the box, at the same X of the point I want to hover. Is also a bit confusing, as hovering from left to right I might not notice that the hovering is "stuck" at the previous value and read the wrong value.

Event Timeline

Thanks for the report! I agree with your proposals, was saying something similar yesterday. We're trying to internationalize our number formatting so we're going back and forth a bit on it.

elukey triaged this task as Medium priority.Feb 15 2018, 10:58 AM
elukey added a subscriber: fdans.

Agreed with 1 and 2 but not so much with 3.

Regarding 1:
Localization issues as hard, the "bn" sufix might make sense to americans but not to anyone else reading this site in english.
Thus effort of using SI prefixes before localization is available. We might be fixing some of these issues in this ticket (not all):

Also, thanks for reporting.

fdans renamed this task from Wikistats Bug: Y-axis units and rounding issues to Beta: Y-axis units and rounding issues.Feb 22 2018, 5:43 PM
fdans moved this task from Incoming to Dashiki on the Analytics board.

Regarding nr. 3

I totally agree with @Volans that the popup box is unnecessarily colliding with the line and makes it unconfortable to read its values.
However, I am strongly in favor of making the base of the graphs at Y=0, and think we should move the box instead.

Regarding 1:
Localization for y-axis values (for locales supported by numeral.js is done now)

+1 to graphs starting at zero

mforns raised the priority of this task from Medium to Needs Triage.Mar 8 2018, 6:17 PM

Hey, we know now that we can't place the legend (with the date and the values of the point) anywhere over the line graph as it hinders with the hovering and also makes the line color lighter than usual which might be confusing to the user. At the moment I see one possible solution which is to move the label/valuePopup div to a new position maybe where it does not intersect with the line graph but still remain noticeable to the user. Any suggestions?

@sahil505 Yes, I agree this is an option.
The majority of single-line charts have their line travel through the top section of the canvas.
We could move the popup-legend down and this would help.

However, when activating a breakdown on the left, there is a greater change that one or more lines are still obfuscated by the popup-legend.
I'd suggest maybe to try and make the position of the popup-legend dynamic, depending on the cursor position. Some options:

  1. The popup-legend stays on the top-right (current position), unless the cursor hovers over it. If so, the popup-legend moves to the left.
  2. The popup-legend follows the cursor wherever it goes. Always aligned to the top of the chart, but laterally adjacent to the hovered position.
  3. Another option or combination of them?

If the dynamic placement turns out to be too complicated, we could just move move the popup-legend to another static position that is more convenient.
That would be fine, too.

@mforns This is interesting. Will try my best. Whatever option we go with it should be more convenient to the user to relate to. Maybe want to keep this for the GSoC coding period but lets see if I can get it done before.

Sure @sahil505, please do take your time!
None of those tasks was intended to be done before the coding period!
It's great you're working on them, but please don't feel any pressure now. :]

@mforns @Nuria - I feel like parts of this task are repeated in various other tasks. Please see T184011 & T188277. Thanks.

Seems like only last point needs addressing and that is a duplicate of other tickets so this task can probably be closed as a duplicate.

I think #2 is still an untackled issue:

I will adapt title and description of this task, and keep it open for GSoC.

mforns updated the task description. (Show Details)
mforns triaged this task as High priority.
mforns set the point value for this task to 5.

Just to put it up, the #2 issue is not specific to just line charts but it is also observed in bar charts. Here is an image:

Change 434326 had a related patch set uploaded (by Sahil505; owner: Sahil505):
[analytics/wikistats2@master] Corrected y-axis labels to one decimal place to avoid similar labels

Change 434326 merged by Mforns:
[analytics/wikistats2@master] Corrected y-axis labels to one decimal place to avoid similar labels