I have a web app that builds and displays a bar chart based on dollar amounts. A typical graph looks something like this:

As you can see, the layers at the bottom of the graph have dollar amounts that are too small to show their labels without them overlapping.

What's the best way to compensate for this so that the bottom of my graphs are easier to read?

Things I've thought of:

• Set up a minimum layer height so that the labels can't overlap. This looks the best but requires me to squish the remaining layers to make everything fit and so the graph is no longer accurate.

• When a layer is too short, stagger the labels so they don't overlap. This is better than them overlapping but still doesn't look great IMO.

• Remove the labels altogether and place them in a separate key/legend based on color. This is a clean solution but I already have the labels for the vertical slices separated into a key and I'm worried that the more I remove from the actual graph, the harder it is to interpret and therefore loses some of its value.

If it is absolutely necessary to see all the amounts in detail all the time you could go with a variation of your second solution but still keep the figures in one column. like this

Alternatively you could implement something like a magnifiyng glass to show the small amounts. I first thought about tool tips on hover but a amount could be so small, that the height of an amount is just one pixel an therefore not easy to hover over.

You have several visualization problems to solve in one graph. How are the users interacting with this?

Your question is focused mostly on labels, however, you also mentioned showing when an element is being split among several entities for payment.

So you have a stacked bar - like graph doing some heavy lifting.

Considering what you want the user to understand, you might consider altering the visualization type.

1. Consider a table for comparative values, and ability for sort and drilldown.

There are some tradeoffs (such as maybe more reading than a visual gestalt), but it brings data forward in a sortable fashion, and can show small % categories w/o eyestrain or interpretation.

Summary tables can:

• Show totals (the summary at bottom, so users know the total, if that's important)


• Show parts of the whole: the % column allows users to see relative values


• Split payments by category (instead of vertical lines the user has to see in small volume categories, just label the category, and allow for hover details)


• Sort for quick comparison


• Scale: As more categories are added you can add additional rows


• Display labels: your current labels still force the user to look for what color goes with which category

Is your visualization part of a larger dashboard?

If it is, you could put color legends in the table itself, to relate to other visualizations in close proximity:

2. Or, try a horizontal bar chart.

In the stacked area example, users have to use height to see magnitude comparison at a glance.

With a horizontal chart, you can take advantage of humans ability to assess values by length.

from Show me the Numbers, by Stephen Few (pg 94):

Visual perception is highly tuned for seeing differences among the lengths of objects that share a common baseline but not well attuned for discerning differences among 2-D areas.

I don't know if I truly understand your use case, but it seems that parsing categories, their magnitude, labels, and the need to indicate split payments might warrant experimenting with a different visualization type.