386672 - Navigation Improvements to new graph server

Status: RESOLVED INVALID

(Webtools Graveyard :: Graph Server, defect, P3)

Description

[Mike Schroepfer]

There are a couple of critical improvements needed to navigation on the new graph server:

1) The two main pages are not connected (e.g. no links from one to another): 

graphs.mozilla.org/graph.html
graphs.mozilla.org/dgraph.html

2) graphs.mozilla.org/dgraph.html makes it very hard to compare results across branches/machines.  It seems like the two most common use cases for this page are to compare:
  a) Two runs of the same test on the same branch and machine.  This one is fairly easy - but the final test selection box should (imho) sort with latest test results to the top
  b) Two runs of the same test across machines or across branches.  This is very difficult to do - seems like we need a second set of selectors (or a notion of a "chosen graph like the other graph server. here.

3) graphs.mozilla.org/graph.html

Would be nice to be able to selectors similar to graphs.mozilla.org/dgraph.html where you can easily choose a branch, test, machine, test instance (in that order of selection and importance)

It seems like the main navigation selectors for 2/3 can likely be shared..

Comment 1

[Mike Schroepfer]

Beltzner I was told you had some suggested wireframes for nav improvements for the graph server.  Can you attach?

Comment 2

[chizu]

Beltzner, do you have those wireframes? I've been working on part 2.b mostly, but a second set of selectors doesn't seem to be much of an improvement over just one.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: wireframe for graph-o-matic 2.0 (trends view)

Notes:

 - adding a graph should invoke a re-layout of the graph content
 - the date-range options should be "instant-apply" on change
 - "Get TinyURL" should generate the URL and open a DHTML popup with the resulting TinyURL
 - clicking on an [x] should remove the graph from the view
 - "Show trend lines" replaces "average", and should apply to all data sets when checked
 - the names of the tests, branches and machines should be simplified to the minimum required information - I'll post more thoughts on that in a bit

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: wireframe for graph-o-matic 2.0 (specific view)

Notes:

 - like the trends view, changes and graph additions are instant-apply
 - graphs should be grouped by date within their type (branch/machine-platform/test), and an [x] on the group header removes the entire subgroup

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

"Graph-o-matic v2.0" represents a first step in the changes I think we need to make. In addition to what's shown in the mockups and outlined in the notes in comment #3 and comment #4 ..:

- need a better name for "trends" and "specific" tabs; these map to the functionality currently provided by graph.html and dgraph.html. Perhaps "Overview" and "Drill-down" or "Averages" and "Individual Tests"?

- both axes should be labelled with the appropriate units

- branches should be listed in descending order

- machine/platform should be broken out by platform (win, mac, linux) and then within those sections, machine names (just the bits after the dash, though)

- dates should be listed in newest-oldest order

- need to come up with a sensical set of names and order for tests (who's good to work this out with me?)

- when a user switches from trends to specific and vice versa, we should try to match the data-selection drop-down fields as best we can to make it easier to drill down and elevate up (see "v3.0 thoughs, below)

Thoughts towards Graph-o-matic v3.0
---------------------------------
I'd really like to get to a design where as a user traces along a graph line in the trends view, they can isolate a point, double click, and have the specific test added to a bucket somewhere on the page. When they're done accumulating tests, they would then click on a button to drill down into a graph of those individual test runs.

Other features I'd like to enable in the future:

 - illustrating performance for a test site over time
 - setting a value range and finding tests that meet the criteria, then displaying them
 - adding baseline values in once we have them again
 - 

Comment 6

[Mike Schroepfer]

Great stuff beltzner!  Some thoughts:

1) Renaming the tests isn't really important.  The audience that uses this understands them.

2) For Specific View it would be great to have a date limiter so that "date" popup doesn't become huge (could be > 500 entries otherwise).  

3) Another huge win would be to snap the cursor to real Y/X values e.g. google finance:
  http://finance.google.com/finance?q=GOOG

So as you move the cursor over the graph it should the Y/X value actually on the graph closest to the cursor.  

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

1) I was thinking more for spacing issues, since right now the names are unneccessarily long and tend to make the UI selection elements larger than they have to be, but sure.

2) Agreed; you know, just repeating the same date range UI from "trends" would work well, I think.

3) Yes, that would be great.

Comment 8

[Mike Schroepfer]

http://simile.mit.edu/timeplot/

Has some sweet canvas code as it is helpful...

Comment 9

[Mike Schroepfer]

Trevor do you have what you need here?

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: wireframe for graph-o-matic 2.0 (trends view, rev2)

Updated mockup to reflect comments about snap-to, just for fun

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: wireframe for graph-o-matic 2.0 (specific view, rev 2)

Updated to include UI for restricting date range

Comment 12

[Justin Fitzhugh]

In the beginning of this bug, there were 3 minor to somewhat-minor fixes, but seems this has morphed into a total UI rewrite, something beyond what we originally expected, and not sure we are the right ones to do it (we may be, just different than originally).  In the short term, do you still want the original three things fixed, or should we just focus on finding the right person for the UI rewrite.  Unclear as to how major the current deficiencies are.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I have a branch that I started a while back that rips out all the YUI/mochikit/etc. cruft and replaces it with a much simpler HTML layout and uses jquery; it keeps the current UI, but that would be the first step in any UI morph.  After that point it should be simpler for someone else to take over the full UI rewrite, but I don't think this is a very high priority right now.

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Taking

Comment 15

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Found in triage - any update?

Comment 16

[alice nodelman [:alice] [:anode]]

This is a bug that has become invalid due to the new graph server front end.  See it in action here:

http://graphs-stage.mozilla.org/g2/
http://graphs.mozilla.org/g2/

And for those interested in the code:
http://hg.mozilla.org/index.cgi/graphs/

We are actively working to make this the only front end and deprecate the old.  See bug 429226.

If the problem persists or this bug is still active please re-open or re-file.

Comment 17

[Dave Miller [:justdave]]

um, this bug was about the new graphs server.  Shouldn't it be fixed instead of invalid?