The components used in the Intuitive for SAFEQ6 solution have also gone through a transformation piece, akin to the dashboards, datasets and datafeeds.
Starting with the filters, there are a few components that pre-filter data when they’re placed onto a dashboard. It can be for a multitude of reasons, but typically it’s due to us limiting the data based on the scope or story of the dashboard, to show only data relevant to colour documents, duplex documents and so on, or alternatively to limit it based on a time-based flag. These flags are calculated inside of the datafeeds, but are used to restrict the data based on a particular time attribute, such as the last year.
One example to show is on the Environmental Impact dashboard. Component based filters are used quite extensively here, instead of filtering the dashboard as a whole. Reason for this, is that we’re comparing two separate time periods on the same dashboard, the last rolling year vs. the year prior.
Gauges are one area we limit data, and typically it’s when a percentage is used. For example, on the Cost dashboard, the colour % of documents printed are listed through either a linear horizontal bar, or through a speedometer-style gauge with a needle. As our percentages are typically from 0-100, it allows us to set a range of use that is green for ‘good’ (percentages at or under 20%) and red for ‘requires improvement’ (percentages between 20.01% and 100%).
These ranges can be altered very easily, but are changed at the individual component level. To change the values, you need only alter the ranges to your desired input. A useful tip for changing them is to change the upper value first (i.e. the 20.01 to 100) value, and then alter the lower value. Reason being, is that any value overlaps will give an error, and will not allow you to proceed with the rest of your changes.
Additional counts and sums are also show on our grid components. Counts are useful for displaying the number of unique combination of rows. They also have a great use-case when comparing components which have a ‘Top 100’ or ‘Top 20’. In some cases, customers may not have enough unique values to fill these components, so a count of the entire grid component is handy for showing where there’s less data to work with against what the component was designed for.
Sums are often used for calculating the values in that given column. Taking the ‘Top 20 Users’ component from the Executive Summary dashboard, we use a sum against the Total Pages metric. This is a sum of the total pages parameter, but in this case, just for the Top 20 users in the organization. This figure is recalculated when the data onscreen is filtered by the ‘Month’ attribute.
Going back to the ‘Top 100 Documents’-type components, these are limited by row count, and the title usually indicates how many rows to limit by. In this case, sort by a particular metric, and limit to 100. Limiting rows is a way of improving performance, whilst also limiting the usable dataset to the customer. You may want to limit the amount purely for the usage element of the dashboards. For example, if you had a list of 20000 users, would you want to scan through each on individually, or do you have a particular question you wish to ask of this list of users? Typically the story behind the request surrounds a top or bottom selection of criteria. In that case, building focused, row-limited components speeds up analysis time from the user, whilst giving them the most relevant amount of information.
On a last note for grid columns, it’s important to point out when totals are displayed on a given row, and the behaviour around component drilling. Let’s have a look at the Printer Variance in the Printer Analysis dashboard. Drilling into one of the Groups, we’re presented with the printer estate by the:
- OU Name
- Device OU Name
- Device Name
- Device Location
- Group Name
- Total Pages
- Variance
- AVG Page per Printer
Each of these rows shows the unique combination of devices across these different attributes, and the associated measures. It can, in some circumstances, display ‘duplicates’ of data. This is due to again the unique number of combinations the data can present to us. One example could be a device moving across the estate. The Device Name and Device OU Name unchanged, but there be two separate entries for the Device Location with it changing from Location A to Location B. Each associated row will have its own measure totals.
When drilling into the attributes on this page, you’re not selecting a combination of those rows, but rather the explicit value you clicked onscreen. For example, if the row of data was the device name of ‘printer abc’ with a Device Location of ‘location 1’ and we select the location, we’re not selecting this combination of attributes to filter onwards, but rather we’re just selecting the location of ‘location 1’ to pre-filter the next page.
Ultimately, grid components will by design, aggregate data onscreen to show the unique entries of what is in your data. It will not duplicate the exact same rows, but when that visually is nearly the case, it will be down to one attribute (or more!) that is setting it apart from the other ‘duplicate’.
Moving on, we often reuse different components across each of the dashboards. This is by design, as it cuts down the overhead of the number of components that need to be maintained across our solutions. One example are our filters, where a ‘month’ filter is applicable for most of the dashboards, and so therefore doesn’t need to be recreated each time. If we’ve already created that component once, and it is useful elsewhere in the solution, it should be reused.