703005 - exponential scaling in histograms is not useful

Status: RESOLVED FIXED

(Mozilla Metrics :: Frontend Reports, defect)

Description

[(dormant account)]

I can't see the small bars whenever there is a single bar that dwarfs everything else, eg MOZ_STORAGE_ASYNC_REQUESTS

Also x-axis is unreadable in CYCLE_COLLECTOR probe

Comment 1

[Pedro Alves]

Maria is much more familiar with this, if it's a frontend issue is in UDJC

Comment 2

[Lawrence Mandel [:lmandel] (use needinfo)]

Maria - Any thoughts?

Comment 3

[Pedro Alves]

> Also x-axis is unreadable in CYCLE_COLLECTOR probe

This should be fixed. There's some invalid submissions in fx7 / fx8, but that should be done


As for the others, I'm not sure how often it happen. If it's something that only happens for some of the histograms, can we use the new export feature?

Comment 4

[Justin Lebar (not reading bugmail)]

> If it's something that only happens for some of the histograms, can we use the new export feature?

If raw JSON is more readable than the telemetry front-end, for any histogram, I think that's a bug.  Do you disagree?

Comment 6

[Paulo Pires]

It's still a WIP, but now: 
- if you click on a bar of the histogram the yAxis resize to the value of that bar
- click on another bar and it resizes to the value of the new bar
- click on the same bar and the yAxis returns to the default size.

Comment 7

[Pedro Alves]

And just for the record, I 100% Agree with justin, it's definetly a bug

Comment 8

[Justin Lebar (not reading bugmail)]

(In reply to Paulo Pires from comment #6)
> It's still a WIP, but now: 
> - if you click on a bar of the histogram the yAxis resize to the value of
> that bar
> - click on another bar and it resizes to the value of the new bar
> - click on the same bar and the yAxis returns to the default size.

This works really well for me!  It would be nice if there were some indicator of which bar I needed to click on to restore the display, or if there were some other way to restore the display without finding the right bar.

Comment 9

[Pedro Alves]

That's the WIP part ;)

Comment 10

[(dormant account)]

Still not good enough.
MOZ_STORARY_ASYNC_REQUESTS_MS  has data i can't mouse over(bars too small)
cycle_collector_need_gc doesn't even show the second bar.

I think we should be able to set minimum height for datapoints. We should also be able to detect when large bars are dominating and ensure that tall bars are never >50% higher than every other bar.

Comment 11

[Justin Lebar (not reading bugmail)]

Bug 711984 is on file for making the hover targets larger.

Comment 12

[(dormant account)]

(In reply to Taras Glek (:taras) from comment #10)

> I think we should be able to set minimum height for datapoints. We should
> also be able to detect when large bars are dominating and ensure that tall
> bars are never >50% higher than every other bar.

obvious way to do this is to change the Y-axis scale

Comment 13

[Paulo Pires]

When the histogram is rendered it checks for the value of the second biggest bar, if that value is inferior to 2% it resizes the yAxis to the value of the second biggest bar.

The toggle when clicking on the bars is maintained, but the default yAxis now corresponds to the value of the second biggest bar if is inferior to 2% (no point on showing a big 100% bar and the other too small).

Also the bar clicked has now a red border to highlight it from the others.

Comment 14

[Paulo Pires]

Just a few notes:

- when the yAxis is resized, the bars that are greater than the new yAxis max have a red triangle that indicates that the bar is bigger, we will change this aspect.

- the tooltip of the bar is attached to the top of the bar, so when the bars are bigger than the top yAxis value the tooltips appear outside the histogram, we will change this also.

Comment 15

[(dormant account)]

This broke A11Y_INSTANTIATED

Comment 16

[Paulo Pires]

This was breaking because on A11Y_INSTANTIATED we have a 100% bar for 1 and two null bars for 0 and 2, so the yAxis size was changing to 0.
It's fixed now, showing a 100% yAxis size.

Comment 17

[Justin Lebar (not reading bugmail)]

The way this works atm, when we detect an outlier bar and re-scale to the next-highest bar, that bar is not highlighted.  So there's no apparent way to undo the auto-rescale.

We should treat auto-rescale exactly the same as if the user had clicked on the bar we're re-scaling to.

Comment 18

[Paulo Pires]

For example, watching ZIPARCHIVE_CRC we have a big bar on 1 and two small bars on 0 and 2, so the y-axis is resized to the second largest bar, which is 0, but you can still click on the 2 bar (or others, if that's the case) that it will resize to the clicked bar, but not to 100%.

The histogram won't resize to 100% because if it did, the second largest bar (and smaller ones) would get too small to click, and you would only see a big 100% with one or more too small non clickable bars.

Comment 19

[Justin Lebar (not reading bugmail)]

> and you would only see a big 100% with one or more too small non clickable bars.

We have a bug on increasing the clickable area for bars.  That would fix this issue, right?

Comment 20

[Paulo Pires]

Yes, but for now I think it's best this way or you'll get a non clickable histogram

Comment 21

[Justin Lebar (not reading bugmail)]

Agreed.  We can revisit this in a separate bug once we increase the clickable area.

Comment 22

[Paulo Pires]

With the normalization fixed there isn't always a 100% bar so I removed the condition that didn't let to resize the yAxis when clicking on a 100% bar.

In some cases there is a greater than 90% bar and all the others are small, so the yAxis size is set to the second biggest bar like before, but now you can click on the greather than 90% bar to resize the yAxis to it.

In all other cases the yAxis is set to the biggest bar.

Comment 23

[Annie Elliott]

updating whiteboard

Comment 24

[Annie Elliott]

updating status and assignee

Comment 25

[Annie Elliott]

New JIRA migration identifier - 55 BZ issues being considered in current planning for Q3

Comment 26

[Annie Elliott]

reopened by accident

Paulo Pires made changes - 2012-01-20 09:50 AM
Time Spent 	2 days, 2 hours [ 64800 ] 	2 days, 4 hours [ 72000 ]
Worklog Id 	10408 [ 10408 ]