Custom Dashboard Best Practices
? Develop your dashboards using whatever resolution is appropriate for whatever resolution/size screen you need to view it on in the NOC/SOC/desktop/laptop and adjust your layout accordingly. If you create a background image of the desired size you can use it as a guide for your Dashboard layout.
? Rely on a graphics designer or learn to use Adobe Photoshop or a free tool like GIMP to create images with transparent sections.
? Maintain an image library on your desktop and pull the images in from there instead of using the Dashboard Designer image browser which is limited in size.
? Limit your Dashboard images to less than a total of 5 MB/200 images if possible
? Use ?Panel Links? instead of just ?Panel? widgets to optimize performance
? Please keep in mind that if you use too many Panels (versus Panel Links) and have many underlying dashboards, dashboard performance will be adversely affected. Therefore, please use Panel Links wherever possible versus Panels that allow nesting.
Note that you will have to create an ?Up? button for each underlying dashboard to navigate back to the Parent Panel (via link).
The size of the data returned for a dashboard panel should not exceed 5MB. If so occurs you may observe slow response, scroll bars freezing or not causing content in dashboard to scroll. In order to estimate the data sent for a panel you can use the following guidelines:
? Gauge, meter, slider: on average 50 bytes
? Chart: on average 50 bytes for each sample
? Table: size of data returned from query + overhead for each cell equal to (the length of the column name times 2) + 5 bytes.
If this size limit is surpassed UMP should log message to its log and send notification to the requesting client.
To alleviate this issue, you MAY need to redesign your Dashboards to minimize the use of Panels and use Links instead. This would entail copying/creating MANY separate dashboards. For a Parent/main dashboard, your initial Panel may not be that large but each of the underlying nodes/servers/objects etc may a custom Dashboard below it. Each custom Dashboard may contains charts, widgets, text boxes, gauges, images etc... So perhaps each custom dashboard may not be that big per se but it may add up when you total it all up -- underlying dashboards that need to cache images/load underlying objects/images/data etc.
? Try also to keep your Dashboard levels to a total of 3 LEVELS deep.
? Dashboard size/scope: create dashboards with future needs in mind so you plan for enough space to add more objects/images if needed, e.g., more servers, more customers, devices, etc. Keep the dashboard adaptable.
Note that there are some drawbacks to using Links versus Panels for the sake of performance improvement (SDP/UMP).
1. You have to publish ALL of the Dashboards you need to link to (so now they will ALL show up in the Custom dashboard view along with the parent Dashboard) ? it has been noted and we are aware of this so we may be able to hide the linked dashboards in a future release.
2. Entirely new windows open instead of being able to drill down into the underlying Panels within the same window
3. Navigation link objects (e.g., up arrows with links to parent dashboard) need to be placed on every dashboard below the parent so you can navigate back to the previous Dashboard.
I also recommend using Mozilla Firefox (latest version) for the best performance as well as the latest version of Flash.
Approximate image sizes given an example set of images.
8 alarm images: ~6 Kb
3 gauges: ~150 Kb
6 charts, 6 hour time-period: ~300 Kb
3 LEDs: ~ 150Kb
14 Text boxes: ~unknown
1 table: ~250Kb?