Closed
Bug 641413
Opened 13 years ago
Closed 11 years ago
Option to zoom on y-axis
Categories
(Webtools Graveyard :: Graph Server, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: nthomas, Assigned: rniwa)
References
Details
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
Comment 1•13 years ago
|
||
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?
Comment 2•13 years ago
|
||
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.
Assignee | ||
Comment 3•12 years ago
|
||
I might give a shot on this bug in Q2 (Apr-Jun).
Comment 4•12 years ago
|
||
I have a WIP patch in bug 680140 that has some overlap with this bug. It may be bitrotten now through.
Comment 6•11 years ago
|
||
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
Comment 7•11 years ago
|
||
(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)
Comment 8•11 years ago
|
||
(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]]
Comment 9•11 years ago
|
||
(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.
Comment 10•11 years ago
|
||
(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. :(
Comment 11•11 years ago
|
||
(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 :)
Comment 12•11 years ago
|
||
Are there any objections to just killing the front page, if it's not useful? It's been broken for a while after all.
Comment 13•11 years ago
|
||
(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.
Comment 14•11 years ago
|
||
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.
Comment 15•11 years ago
|
||
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?
Comment 16•11 years ago
|
||
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.
Comment 17•11 years ago
|
||
(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?
Comment 18•11 years ago
|
||
Deployed in bug 900054.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•