Build1 publisher2 min readPublished Updated
Amazon Quick Sight folds up to five filter levels into one hierarchy control
Amazon Quick Sight's new hierarchy filter puts up to five related fields, such as Region down to City, into a single dashboard control. Readers get one control to scan in place of several, and the dashboard author sets the drill order in advance.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Authors turn an ordinary filter into one by picking Hierarchy filter under ADVANCED FILTER in the Filter type menu of the Edit filter panel.
- The fields need not be geographic, since AWS says any parent-child pair works, with Product Category to Product as its example.
- AWS's sample layout starts with six filters, four of them geographic (Region, Sub-Region, Country, City) plus Segment and Product.
- The walkthrough dataset holds three Regions, eight countries and fourteen cities arranged in a three-level geographic hierarchy.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Collapsing the geographic filters takes AWS's six-control example toolbar down to three, and the case for doing it is strongest where the bottom level runs to hundreds of values.
- capability One selection can hold a whole country and a single city somewhere else, so a cross-level question no longer needs its own control for each level.
- constraint Every reader drills in the order the author chose, so readers whose questions start at City take the longer route down from Region.
- cost A wrong field order is expensive to fix after launch, because reordering clears selections readers have already saved on the filter.
Quick Sight labels the new filter type "Organize and present filter values in a hierarchical tree control." [8] The label is accurate. A reader opens the control on its top level, which in AWS's example is a short list of Regions. Each selection narrows the list beneath it [5]. The parent-child mapping lives in the filter, so the reader does not need to know which country belongs to which Region [6].
That mapping has to come from the data, and a tree gives each child exactly one parent. AWS's post does not show what the control does when a value sits under two parents, such as one city name used in two countries. I would test that case on a production geography table before retiring the independent filters the hierarchy replaces.
The clutter argument depends on scale. AWS describes the problem as hundreds of cities shown upfront [5]. Its walkthrough dataset has fourteen [11]. Fourteen cities fit on one screen without help. For the saving to carry over to another dashboard, that dashboard's bottom level has to be long enough that a flat list slows readers down. The demo also uses only three of the five levels the filter allows [2].
The part of the design I would credit most is that one selection can span levels [4]. The trade-off is that the author fixes the path. Fields are arranged from broadest to most detailed, and that order becomes every reader's drill-down path [12]. I think a fixed path is the right default for geography and product catalogs, where each city or product has a settled parent. It suits less well a reader whose question starts at the bottom level, because the path AWS describes starts at the top [5].
What to watch
- How the hierarchy filter handles a child value under two parents, such as one city name used in two countries, once authors run it on production data.
- Whether AWS documents how a cross-level selection like Japan plus New York combines with a dashboard's other, independent filters.