The amount of information we can compile on switches now is making it impractical to list everything always. As it happens, we already have a natural way to divide the information. It is all derived from nms-map-handlers.js handlers, each handler already has a name, a score and a reason for that score. This is used for the health-stuff, so is well-maintained.
I did a quick test on whether it makes sense, and I'd say it does....
This is with 0 modification to the data source. It's easy to imagine that we can expand upon this by only providing the Description/reason initially until you drill down, and we can even add visual indications of health for each group of information. It would then also make sense to remove some stuff like the snmp "No data"/"Data present" field, and in turn add others.
This is almost exclusively a matter of finding a decent way to visually represent what we want, and not so much a real coding-thing....
Just to clarify: The screenshot would be if every information pane was expanded. Normally, the now-dotted items would be "hidden" until the top-element was expanded.
The amount of information we can compile on switches now is making it impractical to list everything always. As it happens, we already have a natural way to divide the information. It is all derived from nms-map-handlers.js handlers, each handler already has a name, a score and a reason for that score. This is used for the health-stuff, so is well-maintained.
I did a quick test on whether it makes sense, and I'd say it does....
This is with 0 modification to the data source. It's easy to imagine that we can expand upon this by only providing the Description/reason initially until you drill down, and we can even add visual indications of health for each group of information. It would then also make sense to remove some stuff like the snmp "No data"/"Data present" field, and in turn add others.
This is almost exclusively a matter of finding a decent way to visually represent what we want, and not so much a real coding-thing....