Old Dashboards

Reference guide

This section refers to Ardexa's v2 dashboards, which are deprecated and no longer available in most workgroups. Please refer to Dashboards for information on our latest iteration of dashboards.

Almost all organizations have a need for dashboards. It is very easy to underestimate the work required to develop them. Dashboards are almost always not about displaying a single number, that is being collected. They usually require a combination of one or more of the following considerations. Furthermore, dashboards almost always need to evolve over time, to best suit the needs of the organization. Sometimes at a fast rate. Here are some issues to consider:

a. Calculations: Often it is required to display a dashboard item based on a calculation. For example, weather data being collected may only be useful if the average hourly temperatures are shown for past few years. This may require a calculation that needs to be run at constant intervals so the data is at hand when required by the user.

b. Lookup Tables: Sometimes there is a need to lookup an item and use another value or translate it somehow. For example, collecting the daily energy produced from a series of machines, over the last 7 days maybe useful. But it may be a lot more useful to display the revenue (dollar amounts) produced by this energy. For this to work, it would be necessary to continuously import the wholesale price of electricity and then use a calculation (see above). This information can then be used to display the revenue. In another example, it may be necessary to display the status information of a machine from one language to another. This is the role of a lookup table that is dynamic (that is; regularly updated), and available to the dashboard.

c. Performance: Sometimes, a device may be collecting data at a very fast rate, say once every second. And often, users may wish to display this data in an interactive graph, over (say) the last 7 days. The problem with this approach is that there will then be about 10,000 points to display in an interactive graph, which means 10,000 points have to be downloaded to the user's browser. If this is then combined with other devices to show trends, then you may find that the user's browser quickly becomes unresponsive due to the influx of data. It may be better to simply download a JPG rendered graph to the user's browser - but then the interactive nature of the display is removed. Often it will be required to store (cache) values that are constantly in use so as to greatly speed access. All these cases relate to performance, which can be a delicate issue to resolve. Care must be taken to make sure that: 1. There is only a reasonable amount of data sent to the user's browser, and/or 2. The data may need to be summarized or averaged to render a better display, and/or 3. Data may need to be converted to an image either directly or at regular intervals so as to ensure a user is not flooded with data

d. Abstraction: If (say) there are many pumps at a reservoir. The technician may need to see these devices in a dashboard, but other users may only need to see a higher level abstraction of (say) a single pump. If this is the case, then the dashboard designer may need to abstract away the many pumps into 1 or 2 pumps on a dashboard. This approach, in combination with Calculations (see above) may result in a cleaner and more informative display for non-technical users.

f. Lifetime and Validity Checking: You almost certainly do not want to display data that is 3 weeks old in a real time graph. It is therefore necessary to make sure that either old data is not displayed, or it has a time label associated with it. This becomes even more problematic when the displayed data needs to be combined with Calculation or Lookup Tables (see above) - where the calculated data needs to be time aligned with other data. In which case, no data should be displayed if the most recent data is not available. This can become a vexing issue.

g. Hierarchy: Users almost always need to display data in a hierarchical dashboard display. This means that from a parent, the user can "drill down" into the data.

h. Security: This has become a very important issue. Users must only be able to access data for which they have access. In cases, where there may be control "widgets" displayed, security becomes critical.

As you can see, there are many aspects to dashboards that are not straightforward. Usually, its not about the display of numbers or the ease by which this can be done. For these reasons, we usually recommend the following approach:

a. Inform Ardexa of your needs as soon as you know them. b. Expect the dashboards to evolve over time. Do not expect them to be perfect at Step 1. c. Let your user's experiment with the dashboards, and ask for their input. This is a critical step in the evolution process.