Status

Webtools Graveyard
Graph Server
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: nthomas, Assigned: Ryosuke Niwa)

Tracking

Dependency tree / graph

Details

(Reporter)

Description

7 years ago
I like the default of setting the 0 axis to zero, since it puts a proper context on any changes. But sometimes I want to zoom in the y-axis so that I can see more detail on the changes, and hopefully identify the changeset that causes a change. Could we have either
a) a checkbox to disable the 0 minimum, rescaling to show data within min-max bounds
b) the possibility to zoom vertically as well as the existing horizontal zoom
chowse, we discussed this in person when the change was made (change was requested by rsayre). Originally I believe we set min/max bounds for y-axis to the min/max of the whole series, plus some padding. I think we decided to leave it hard-coded and revisit if/when someone complained.

Any thoughts on how we could make this configurable, or if we should support vertical zooming, or some other way to solve the problem?
There are a few ways we could support Y zooming:

* The simplest approach: have a few fixed settings for how the Y axis is fit
  to the data:

  * Don't Fit Y: The current layout. Min is always 0, max is always the max 
    value of all series, plus a 10% padding. This gives a proper sense of
    absolute values (since it is always grounded at zero), but is bad for
    series with high values but little deviation.

  * Fit Y to Data: Set min to the minimum value of all series and max to the
    max value of all series, plus 10% padding above and below. This gives a
    clearer view of trends (deviations are easier to see), but can give a 
    warped sense of absolute changes (large deviations may actually 
    correspond to small values).

  * Fit Y to Selection: Same as above, but chooses Y values based on the
    current x-axis range. When you zoom in on a timerange, the y-axis will
    zoom in as well. Has the same benefits and downsides as 'Fit Y to Data',
    but will cause additional shifts when changing the x-axis zoom.

  This will involve minimal changes to the UI (one new button) and should 
  handle the most common use cases, but will not give users fine-grained 
  control over the y-axis.


* Allow arbitrary zooming of the y-axis as well as the x-axis. This would
  involve several UI changes:

  * Separate zoom-in and zoom-out buttons for the x- and y-axis buttons. How
    zoom-in would work for the y-axis might be a bit tricky, since what y-range
    you'd want to zoom in on would depend on what range of the series you're
    currently viewing (see Fit Y to Selection).

  * Allow selecting y-ranges as well as the x-ranges using the mouse. This
    could be done with rectangular selections (which Flot supports) or by 
    adding a toggle (e.g. holding down the shift key) that alternates between
    which axis to select.  


