Comments archive

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


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