If we could just add a vertical scaling factor (as suggested by @bidouilleur) to the graph toolbar and be able to scroll up and down that could work, IF the x-axis scale values could move/change as the graph scrolls.
I think a 3 button approach would be needed, scale factor, "scroll upandscroll down` to avoid accidentally zooming in on the y-axis when dragging with the mouse, but I could be wrong, I have never worked with flot, I do not even know how easy it would be for dynamic (scrolling?) x-axis labels, I assume it is possible because if you leave the x-axis max as “auto” and zoom into a part of the day that has lower consumption, the vertical scales adapt automatically.
I’d suggest placing the Nav above the graph. For many of my graphs the data I want is under the Nav. And to see the tooltip I need to click > to slide the graph to the left.
But after a couple of seconds the graph navbar fades and you can see the plots, when the buttons are over the top of the box that leaves less room for the graph and when the graph is embedded and 9 times out of 10 showing the right interval, they are effectively redundant buttons hogging space. Perhaps a “permanent external” verses"internal hover-over" toggle option in the settings would be the way to go. This is one of 2 main reasons I use multigraph over the Graph module.
Seeing your mock up with the handed legends I think that might work well with a centre aligned graph navbar too,
Maybe when the axis are left as “auto” there should be a little extra headroom included, when setting the max manually it’s easy to leave a little extra room.
Since most of my graphs show the most likely viewed data by default, the buttons are rarely used, usually for scrolling back or checking last month/week etc, but when embedded or running in kiosk mode the buttons etc are better hidden, but there if you need them IMO.
Centering the Nav is a nice idea. And leaving more headroom would be great! Or having a choice (if possible) would be great also. Nav might be Inside Right, Inside Center, Outside Right, etc.
(I’m saying “great” too many times. I almost sound presidential!)
This screen grab highlights the need for fixed scales on the y-axis. The top graph is a multigraph with fixed scales of 500 and 4000, the lower “graphs” graph has “auto” y-axis scaling. The data displayed is from the exact same feeds, but the lower graph is magnifying the <0.12 watts of noise and making the graph busy and confusing.
Interestingly, I hadn’t previously noticed the graphs module graph background is transparent, I quite like that but unfortunately it doesn’t outweigh the other functional benefits of the multigraph.
also see Looking for a "dashboard" solution - #15 by GeorgeB for an example of alternative solution using the trace colors for the y-scale text, probably not the best idea to use this specifically but it’s food for thought eg colour the left and right axis red and blue and use those same colours for the legend text so that each entry is either blue or red text to indicate left or right.
Seems a pretty clear solution and you will notice it has 4 feeds, each with their own axis. There would need to be a feed limit of say 4 to prevent confusion.
Another solution is to split the y - axis in four and give a quarter of the axis to each of four feeds.
Mmh, I not so sure, your example graph on the linked thread has 6 traces (2 active and 4 disabled) it isn’t possible to colour 2 x y-axis scales (1x left and 1x right) in 6 different colours and having 6 y-axis wouldn’t be clear at all (I have over a dozen traces on some graphs) which is why I suggest abstracting the axis colours from the trace colours, not mention the trace colours can be quite light and hard to distinguish.
indeed, but how would you map 6 (or more) traces to even 4 y-axis? you couldn’t use trace colors which is why I think the example isn’t ideal. I guess I’m suggesting a max of 2 initially to keep it simple.
bLue for Left and Red for Right is easy to recall as is red legend entries for the right axis (as in “warning you are looking at the wrong axis it’s the right one not the left”)
As a first step having the left y-axis and the labels in the legend for the traces that use the left axis and red for right, would fix the immediate problems and perhaps pave the way for additional left or right scales at a later time to follow the same convention eg the 3rd y-axis could be green and legend entries for traces using that 3rd scale are green text.
I do not know how capable flot is for any of these ideas though, I’m just throwing idea’s out there at this point.
not ideal as it decreases resolution by 4x for the same screen area and overlaying the traces often makes it easier to compare events across traces on different value ranges.
That’s not to say there might be a desire for a graphing tool that plots multiple separate graphs using the same nav tools and settings, but that’s a different topic.
Oops! I must be overdue an eyetest but my point stands 6 trace colours still doesn’t go into 4 axis scales
Currently the only issue is knowing if the trace belongs to the left or right axis, I have to memorize or stick to a rule eg minor loads (<3kW max) on the left and major loads (>3kW max) on the right, these are graphs are generally the best debugging tool I have to hand and the main reason I started this very thread.
But more likely achievable, by making it too complex it sometimes discourages development. 2 colors fixes the issue raised here. job done! Then it could indeed possibly be extended.
I get what you say but which ever way it works 4 graphs stacked take up 4x as much space with the same resolution or give 4x less resolution using the same space and not really a factor in this context, that would be a different visualization it wouldn’t replace this of be concidered a fix for this no matter how useful for something else.
Ok George we’ll have to agree to disagree, if you read my comments in the original thread, the scale disappearing if only one trace is selected doesn’t fix the issue, it might be nice to have and work sometimes, but it isn’t a fix.
This thread is specifically about identifying which traces use which axis scale, removing a scale when only one trace is active does nothing to help that, I thought being able to see which axis the only enabled trace was using would be helpful, perhaps I was wrong.
Showing any sort of scale for something that doesn’t exist seems bizarre to me and I don’t have a clue how it was coded with no data, ergo don’t provide a scale.
If one of those other five traces wasn’t disabled and was tracing a value around zero, you would still see the exact same 2 y-axis scales as the graph you posted… ergo you could still make the same mistake that urged you to propose removing the unused scale… ergo you still need to identify which trace is using which scale.
This is why I say identifying what is what is essential and dropping an unused scale is just nice to have.
I don’t really understand what point you are making, are you saying you can’t or won’t consider another scenario?
I’ve agreed with you, a disappearing axis might be nice to have, but it simply doesn’t fix anything, it only helps when only one axis is in use, in which case you could just create graphs with just the one axis, job done! I don’t know what else to say.
I don’t think I can be any clearer. No feed, no axis.
It fixes the “bug” of showing an axis for something that doesn’t exist and I would have thought it can’t be difficult to show a blank axis.
But the whole idea is that you can deselect feeds in the graph and sometimes 15, 12, 9, 3 or 2 feeds will be cut to 1 for clarity, without creating multiple graphs.