I can update the prototype (http://is.gd/UclSZP) with examples of each. Let me know if you have any thoughts on the feasibility or usefulness of either solution.
See Also: → bug 651690
(Assignee)

Comment 3

6 years ago
I might give a shot on this bug in Q2 (Apr-Jun).
I have a WIP patch in bug 680140 that has some overlap with this bug.  It may be bitrotten now through.
Duplicate of this bug: 680140
Apparently this was fixed but not deployed:
https://github.com/mozilla/graphs/pull/6
https://github.com/mozilla/graphs/pull/7

Robert, could we get this deployed?
Assignee: nobody → rniwa
Status: NEW → ASSIGNED
Flags: needinfo?(rhelmer)
Hardware: x86 → All
(In reply to Matthew N. [:MattN] from comment #6)
> Apparently this was fixed but not deployed:
> https://github.com/mozilla/graphs/pull/6
> https://github.com/mozilla/graphs/pull/7
> 
> Robert, could we get this deployed?

It has a bug, the pre-generated graphs don't work so we are releasing off an old branch (it's on hg now also)

The larger issue is that graphs.m.o is deprecated in favor of datazilla.m.o, so I am not inclined to make any changes except for bug fixes at this point :(
Flags: needinfo?(rhelmer)
(In reply to Robert Helmer [:rhelmer] from comment #7)
> (In reply to Matthew N. [:MattN] from comment #6)
> > Apparently this was fixed but not deployed:
> > https://github.com/mozilla/graphs/pull/6
> > https://github.com/mozilla/graphs/pull/7
> > 
> > Robert, could we get this deployed?
> 
> It has a bug, the pre-generated graphs don't work so we are releasing off an
> old branch (it's on hg now also)

Do you mean the graphs on index.html?

> The larger issue is that graphs.m.o is deprecated in favor of datazilla.m.o,
> so I am not inclined to make any changes except for bug fixes at this point
> :(

I haven't heard this announced and I think it's premature given that datazilla doesn't cover use-cases that graph server does AFAIK. Some examples include finding regressions on trees which don't post to m.d.tree-management and comparing the performance of two different trees. Datazilla doesn't even work at all for the UX branch AFAICT. 

I consider it a bug that I can't get read useful data off of [1] without zooming on the y-axis :)

[1] http://graphs.mozilla.org/graph.html#tests=[[83,137,25],[83,94,25]]
(In reply to Matthew N. [:MattN] from comment #8)
> (In reply to Robert Helmer [:rhelmer] from comment #7)
> > (In reply to Matthew N. [:MattN] from comment #6)
> > > Apparently this was fixed but not deployed:
> > > https://github.com/mozilla/graphs/pull/6
> > > https://github.com/mozilla/graphs/pull/7
> > > 
> > > Robert, could we get this deployed?
> > 
> > It has a bug, the pre-generated graphs don't work so we are releasing off an
> > old branch (it's on hg now also)
> 
> Do you mean the graphs on index.html?


Yes, they are static images generated by node.js from cron (using the same code as the frontend). The list of tests hasn't been managed all that well unfortunately so I doubt it's that useful to people much anymore (I mostly worked on the frontend not the talos data collection side as much)


> > The larger issue is that graphs.m.o is deprecated in favor of datazilla.m.o,
> > so I am not inclined to make any changes except for bug fixes at this point
> > :(
> 
> I haven't heard this announced and I think it's premature given that
> datazilla doesn't cover use-cases that graph server does AFAIK. Some
> examples include finding regressions on trees which don't post to
> m.d.tree-management and comparing the performance of two different trees.
> Datazilla doesn't even work at all for the UX branch AFAICT. 


I did a blog post a while back, I don't recall if I posted to the newsgroups. It's a long-term transition, I still help out with graphserver but it's on my own time at this point.

 
> I consider it a bug that I can't get read useful data off of [1] without
> zooming on the y-axis :)
> 
> [1] http://graphs.mozilla.org/graph.html#tests=[[83,137,25],[83,94,25]]


Your patch is an interesting approach, I'll take a look.
(In reply to Robert Helmer [:rhelmer] from comment #7)
> > Robert, could we get this deployed?
> 
> It has a bug, the pre-generated graphs don't work so we are releasing off an
> old branch (it's on hg now also)

The pre-generated graphs on index.html are already broken in production, so why would this bug block us from deploying a newer version?

I'm also interested in helping with the graph server in my spare time (I've commited several changes to the back-end scripts already), but only if there's a way for improvements to get deployed.

I don't think that "wait for Datazilla" is an acceptable solution for improving this, since Datazilla has been in progress for over a year and still doesn't seem close to solving my graph server uses cases.  Would it be possible to delay the deprecation of graph server until after its replacement is available?  Otherwise we're stuck using tools that no one is allowed to improve.  :(
(In reply to Matt Brubeck (:mbrubeck) from comment #10)
> (In reply to Robert Helmer [:rhelmer] from comment #7)
> > > Robert, could we get this deployed?
> > 
> > It has a bug, the pre-generated graphs don't work so we are releasing off an
> > old branch (it's on hg now also)
> 
> The pre-generated graphs on index.html are already broken in production, so
> why would this bug block us from deploying a newer version?


This is a good point, it's only broken because the test names change and nobody has updated the JS. This changes surprisingly often! I followed up on them for a while but have been on other projects lately so only getting pulled into graphserver/talos for serious problems which doesn't happen much.

 
> I'm also interested in helping with the graph server in my spare time (I've
> commited several changes to the back-end scripts already), but only if
> there's a way for improvements to get deployed.


I can deploy things, so that's no problem. Happy to review etc. too.


> I don't think that "wait for Datazilla" is an acceptable solution for
> improving this, since Datazilla has been in progress for over a year and
> still doesn't seem close to solving my graph server uses cases.  Would it be
> possible to delay the deprecation of graph server until after its
> replacement is available?  Otherwise we're stuck using tools that no one is
> allowed to improve.  :(

graphs.m.o is not going away until datazilla is ready, I just don't have time to work on new features at the moment but happy to push it forward as long as we don't break anything :)
Are there any objections to just killing the front page, if it's not useful? It's been broken for a while after all.
(In reply to Robert Helmer [:rhelmer] from comment #12)
> Are there any objections to just killing the front page, if it's not useful?
> It's been broken for a while after all.

No objection here.  The fact that it's been broken for a long time without drawing many complaints suggests that no one depends on it.
Depends on: 898640
Since the frontpage was already "broken" I don't think we even need to do anything to it before deploying this.
The only problem I see is that 0 is not visible in the y-axis by default so graphs look very noisy until you zoom out using the overview. I looked into fixing that but the code seems overly complicated and I didn't find what was causing that.
Front page is gone, we are unblocked on this. Stage is updated (http://graphs.allizom.org) but it seems to be having DB trouble just now.

It's quite trivial to test this locally though, just opening graphs.html in a browser locally will pull the public production graphs API.

Can someone volunteer to help test this?
I have been using the repo tip locally and at graphs.MattN.ca and the only problem I noticed was in comment 14. I don't know if that needs to block this improvement. I can take another stab at fixing that on the weekend if nobody else does first.
Depends on: 900054
(In reply to Matthew N. [:MattN] from comment #16)
> I have been using the repo tip locally and at graphs.MattN.ca and the only
> problem I noticed was in comment 14. I don't know if that needs to block
> this improvement. I can take another stab at fixing that on the weekend if
> nobody else does first.

I don't think it should since this can be zoomed out in the overview if desired. Can you file a followup bug if you disagree?
Deployed in bug 900054.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 705293
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.