Old PNG style :-
New SVG style :-
I like the line graphs. I feel they show more, and work well. Importantly, if there is a short period of no traffic or even high traffic, that transition is not clear on the old graphs.
However, there are cases where it looks more "cluttered" and can mask some of the data usually at the bottom of the graph showing latency.
Oddly, quite a few people do not like it, and I had a long conversation with one person that felt it was "wrong" to draw lines. He felt we added data points that did not exist. But a speed graph on a car would have lines even though sampled for periods to make speed from pulses. Eventually he could not explain why lines were wrong. I don't think they are "wrong", just a different way to show the speed and how it changes over time.
Now, I agree, aesthetically they are different, and they have pros and cons.
So latest code aims at a compromise, the "+" marks and thinner lines :-
I am not sure of that. It works OK. So maybe just the "+" marks on SVG?
My conclusion, we need options! The latest code makes SVG which has all points so can work with markers on the line or not, and so we end up with SVG that can be controlled by CSS after the fact. This means we can have user settings on our control pages for A&A, and we have settings for default CSS controls on the FireBrick code. This should allow users (and staff) a choice. Because of change freeze this won't apply until new year, then we will look in to what options we offer. FireBrick users that have access to alpha builds can play now.
I never knew it could be so controversial!
P.S. Plan is now to make code use lines only but CSS controllable so A&A control pages could have options in the new year.
The previous default for SVG was great. Now it looks too cluttered for me, so delighted there are options which can be set.
ReplyDeleteYes, tempted to change the defaults to be line based as before, and allow for markers if wanted. It is maker-width set to blank that should do what you want. Thanks for feedback.
DeleteWorks a treat. Thank you.
Delete(For anyone else looking, it is actually “marker-width”, and it’s an “additional” option.)
Nice to have options, but I like the simple lines look the best.
ReplyDeleteLines look good to me
DeleteLines look fine to me, instantly recognisable for anyone that uses enterprise performance monitoring software.
ReplyDeleteWhilst you've already got dual Y axis, another option could be to dynamically adjust the scale, particularly for the latency measurement. At the moment mine is showing 0 - 500ms but with an average latency around 10ms, so you could 'scale to max' which would change the scale to say 0-15ms (1.5x max). This would pull all the latency information off the bottom of the graph and bring it up to the center to make it much more readable.
Just a thought and as you can't please everyone... options! :)
The svg design allows scale changes later with very little editing. I have used svg to crop the data to allow this. Also, in the actual FireBrick you can get graphs with other scales in the first place. We felt for A&A control pages, especially for comparison, a fixed latency scale was more importantly.
Deletehttps://www.youtube.com/watch?v=cIQ9IXSUzuM
ReplyDeleteNow I know this doesn't at first glance appear to have anything with your graphs, however the questions about how to display sampled values is relevant
I like the new lines, very clean. Didn't think I would when you first previewed them here. Crosses and lines look very cluttered to me.
ReplyDeleteI like the lines, all the other options look cluttered.
ReplyDeleteI can understand your commenters point and had this same arguement at $oldjob.
ReplyDeleteSpeed has an instantaneous value, between two sampling points, the speed will still have been between those two values, no matter how much you "zoom in"
Data downloaded in a period is not as clear cut. It's only measurable *after* the sampling period.
(As I'm writing this, I'm less clear myself, both are "per second" values...)
Well yes, though speed on a car is typically counting pulses so technically you know know it is continuous - you assume, like counting bytes you can assume bytes go at an even rate, or packets...
DeleteI hope you weren't referring to me in your post because in your "SVG all the things" post I commented with a clear explanation of why the line graphs lost detail and were causing a specific problem. I was ready to provide screenshots, but in response you added the PNG option which worked perfectly to restore the original behaviour.
ReplyDeleteThe car analogy isn't great since car speed is continuous and the sampling gives some resolution on that. On the broadband line speed isn't continuous and inventing lines connecting sampled points can be visually useful but, in your implementation, they are also thick enough to swamp some detail.
No, not you - there are several people that have suggested several perceived or actual issues with either approach to this. Thiner lines do help, I agree, and I have been looking at that as well. The main change in the latest FireBrick code is to allow use of markers and lines from CSS to allow the graphs to be presented in a lot of different ways to suite requirements.
DeleteI notice that portfast.co.uk also uses svg line graphs but they don't lose detail because they're much larger (see link). Your graphs are small in comparison; perhaps making them larger will give the SVG room to breathe and make all the problems go away, allowing you to standardise on one display without losing detail.
ReplyDeleteI like the lines in principle but not when they swamp details at normal zoom, requiring several Cmd+ and scrolling to recover the original info.
https://drive.google.com/file/d/1uZHDuIGEDxTOhK48_gLwWVJAnNWPmF9F/view