Comments archive

The pages of this comments archive list all public comments on the latest version of the IBCS® Standards in chronological order.


I’m pretty sure that there are certain scenarios where it could be usefull to have outliers not only within relative deviations but also within absolute deviations or even regular charts(see also comments in UN 5.3) as they also can get unreadable if one measure is too high.

Examples for outliers would be:
– Vacation pay or sick pay in a chart for labor costs per month
– Additional payments for heating, power and water in a chart for operating costs per month.

View comment inline

Hello Michael,

The category width and aggregation level problem not only arises when we deal with one indicator differentiate by regions and business units etc., but also when dealing with KPIs where we have very wide data ranges as shown in the chart below.

As we can see category and bar width applies not only to the time dimension, but is also used for differentiating basic measures, calculated measures, ratios etc. That’s why it could be difficult to use category width for visualizing aggregation hierarchies.

As one of the most important premises of IBCS standards is the “True view” even extreme values have to fit within the chart. Following this leads to using “winding columns/bars” (CH 2.2). The other way is applying scaling indicators (CH 4). A third way could be “normalizing” values to a base “100”, which is used sometimes in bullet charts and specially for comparing values. (see

Best regards,

View comment inline

Hi Rolf, hi all,

I’m facing a similar issue in my daily business and would appreciate a solution to provide a visual differentiation between multiple aggregation levels or units used on a single report. For example a dashboard showing turnover by different categories whereas a meaningful scale can only be applied by using million EUR for the first graph and thousand EUR for a second graph. Same issue may occur by comparing turnover and revenue for business with really low margin (e.g. stock exchange turnover vs. trading fee).

Today the category and bar width is only used to differentiate between the time dimensions. I suggest to extend the usage of the widths to a more generic definition: The width can be used to identify the level of aggregation. The higher the level the wider the category segments. Whereas aggregation can be the aggregation over time, the aggregation along a hierarchy (e.g. product hierarchy) or along a unit (e.g. metric system).

For the time dimension it still works because time is a standard aggregation hierarchy. But, with the more generic definition it could also be used on the Y-axes to differentiate between category aggregation levels (drill from highest product group down to single item) or to indicate the usage of different units (for example millions for turnover and thousands for revenue in two graphs on a single report).

A more generic definition could also enhance the visualization according to UN5.2 scaling indicators.

One additional thought: Today, the unit is typically mentioned once in the report title. In case of using different units on a single report we might also think about a standard visualization/position to show the graphs unit.

What do you think?

Best regards, Michael

View comment inline

Thanks for starting this legends discussion – especially for interactive applications.

I once had a clear opinion regarding legends: there is no need for them.
But our clients convinced me, that there is a need for legends (sometimes).
So we build a – cost free – component to meet these expectations 😉

First I would like to distinguish between legends for data series and legends for categories.

If you show different measures – data series – in several charts on one screen, it’s a good idea to label these measures directly at the chart elements. If there is not enough space on the dashboard, than the chart title could be used. On the other side labeling all category elements directly could end in a mass, if there are to many or to small chart elements which is often the case with stacked bar/columns charts.

As we suppress labels for small elements, our clients asked for a legend component: their dashboard addressees wanted to know what they are looking at.

Of course small multiples are a good alternative but they need much more space.

And yes, the lowest stack at the base line is the only series which could be read easily against the overall value.

Here is our idea: By clicking at one stack series this series is displayed at the bottom line of the chart and it’s always labeled.

But I also agree to Markus to place a legend a little bit offset – in the same fixed(!) order as the stacked values.

Second my thoughts on an interactive legend on mouse-over.

As Raphael pointed out, most BI tools show the value and even the category label in a so called tool tipp when hovering over one chart element. This helps to understand what is shown – even in a quite detailed manner. But it doesn’t help to get a quick overview.

If you are not able to distinguish the formats for actual, budget, forecast or other values for example, you need a legend. Legends consume real estate and as they are even more things to explain to a dashboard user, I suggest to place a small question mark or an “i” for information as an icon in the dashboard. By hovering over this icon a pop-up opens up and all necessary information on how to use the dashboard and interpret the data is presented.

One last thought: Why not using legends only temporarily? If dashboards are designed consistently and well structured, I don’t think there is a need to show legends always. 🙂

View comment inline

First of all I highly appreciate that Jürgen articulated the issues arising with certain chart types, especially in an “automated” environment with BI tools.

Re “mouse-over” legends: I’m not really happy with the idea to skip the legend completely. But mouse-over could be a good thing to show the legend (say label) especially for the very small items for which you typically don’t have enough space to put the label besides of it. In addition to the label, most BI tools already today manage to show the data value of the specific segment which is helpful for small values too (for which you don’t print the label on the bar or column element directly).

View comment inline

Jürgen, I like your comprehensive statement on the matter of legends 🙂

Also, I do endorse your simple but effective recommendation to choose a simpler chart type in cases where stacked bars/columns or intersecting lines start to make trouble with the legends. In many of these cases, small multiples might be a good option.

Furthermore I would like to share my thoughts on two aspects, based on personal experience and feedback that I received over the years.

1. Worthwhile exceptions
In some cases I find it worthwhile to place the legend items a little bit offset from their normal position to allow for small values in a stacked column. This can be done automatically by shifting the label position just enough to avoid the overlapping. A small line connects the offset legend item with the corresponding column segment.

I would use this kind of ‘advanced’ legend, when the data fulfil the conditions you described in general (max 5 series etc.) but cause problems in only some instances, e. g. for certain countries or products.

Of course, a dynamically generated segment ‘other’, dependent on the proportion between the currently filtered data series would be a great alternative.

2. Interactive legend on mouse-over
Especially for the use in interactive dashboards there would be another option for legends in charts with high information density, such as stacked columns with multiple data series. We could abandon the ‘fixed’ legend and replace it with a ‘mouse-over-only’ solution. This means that the user will have to point on a data point to learn which series the point belongs to. At first glance this might sound a little hard to do but I think it’s really intuitive. Eventually, dashboards are all about working with data interactively, not reading a printout.

The mouse-over legend might also offer a solution for other chart types that are very useful but only hard to label, such as tree maps or certain details in small multiples.

I’m curious to learn about other opinions on the mouse-over idea. You might conceive it as divergent from the standard, because there wouldn’t be any legend if the dashboard is viewed as a still image. On the other hand it would be coherent with the interactive nature of a dashboard.

View comment inline
Jürgen Faisst

Motivation for integrated legends
There are two main reasons, why IBCS suggests to integrate legends into charts and not position them externally:

Legibility: Better and faster legibility, because you do not have to look-up but see the label next to the data series

Color: No need to spoil color (which is the most valuable visual means) for minor things such as linking a label to a data series.

Challenges in visualizing integrated legends in charts with stacked columns or bars
There are two main situations when the visualization of integrated legends in charts with stacked columns or bars becomes challenging:

Small or missing segments: Some segments of the last column or the first bar (used for labeling) are very small or even missing, even harder if there are also missing segments in the last but one column or first but on bar respectively. In this case we do not know where to write the labels.

Scroll bars: The chart uses scroll bars because not all categories fit into the given space. In this case, the integrated labels tend to ‘jump around’ when scrolling.

Problem abstraction
Both challenges result from the fact, that the chart type had to be selected without knowing the data yet. This is typical for interactive analytic applications such as dashboards, whereas almost no such problems occur in message based reporting on a specific (data) situation.

We can see a lot of similar challenges when using other chart types. Look at a line chart with 10 intersecting lines. Labeling is a challenge, but the bigger problem is, that the chart is completely useless, because we do not see anything.

So what I want to say is: If we run into visualization challenges like the ones described above, then the question is, whether the selected chart type is best suited to visualize the specific data constellation. Instead of trying to optimize the visualization of a chart, which in the specific data constellation is of limited use, we should think of methods for applying better suited visualization options.

When are stacked columns or bars a good choice?
Stacked columns and bars are best suited for the following two situations:

a The numbers of segments are limited to a maximum of five, where the different segments have a similar size and low volatility (e.g. staff of an international conglomerate by global regions).

b The user is interested in the evolvement of one specific segment of a group (displayed in the lowest stack) in relation to the overall group. Example: We are interested in the development of the number of employees in USA and the overall number of employees. All other countries are of minor interest.

In all other situations stacked columns or bars do not provide a lot of insight. Let’s face it: Most applications of stacked columns or bars are not covered by the two use cases mentioned above. They have just been implemented, because it is practical to visualize hierarchical structures in stacked columns or bars from a technical perspective, not from an analytical perspective.

So here is my first suggestion: Don’t use stacked columns or bars in dashboards unless the application fits into one of the use cases above.

Stacked columns or bars in a dynamic environment
In a dynamic environment we still can run into the visualization challenges mentioned above. However, I think, that a good visualization software should detect, that a specific visualization does not provide insight in a specific data constellation and should be able to suggest alternatives. In the case of stacked columns or bars, the system could suggest various improvements depending on the data constellation:

If there are small or missing segments the system could
+ suggest to show all data series on a trellis
+ suggest to aggregate small data series and data series with missing values to an ‚Other’ position
+ allow for dragging one data series to the bottom of the columns or bars and aggregating the rest
+ use light colors only for those data series that cannot be labelled directly (e.g. because of missing values)

If there is a need for scroll bars the system could suggest to
+ sort bars (not applicable with columns) and show only the top x elements together with a ‚Rest‘ position which you can drill down
+ add an ‚average‘ bar or column which remains fixed, i.e. does not change when scrolling.

Running into visualization problems in dynamic analytic environments is not limited to the problem of labeling legends in stacked columns or bars. The following suggestion will help to solve this kind of problems:

Chart selection: The architect of a dashboard should choose the chart type best suited for the specific purpose of the analysis (which only in rare cases will be stacked columns or bars).

Usability: The software should allow the user to easily change inappropriate visualizations into better ones.

Heuristics: The software could even support the user by providing intelligent heuristics detecting inappropriate visualizations such as too much intersecting lines in line charts (‘spaghetti’), missing values in stacked bars or columns, or scroll bars in column charts and bar charts, and suggesting alternative visualization options.

View comment inline

Hi Jens –

you mentioned this idea in our training of last week. Yes, this could be a solution.

But there is an important argument against it:

We use the horizontal X-axes to represent the time dimension. Therefore it makes sense to differentiate the different time periods by different category width – see above. Yearly X-categories are wider than monthly X-categories etc..

The vertical Y-axes have no relation to time – there we show values for one period or one point of time. So time periods are only one of several dimensions which might be necessary to distinguish and to visualize in bar charts – others could be currency, products, countries, etc. But why using the width of the Y-category for time? The vertical Y-axis has nothing to do with time.

As for now, the IBCS have no suggestion for different category width at the Y-axes. So far there is only one. I suggest that we wait for more ideas. May be, we will find another, hopefully more intuitive application for this. Different widths for Y-categories are a very strong visual aid – and we can use it only once…

Let us see what other people think about this subject.

View comment inline

It might be helpful if the category width is not only differentiated in column charts but also in bar charts. By unifying the category width of column and bar charts it will be easier to understand to which time period the given data in a bar chart is related. In a Dashboard environment it will help to recognize in which drill down level the reader is currently in.

View comment inline

Daniel –
I am not sure whether I understand the terms “multiple structure chart” and “structure elements” correctly. Do you mean that you have a fixed “analysis setup” of certain measures such as sales, profitability, etc. on one page — and you use this fixed analysis setup to compare and report different markets, countries, or clients?
If this is the problem we suggest to use icons for the large number of elements in the respective structure dimensions – see structure dimensions. Colors would not be a good choice because you would probably not find enough distinguishable colors.

View comment inline