Opened 7 years ago

Closed 7 years ago

#11389 closed enhancement (fixed)

Graphs should start/end at the same position

Reported by: rndm Owned by: rndm
Priority: Medium Milestone:
Component: Metrics/Globe Version:
Severity: Keywords:
Cc: karsten Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

> Do you think it would be better to modify the graphs so all of them
> start/end at the same time? (There is a small offset because the first
> and last fields aren't always the same)

I thought about this, but didn't bring it up yet, because it may not be
trivial to implement.


Idea #1: Does the graphing engine support defining the x axis limits
independent of displayed data points?  That is, can you draw a graph
like this (bad ASCII "art" ahead):

              +-----------------------------------+
              |                                   |
              |                       -O          |
    O--       | --O------O--        --            |
       --     |-            --    --              |
         --O--|               --O-                |
              |                                   |
              +-----------------------------------+
           x_start                              x_end

If so, I'd say try setting x_start to current system time minus whatever
period you're displaying and x_end to current system time.

By doing so, you'll discard a few data points left to x_start, and
you'll leave some graph space empty between the last O and x_end.  But
you'll have graphs displaying exactly the promised time period, and
graphs for that period will be easier to compare.  I'd say that's a fine
compromise.


Idea #2: If the graphing engine does not support redefining x axis
limits, you'll need to do some tricks: if there's no data point for
x_start, compute this point as the average of the two data points before
and after x_start; also add a "null" value for x_end.

Here's a build that changes the dygraph range to start at the earliest date and end at the latest date in all periods:

http://globe.rndm.de/canary/index-11349-trim-graphs.html

It is possible to start at the earliest date that is in all periods and end at the latest date that is in all periods.
My concern is that for some periods it can happen that this range spans only around two days (see 3_days http://i.imgur.com/RdH61YT.png ). This could confuse the user because he clicked on the "3 days" period.

What do you think?

(If you're cutting off values left to
x_start as discussed above, be sure to exclude them from the average.)

As I'm not cutting anything off (it's basically zoomed in/out) is this still an issue?

Child Tickets

Change History (10)

comment:1 Changed 7 years ago by karsten

So, your first variant displays [min(x_start), max(x_end)].

And your second variant shows [max(x_start), min(x_end)], right?

I think the first variant has the downside that there are missing values to the left, which might confuse relay/bridge operators, because their relay/bridge operator was running and submitting data at that time. This is probably not as bad with missing values to the right, because operators understand more quickly that their relay/bridge did not report that specific type of data to display yet.

Your second variant indeed has the problem that the displayed period does not match what the user selected.

How about a mix of the two: [max(x_start), max(x_end)]?

Those graphs will cover the selected period (under the assumption that the relay/bridge was running long enough), and it will only have missing values to the right.

Regarding calculating the average: with sliders this is not an issue, because users will understand that the average is calculated for the full graph, not just for the currently visible part. (And they sure wouldn't expect that the average gets updated when they use the slider.) But once you put these graphs into Globe-node which doesn't have sliders (IIUC), you should only include data in the averages that is displayed in the graph. So, maybe leave it as is and put in a TODO note for Globe-node?

comment:2 in reply to:  1 Changed 7 years ago by rndm

Replying to karsten:

How about a mix of the two: [max(x_start), max(x_end)]?

Those graphs will cover the selected period (under the assumption that the relay/bridge was running long enough), and it will only have missing values to the right.

I updated http://globe.rndm.de/canary/index-11349-trim-graphs.html so it now uses [max(x_start), max(x_end)]. If there's nothing wrong with it I'll close this issue, merge it and work on fixing #11349.

Regarding calculating the average: with sliders this is not an issue, because users will understand that the average is calculated for the full graph, not just for the currently visible part. (And they sure wouldn't expect that the average gets updated when they use the slider.)

Sounds reasonable.

But once you put these graphs into Globe-node which doesn't have sliders (IIUC), you should only include data in the averages that is displayed in the graph. So, maybe leave it as is and put in a TODO note for Globe-node?

Ok.

comment:3 Changed 7 years ago by karsten

Looks good! Feel free to close, merge, and tell me what to deploy. Thanks!

comment:4 Changed 7 years ago by rndm

I released https://github.com/makepanic/globe/releases/tag/v0.4.6 which includes the fix for this issue.

comment:5 Changed 7 years ago by rndm

Resolution: fixed
Status: newclosed

comment:6 Changed 7 years ago by karsten

Resolution: fixed
Status: closedreopened

Maybe it was a mistake to use the [max(x_start), max(x_end)] approach. What if one graph type only covers a small part of the other graph types? It would be sad not to display most of the other types' data, even though it's covering the selected period just fine.

New idea: how about we use [now - time_period, now] as visible x-axis limits?

comment:7 in reply to:  6 Changed 7 years ago by rndm

Replying to karsten:

Maybe it was a mistake to use the [max(x_start), max(x_end)] approach. What if one graph type only covers a small part of the other graph types? It would be sad not to display most of the other types' data, even though it's covering the selected period just fine.

New idea: how about we use [now - time_period, now] as visible x-axis limits?

Here's a version that uses [now - time_period, now]:

http://globe.rndm.de/canary/index-11389.html

comment:8 Changed 7 years ago by karsten

Looks good! Let me know when you have a new version to deploy. Thanks!

comment:9 Changed 7 years ago by rndm

I released v0.4.7 which includes the fix for this issue.
https://github.com/makepanic/globe/releases/tag/v0.4.7

comment:10 Changed 7 years ago by karsten

Resolution: fixed
Status: reopenedclosed

Great. Deployed on globe.tpo. Thanks! Closing.

Note: See TracTickets for help on using tickets.