M
Mark Tarry
What I'm trying to do
Render the distribution of answers to a Likert-scale survey question as a bar chart — one bar per point on the scale, in scale order (for example "Never / Rarely / Sometimes / Often / Always"). The bars are produced by grouping entities on a relation, and the target blueprint carries an explicit
display_order
number property giving the intended position of each option.
What happens instead
bar-chart
always orders its bars by value, largest first. There appears to be no way to override this: the widget schema exposes
type
,
title
,
blueprint
,
property
,
dataset
,
emptyStateText
,
icon
,
description
and
segmentTableViewConfig
, and the
sortSettings
available inside
segmentTableViewConfig
configures a table view rather than the chart axis.
Why size-ordering is a problem for ordinal data
For a categorical breakdown, sorting by size is a sensible default — it puts the biggest category first. For an
ordinal
scale it removes the only information the chart shape carries, because the result is a descending staircase regardless of the underlying data:
| Underlying distribution | Counts in scale order | Rendered |
| --- | --- | --- |
| Polarised — people at both extremes | 5, 1, 0, 1, 5 | 5, 5, 1, 1, 0 |
| Converged — people clustered in the middle | 1, 2, 6, 2, 1 | 6, 2, 2, 1, 1 |
Both render identically in shape. Worse, the polarised case puts its two opposite extremes side by side as the two tallest bars, which reads as a consensus cluster — the opposite of what the data says. Telling these two cases apart is usually the entire reason for charting a distribution rather than reporting a mean.
What I'd like
Any one of these would solve it:
  • an explicit sort option on the widget, e.g.
    sortBy
    accepting a property of the grouped-by entity (such as
    display_order
    ) with
    asc
    /
    desc
  • an option to preserve the natural order of the grouped-by entities rather than sorting by value
  • the ability to supply an explicit ordered list of group keys, with bars rendered in that order
The first is the most useful, since the ordering property already exists on the blueprint.
Workaround in use
table-entities-explorer
, grouped by the same relation and sorted on
display_order
ascending. It gives correct scale order and the group headers carry the counts, so the data is right — but it is a table where a chart belongs, on a dashboard that is otherwise all charts, and it loses the at-a-glance shape that made a chart worth having.