Use of Number Scaling

Center of Excellence

1. Abstract

A common requirement when displaying data, particularly financial data, is to use scaling – whether that’s displaying numbers in thousands, millions or whatever makes sense in order to make the displayed data more easily readable.

2. Context

There are multiple ways in which scaling can be introduced when displaying data, the suitability of different methods depends on the precise nature of the data to be displayed along with the use case in question, and each method has advantages and disadvantages.

3. Content

3.1 Automated Method

Board provides us a feature called “Data View Numbers scaling” which automatically displays large numbers in a shortened format with one decimal place, adding a "K" for thousands, "M" for millions or "B" for billions. But sometimes the automated feature does not fully meet our requirement because we want to apply specific scaling rule to specific report’s lines.

Several factors need to be considered when deciding upon the best method for introducing scaling, there are several methods which can be used, and each lends itself to a different situation.

3.2 Custom Methods

There are several methods which can be used to introduce scaling, from overly simplistic to slightly more involved, which you should use depends on the use case.

3.2.1 Divide By

Board natively supports basic scaling in the form of the Divide By setting, each block in a layout is by default set to divide by 1, however when required this can be set on any number required – 1000 to display in thousands, 1000000 to display in millions, or even -1000 if the signage is to be flipped along with the introduction of scaling.

This method works well where a single block needs to be scaled consistently with no exceptions, it requires minimal effort and can be set up very quickly, however it’s then hardcoded – meaning that if the requirement changes down the line each individual layout using this method may need to be updated separately, and it also applies to the entire block, with no distinction between different rows of the layout.

3.2.2 Algorithm Based on an Entity

A second option which can be used is to hide the cube to be displayed, and to instead display an algorithm block which performs the scaling based on an entity block. Say you want to display a list of metrics, most of which are monetary but a handful of which are not – you might want to divide the monetary values but not the others (for example dividing a headcount might render the numbers too small to be properly readable). In this instance you might include the metric code as an entity block and use an algorithm which looks at the code of the entity to be displayed and decides whether it should be divided by 1000.

This method works well where the distinction between scaled and non-scaled rows is quite simple and only either a small number of exceptions exist, or the exceptions have a consistent coding so as to be easily identifiable using a generic algorithm – for example they all have a code beginning with “X”. There are several downsides to this method – introduction of an entity block can affect the performance of a layout, particularly larger layouts, the algorithm will need to be recreated every time this method is to be used, and if requirements change down the line (for example if the coding changes) every data view using this method will need to be changed.

3.2.3 Algorithm Based on a flagging cube

Another option we can use is an algorithm based on a cube, this avoids the potential performance impact of an entity block and allows us to use a cube to flag any rows which shouldn’t have the scaling applied. This method means that we can have an admin screen for flagging which lines should be excluded, allowing us to use the same cube in multiple layouts; in the event of needing to amend the configuration we then only need to change it in one place in order to apply it to all affected layouts.

3.2.4 Algorithm Based on a scaling cube

An alternative, similar approach is to have the configuration cube actually contain the scaling factor, this could be used where you might want to toggle the scaling on a report, for example to show it in millions when looking at companywide figures but allow the user to switch it to show in thousands if they filter down to look at a particular area of the company which might have much smaller numbers associated. The scaling cube would need to be dimensioned by the different scaling factors to be made available (millions, thousands, actual) and the relevant numbers populated. This would require a bit more maintenance than the flagging cube approach but offers extra functionality should it be needed.

3.3 Which method to use?

If you’re only looking to display a handful of values, whose scaling requirements are determined by block and not by row, then you can probably make do with method 1, as that’s going to involve the least effort and, in this instance, gives you what you need.

In many instances however the requirements will be slightly more complex, in which case your best bet is likely to be options 3.2.3 or 3.2.4, typically the latter will only be necessary if the ability to toggle scale is a requirement, it requires more maintenance than 3.2.3 as a trade-off for the extra versatility.

Option 3.2.2 would rarely be used due to the hardcoded nature and the fact that it would only really make sense where the scaling requirements can easily be determined purely from the code, the potential performance impact and need to apply any modifications separately to each layout that uses it means that it’s unlikely to be your best option in most cases.