Navigation Improvements to new graph server

RESOLVED INVALID

Status

Webtools Graveyard
Graph Server
P3
normal
RESOLVED INVALID
11 years ago
2 years ago

People

(Reporter: Mike Schroepfer, Assigned: vlad)

Tracking

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

11 years ago
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..
(Reporter)

Updated

11 years ago
Blocks: 386669
(Reporter)

Comment 1

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

Component: Testing → Graph Server
Product: Core → Webtools
QA Contact: testing → graph.server
Version: unspecified → Trunk

Updated

11 years ago
Assignee: nobody → thardcastle

Comment 2

11 years ago
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.
Created attachment 273682 [details]
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
Created attachment 273683 [details]
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
"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
 - 
(Reporter)

Comment 6

11 years ago
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.  

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.
(Reporter)

Comment 8

11 years ago
http://simile.mit.edu/timeplot/

Has some sweet canvas code as it is helpful...
(Reporter)

Comment 9

11 years ago
Trevor do you have what you need here?
Created attachment 275987 [details]
wireframe for graph-o-matic 2.0 (trends view, rev2)

Updated mockup to reflect comments about snap-to, just for fun
Attachment #273682 - Attachment is obsolete: true
Created attachment 275988 [details]
wireframe for graph-o-matic 2.0 (specific view, rev 2)

Updated to include UI for restricting date range
Attachment #273683 - Attachment is obsolete: true

Comment 12

11 years ago
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.
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.
Taking
Assignee: thardcastle → vladimir
Found in triage - any update?
Priority: -- → P3
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
um, this bug was about the new graphs server.  Shouldn't it be fixed instead of invalid?
No longer blocks: 386669
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.