Hi Christian,
moving our private discussion to the public mailing list.
You were asking about making graphs from Onionoo's new clients documents. Here's an example:
"1_week":{"first":"2014-03-23 12:00:00","last":"2014-03-30 12:00:00","interval":86400,"factor":0.002802803,"count":8,"values":[251,933,471,955,999,999,735,713],"countries":{"cn":0.1882,"dz":0.0728,"es":0.0146,"fr":0.1006,"gb":0.0174,"hk":0.0233,"ir":0.1119,"jp":0.1882,"kz":0.0117,"my":0.1532,"us":0.1123},"versions":{"v4":1.0000}},
For this bridge, you'd draw the first data point at x = 2014-03-23 12:00:00 UTC with y = 251 * 0.002802803 = 0,703503553 concurrent users.
You were also asking about feedback on new uptime graphs:
http://rndm.de/globe/canary/index-11349.html
Looks pretty good! The uptime graphs for the relays I checked were not as exciting as the bandwidth graphs, but it's actually good if uptime is always at 100%.
And finally, you asked about showing numeric averages next to graphs, like on:
https://status.github.com/graphs/past_week
I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs.
Thanks!
All the best, Karsten
On 30.03.2014 12:44, Karsten Loesing wrote:
Hi Christian,
moving our private discussion to the public mailing list.
You were asking about making graphs from Onionoo's new clients documents. Here's an example:
"1_week":{"first":"2014-03-23 12:00:00","last":"2014-03-30 12:00:00","interval":86400,"factor":0.002802803,"count":8,"values":[251,933,471,955,999,999,735,713],"countries":{"cn":0.1882,"dz":0.0728,"es":0.0146,"fr":0.1006,"gb":0.0174,"hk":0.0233,"ir":0.1119,"jp":0.1882,"kz":0.0117,"my":0.1532,"us":0.1123},"versions":{"v4":1.0000}},
For this bridge, you'd draw the first data point at x = 2014-03-23 12:00:00 UTC with y = 251 * 0.002802803 = 0,703503553 concurrent users.
Thanks, I added client graphs to canary/index-11349.html .
You were also asking about feedback on new uptime graphs:
http://rndm.de/globe/canary/index-11349.html
Looks pretty good! The uptime graphs for the relays I checked were not as exciting as the bandwidth graphs, but it's actually good if uptime is always at 100%.
And finally, you asked about showing numeric averages next to graphs, like on:
https://status.github.com/graphs/past_week
I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs.
Do you think, that we should place all graphs above eachother? With more than two graphs it's harder to compare them if they're positioned in a grid like fashion.
Thanks!
All the best, Karsten
On 30/03/14 22:54, Christian wrote:
On 30.03.2014 12:44, Karsten Loesing wrote:
Hi Christian,
moving our private discussion to the public mailing list.
You were asking about making graphs from Onionoo's new clients documents. Here's an example:
"1_week":{"first":"2014-03-23 12:00:00","last":"2014-03-30 12:00:00","interval":86400,"factor":0.002802803,"count":8,"values":[251,933,471,955,999,999,735,713],"countries":{"cn":0.1882,"dz":0.0728,"es":0.0146,"fr":0.1006,"gb":0.0174,"hk":0.0233,"ir":0.1119,"jp":0.1882,"kz":0.0117,"my":0.1532,"us":0.1123},"versions":{"v4":1.0000}},
For this bridge, you'd draw the first data point at x = 2014-03-23 12:00:00 UTC with y = 251 * 0.002802803 = 0,703503553 concurrent users.
Thanks, I added client graphs to canary/index-11349.html .
Awesome!
You were also asking about feedback on new uptime graphs:
http://rndm.de/globe/canary/index-11349.html
Looks pretty good! The uptime graphs for the relays I checked were not as exciting as the bandwidth graphs, but it's actually good if uptime is always at 100%.
And finally, you asked about showing numeric averages next to graphs, like on:
https://status.github.com/graphs/past_week
I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs.
Do you think, that we should place all graphs above eachother? With more than two graphs it's harder to compare them if they're positioned in a grid like fashion.
Putting them above each other might make sense, yes. Also reducing graph height might work, so that all graphs fit on a small display.
Here's another thing I like in GitHub's graphs: the "Past Day/Past Week/Past Month" selector that affects all graphs at once. Do you think something like that would work for Globe (or Globe-node)?
So, basically, we'd have similar graphs as GitHub, but with more than 1 line per graph, because we want to compare those lines directly to each other.
Thanks!
All the best, Karsten
On 31.03.2014 08:38, Karsten Loesing wrote:
On 30/03/14 22:54, Christian wrote:
On 30.03.2014 12:44, Karsten Loesing wrote:
Hi Christian,
moving our private discussion to the public mailing list.
You were asking about making graphs from Onionoo's new clients documents. Here's an example:
"1_week":{"first":"2014-03-23 12:00:00","last":"2014-03-30 12:00:00","interval":86400,"factor":0.002802803,"count":8,"values":[251,933,471,955,999,999,735,713],"countries":{"cn":0.1882,"dz":0.0728,"es":0.0146,"fr":0.1006,"gb":0.0174,"hk":0.0233,"ir":0.1119,"jp":0.1882,"kz":0.0117,"my":0.1532,"us":0.1123},"versions":{"v4":1.0000}},
For this bridge, you'd draw the first data point at x = 2014-03-23 12:00:00 UTC with y = 251 * 0.002802803 = 0,703503553 concurrent users.
Thanks, I added client graphs to canary/index-11349.html .
Awesome!
You were also asking about feedback on new uptime graphs:
http://rndm.de/globe/canary/index-11349.html
Looks pretty good! The uptime graphs for the relays I checked were not as exciting as the bandwidth graphs, but it's actually good if uptime is always at 100%.
And finally, you asked about showing numeric averages next to graphs, like on:
https://status.github.com/graphs/past_week
I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs.
Do you think, that we should place all graphs above eachother? With more than two graphs it's harder to compare them if they're positioned in a grid like fashion.
Putting them above each other might make sense, yes. Also reducing graph height might work, so that all graphs fit on a small display.
Here's another thing I like in GitHub's graphs: the "Past Day/Past Week/Past Month" selector that affects all graphs at once. Do you think something like that would work for Globe (or Globe-node)?
I thought about that, but wasn't sure how we should handle periods that aren't available for all history documents. Bandwidth documents go from '3_days' to '1_year'. Weight, clients and uptime documents from '1_week' to '5_years'.
Here's a WIP build that contains tabs and graphs above eachother:
http://globe.rndm.de/canary/index-11349-graph-layout.html
If the period isn't available it displays the 'No data available' message.
(I'm going to port these changes to globe-node if we're done with the ui and functionality of the new graphs)
So, basically, we'd have similar graphs as GitHub, but with more than 1 line per graph, because we want to compare those lines directly to each other.
Thanks!
All the best, Karsten
On 31/03/14 18:38, Christian wrote:
On 31.03.2014 08:38, Karsten Loesing wrote:
On 30/03/14 22:54, Christian wrote:
On 30.03.2014 12:44, Karsten Loesing wrote:
And finally, you asked about showing numeric averages next to graphs, like on:
https://status.github.com/graphs/past_week
I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs.
Do you think, that we should place all graphs above eachother? With more than two graphs it's harder to compare them if they're positioned in a grid like fashion.
Putting them above each other might make sense, yes. Also reducing graph height might work, so that all graphs fit on a small display.
Here's another thing I like in GitHub's graphs: the "Past Day/Past Week/Past Month" selector that affects all graphs at once. Do you think something like that would work for Globe (or Globe-node)?
I thought about that, but wasn't sure how we should handle periods that aren't available for all history documents. Bandwidth documents go from '3_days' to '1_year'.
Bandwidth documents should also be available for '5_years'.
Weight, clients and uptime documents from '1_week' to '5_years'.
That's true. But you could use data from the '1_week' lines by skipping everything until $(now - 3 days) and only displaying the last 3 days. Those graphs will have slightly lower "data resolution" than the '3_days' bandwidth graph, but it will still be useful to compare them to the bandwidth graph.
(I guess I should add this remark to the Onionoo protocol page.)
Here's a WIP build that contains tabs and graphs above eachother:
Looks really good!
If the period isn't available it displays the 'No data available' message.
That's fine. After all, there may be edge cases when there's no data available, not just in the '3_days' case.
(I'm going to port these changes to globe-node if we're done with the ui and functionality of the new graphs)
Sure.
Thanks!
All the best, Karsten
On 31.03.2014 19:54, Karsten Loesing wrote:
On 31/03/14 18:38, Christian wrote:
On 31.03.2014 08:38, Karsten Loesing wrote:
On 30/03/14 22:54, Christian wrote:
On 30.03.2014 12:44, Karsten Loesing wrote:
And finally, you asked about showing numeric averages next to graphs, like on:
https://status.github.com/graphs/past_week
I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs.
Do you think, that we should place all graphs above eachother? With more than two graphs it's harder to compare them if they're positioned in a grid like fashion.
Putting them above each other might make sense, yes. Also reducing graph height might work, so that all graphs fit on a small display.
Here's another thing I like in GitHub's graphs: the "Past Day/Past Week/Past Month" selector that affects all graphs at once. Do you think something like that would work for Globe (or Globe-node)?
I thought about that, but wasn't sure how we should handle periods that aren't available for all history documents. Bandwidth documents go from '3_days' to '1_year'.
Bandwidth documents should also be available for '5_years'.
My fault, I haven't seen the line break.
Weight, clients and uptime documents from '1_week' to '5_years'.
That's true. But you could use data from the '1_week' lines by skipping everything until $(now - 3 days) and only displaying the last 3 days. Those graphs will have slightly lower "data resolution" than the '3_days' bandwidth graph, but it will still be useful to compare them to the bandwidth graph.
(I guess I should add this remark to the Onionoo protocol page.)
I added computed 3_days graphs.
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)
Next up I'll add some data for the left column. Is there anything special that should be visible there? If not I'm going to use the status.github idea and display average graph data there.
Here's a WIP build that contains tabs and graphs above eachother:
Looks really good!
If the period isn't available it displays the 'No data available' message.
That's fine. After all, there may be edge cases when there's no data available, not just in the '3_days' case.
(I'm going to port these changes to globe-node if we're done with the ui and functionality of the new graphs)
Sure.
Thanks!
All the best, Karsten
On 31/03/14 22:24, Christian wrote:
On 31.03.2014 19:54, Karsten Loesing wrote:
On 31/03/14 18:38, Christian wrote:
Weight, clients and uptime documents from '1_week' to '5_years'.
That's true. But you could use data from the '1_week' lines by skipping everything until $(now - 3 days) and only displaying the last 3 days. Those graphs will have slightly lower "data resolution" than the '3_days' bandwidth graph, but it will still be useful to compare them to the bandwidth graph.
(I guess I should add this remark to the Onionoo protocol page.)
I added computed 3_days graphs.
Nice! The data resolution is actually better than I had expected.
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.
Idea #3: If you want to postpone implementing this, feel free to open a ticket and paste our conversation there. Especially if you'd have to implement a workaround for the current graphing engine and re-implement something else for Globe-node. This is a nice feature and worth doing, but it's not a blocker.
Next up I'll add some data for the left column. Is there anything special that should be visible there? If not I'm going to use the status.github idea and display average graph data there.
Average graph data sounds good. (If you're cutting off values left to x_start as discussed above, be sure to exclude them from the average.)
Thanks!
All the best, Karsten
On 01.04.2014 09:56, Karsten Loesing wrote:
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_endIf 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.
Idea #3: If you want to postpone implementing this, feel free to open a ticket and paste our conversation there. Especially if you'd have to implement a workaround for the current graphing engine and re-implement something else for Globe-node. This is a nice feature and worth doing, but it's not a blocker.
I'm going to try solving this tomorrow. If nothing useful comes out of it I'll open an issue.
Next up I'll add some data for the left column. Is there anything special that should be visible there? If not I'm going to use the status.github idea and display average graph data there.
Average graph data sounds good. (If you're cutting off values left to x_start as discussed above, be sure to exclude them from the average.)
I updated the #11349 build with average data:
http://globe.rndm.de/canary/index-11349.html
Thanks!
All the best, Karsten
On 01/04/14 22:12, Christian wrote:
On 01.04.2014 09:56, Karsten Loesing wrote:
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_endIf 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.
Idea #3: If you want to postpone implementing this, feel free to open a ticket and paste our conversation there. Especially if you'd have to implement a workaround for the current graphing engine and re-implement something else for Globe-node. This is a nice feature and worth doing, but it's not a blocker.
I'm going to try solving this tomorrow. If nothing useful comes out of it I'll open an issue.
Sounds good. Maybe, if you don't mind, let's move this discussion to a ticket regardless.
Next up I'll add some data for the left column. Is there anything special that should be visible there? If not I'm going to use the status.github idea and display average graph data there.
Average graph data sounds good. (If you're cutting off values left to x_start as discussed above, be sure to exclude them from the average.)
I updated the #11349 build with average data:
Looks great! I added some feedback to #11349.
Thanks!
All the best, Karsten
Hi,
nice work! One nitpick: if the legend to the left was colour coded like the graphs I would not need to hover over the graphs to see which curve reflects which category.
I was thinking about how it could be possible to combine all perspectives in one graphing window. Especially the seperate window for the bandwidth perspective seems a little wasted and disconnected. Maybe the bandwidth could be rendered as a backdrop plane behind the curves, then on top / in front of it the bandwidth graphs in shades of e.g. red to yellow and the weights graphs in shades of blue to green. Not sure if that works or if you have tried it already. Would need 3 scales on the left, probably colour coded again. Benefit would be that the time slider on the bottom would work for all perspectives synchronously. I always like to have all the information in one place so that my eye doesnt have to wonder, my brain doesn’t have to correlate etc. But of course there’s a treshold where the interface get’s too cluttered to be useful anymore.
Ciao Thomas
On 02 Apr 2014, at 09:35, Karsten Loesing karsten@torproject.org wrote:
On 01/04/14 22:12, Christian wrote:
On 01.04.2014 09:56, Karsten Loesing wrote:
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.
Idea #3: If you want to postpone implementing this, feel free to open a ticket and paste our conversation there. Especially if you'd have to implement a workaround for the current graphing engine and re-implement something else for Globe-node. This is a nice feature and worth doing, but it's not a blocker.
I'm going to try solving this tomorrow. If nothing useful comes out of it I'll open an issue.
Sounds good. Maybe, if you don't mind, let's move this discussion to a ticket regardless.
Next up I'll add some data for the left column. Is there anything special that should be visible there? If not I'm going to use the status.github idea and display average graph data there.
Average graph data sounds good. (If you're cutting off values left to x_start as discussed above, be sure to exclude them from the average.)
I updated the #11349 build with average data:
Looks great! I added some feedback to #11349.
Thanks!
All the best, Karsten
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 02/04/14 11:46, thomas lörtsch wrote:
nice work! One nitpick: if the legend to the left was colour coded like the graphs I would not need to hover over the graphs to see which curve reflects which category.
Right, I asked the same thing on the ticket:
https://trac.torproject.org/projects/tor/ticket/11349
I was thinking about how it could be possible to combine all perspectives in one graphing window. Especially the seperate window for the bandwidth perspective seems a little wasted and disconnected. Maybe the bandwidth could be rendered as a backdrop plane behind the curves, then on top / in front of it the bandwidth graphs in shades of e.g. red to yellow and the weights graphs in shades of blue to green. Not sure if that works or if you have tried it already. Would need 3 scales on the left, probably colour coded again. Benefit would be that the time slider on the bottom would work for all perspectives synchronously. I always like to have all the information in one place so that my eye doesnt have to wonder, my brain doesn’t have to correlate etc. But of course there’s a treshold where the interface get’s too cluttered to be useful anymore.
Hmm. I don't fully understand the graph that you suggest. Can you attach a draft, maybe even something drawn on paper?
My initial reaction is that this is going to be a heavily overloaded graph. In particular putting three different scales on the y axis is discouraged, I think. Also, with all the different colors this graph becomes pretty hard to understand for color-blind people.
If there's a way to overcome these problems, happy to brainstorm more about the topic. :)
All the best, Karsten
On 02 Apr 2014, at 15:40, Karsten Loesing karsten@torproject.org wrote:
On 02/04/14 11:46, thomas lörtsch wrote:
nice work! One nitpick: if the legend to the left was colour coded like the graphs I would not need to hover over the graphs to see which curve reflects which category.
Right, I asked the same thing on the ticket:
Ah, cool. I didn’t know the URL for the tracker.
I was thinking about how it could be possible to combine all perspectives in one graphing window. Especially the seperate window for the bandwidth perspective seems a little wasted and disconnected. Maybe the bandwidth could be rendered as a backdrop plane behind the curves, then on top / in front of it the bandwidth graphs in shades of e.g. red to yellow and the weights graphs in shades of blue to green. Not sure if that works or if you have tried it already. Would need 3 scales on the left, probably colour coded again. Benefit would be that the time slider on the bottom would work for all perspectives synchronously. I always like to have all the information in one place so that my eye doesnt have to wonder, my brain doesn’t have to correlate etc. But of course there’s a treshold where the interface get’s too cluttered to be useful anymore.
Hmm. I don't fully understand the graph that you suggest. Can you attach a draft, maybe even something drawn on paper?
Just imagine all curves in one graphic instead of three. And then I’m making suggestions on how to make that mess readable again :)
My initial reaction is that this is going to be a heavily overloaded graph.
That is of course the problem. It would have to be tested how far color coding can help. Probably your instinct is right and it’s not feasable. Maybe Christian already tried and dismissed it.
In particular putting three different scales on the y axis is discouraged, I think.
That’s solvable. Bandwidth scale to the left, weights to the right, and uptime doesn’t really need a scale (just a legend saying that 100% equals the full height of the graphic).
Also, with all the different colors this graph becomes pretty hard to understand for color-blind people.
It’s definitely not for color-blind people, but I don’t see a way around that since different styles for strokes (like ‘dotted’ etc) make the curves pretty hard. I don’t know about the details though - which colors are more problematic then others, what are critical tresholds between shades of colors etc.
If there's a way to overcome these problems, happy to brainstorm more about the topic. :)
Ciao Thomas
On 02/04/14 15:58, thomas lörtsch wrote:
On 02 Apr 2014, at 15:40, Karsten Loesing karsten@torproject.org wrote:
On 02/04/14 11:46, thomas lörtsch wrote:
nice work! One nitpick: if the legend to the left was colour coded like the graphs I would not need to hover over the graphs to see which curve reflects which category.
Right, I asked the same thing on the ticket:
Ah, cool. I didn’t know the URL for the tracker.
Yeah, it's a bit confusing with the code being hosted on GitHub, the preview versions running on Christian's own server, the stable version running on a Tor VM, and issues being tracked in Tor's Trac. The only solution is that somebody meets Christian in person, makes sure he's a human, and signs his PGP key, so that we can give him access to do everything on Tor gear. :)
I was thinking about how it could be possible to combine all perspectives in one graphing window. Especially the seperate window for the bandwidth perspective seems a little wasted and disconnected. Maybe the bandwidth could be rendered as a backdrop plane behind the curves, then on top / in front of it the bandwidth graphs in shades of e.g. red to yellow and the weights graphs in shades of blue to green. Not sure if that works or if you have tried it already. Would need 3 scales on the left, probably colour coded again. Benefit would be that the time slider on the bottom would work for all perspectives synchronously. I always like to have all the information in one place so that my eye doesnt have to wonder, my brain doesn’t have to correlate etc. But of course there’s a treshold where the interface get’s too cluttered to be useful anymore.
Hmm. I don't fully understand the graph that you suggest. Can you attach a draft, maybe even something drawn on paper?
Just imagine all curves in one graphic instead of three. And then I’m making suggestions on how to make that mess readable again :)
Indeed. And imagine how the graph becomes even less readable when we add two more graphs for absolute numbers for advertised bandwidth and consensus weight... I'm not sure how putting everything into one graph is going to scale. Though I see the motivation for having everything in one place.
My initial reaction is that this is going to be a heavily overloaded graph.
That is of course the problem. It would have to be tested how far color coding can help. Probably your instinct is right and it’s not feasable. Maybe Christian already tried and dismissed it.
In particular putting three different scales on the y axis is discouraged, I think.
That’s solvable. Bandwidth scale to the left, weights to the right, and uptime doesn’t really need a scale (just a legend saying that 100% equals the full height of the graphic).
I was not referring to technical limitations, but I think putting more than one scale on an axis is discouraged in general. I would have to read up the arguments against it, but I remember Hadley Wickham, the ggplot2 author, bringing up some reasons why it's a Bad Idea.
In fact, here's a quick web search, though this is probably not the best hit:
https://stat.ethz.ch/pipermail/r-help/2006-August/111047.html
Also, with all the different colors this graph becomes pretty hard to understand for color-blind people.
It’s definitely not for color-blind people, but I don’t see a way around that since different styles for strokes (like ‘dotted’ etc) make the curves pretty hard. I don’t know about the details though - which colors are more problematic then others, what are critical tresholds between shades of colors etc.
I agree that the alternative to using many colors is *not* to use different stroke styles.
The better alternative is probably to make separate graphs with fewer colors or no colors at all. I really liked the GitHub graphs, mentioned earlier in this thread, being all black and white. But I don't see how we can remove color as dimension entirely.
As for problematic colors for color-blind people, there's a related ticket about metrics website graphs:
https://trac.torproject.org/projects/tor/ticket/6463
There are a couple of useful links in there.
If there's a way to overcome these problems, happy to brainstorm more about the topic. :)
Ciao
Cheers! Karsten
On 03 Apr 2014, at 10:10, Karsten Loesing karsten@torproject.org wrote:
On 02/04/14 15:58, thomas lörtsch wrote:
On 02 Apr 2014, at 15:40, Karsten Loesing karsten@torproject.org wrote:
Just imagine all curves in one graphic instead of three. And then I’m making suggestions on how to make that mess readable again :)
Indeed. And imagine how the graph becomes even less readable when we add two more graphs for absolute numbers for advertised bandwidth and consensus weight... I'm not sure how putting everything into one graph is going to scale. Though I see the motivation for having everything in one place.
Adding more graphs definitely breaks the idea of gathering all graphs in one graphic at the same time. Still there probably are usecases where comparision of different graphs is helpful. Another way to tackle the problem could be to have one more graphing area in which graphs are selectable from a menu - again color coded if it’s more than one and the scales color coded as well. That might be an addition to the existing graphing areas, by default populated with a preselected assortment of graphs that often need to be examined in combination.
My initial reaction is that this is going to be a heavily overloaded graph.
That is of course the problem. It would have to be tested how far color coding can help. Probably your instinct is right and it’s not feasable. Maybe Christian already tried and dismissed it.
In particular putting three different scales on the y axis is discouraged, I think.
That’s solvable. Bandwidth scale to the left, weights to the right, and uptime doesn’t really need a scale (just a legend saying that 100% equals the full height of the graphic).
I was not referring to technical limitations, but I think putting more than one scale on an axis is discouraged in general. I would have to read up the arguments against it, but I remember Hadley Wickham, the ggplot2 author, bringing up some reasons why it's a Bad Idea.
Generally that’s probably right but the advantages would have been considerable. If this was the only problem I would have dimissed it.
In fact, here's a quick web search, though this is probably not the best hit:
https://stat.ethz.ch/pipermail/r-help/2006-August/111047.html
Also, with all the different colors this graph becomes pretty hard to understand for color-blind people.
It’s definitely not for color-blind people, but I don’t see a way around that since different styles for strokes (like ‘dotted’ etc) make the curves pretty hard. I don’t know about the details though - which colors are more problematic then others, what are critical tresholds between shades of colors etc.
I agree that the alternative to using many colors is *not* to use different stroke styles.
The better alternative is probably to make separate graphs with fewer colors or no colors at all. I really liked the GitHub graphs, mentioned earlier in this thread, being all black and white. But I don't see how we can remove color as dimension entirely.
As for problematic colors for color-blind people, there's a related ticket about metrics website graphs:
https://trac.torproject.org/projects/tor/ticket/6463
There are a couple of useful links in there.
Ah, very good. Thanks!
Bye Thomas
On Tue, Apr 1, 2014 at 9:12 PM, Christian me@rndm.de wrote:
Average graph data sounds good. (If you're cutting off values left to x_start as discussed above, be sure to exclude them from the average.)
I updated the #11349 build with average data:
I really like these graphs! One other thing that I personally would find useful is a graph showing the advertised bandwidth and consensus weight in absolute terms, to distinguish effects of things happening on my relay from those happening to the overall Tor network. Would that be hard to add?
Thanks, - Nikita
On 02/04/14 15:48, Nikita Borisov wrote:
On Tue, Apr 1, 2014 at 9:12 PM, Christian me@rndm.de wrote:
Average graph data sounds good. (If you're cutting off values left to x_start as discussed above, be sure to exclude them from the average.)
I updated the #11349 build with average data:
I really like these graphs! One other thing that I personally would find useful is a graph showing the advertised bandwidth and consensus weight in absolute terms, to distinguish effects of things happening on my relay from those happening to the overall Tor network. Would that be hard to add?
It's actually not easy to add those new graphs to Globe, because Onionoo doesn't yet provide these absolute numbers, just fractions. But it does sound useful to also have absolute numbers. It's also something that Roger wants for graphs for the Tor relay challenge. I just opened a ticket for this:
https://trac.torproject.org/projects/tor/ticket/11388
This is going to take a few weeks though. If you have more ideas what graphs would be useful to have, now is a fine time to mention them. :)
Thanks!
All the best, Karsten
-
Christian -
Karsten Loesing -
Nikita Borisov -
thomas lörtsch