Amazon Quick Sight Hierarchy Filter reduziert Dashboard-Überfrachtung, schafft aber einen neuen Design-Kompromiss
Amazon hat am 30. September den Amazon Quick Sight hierarchy filter veröffentlicht, der mehrere zusammenhängende Dashboard-Steuerelemente durch ein aufklappbares Menü mit bis zu fünf Ebenen ersetzt. Die Änderung zielt auf einen bekannten Konflikt in der Business Intelligence: Leser möchten flexibel filtern, doch jedes zusätzliche Steuerelement erschwert die Navigation in einem Dashboard.
Das neue Steuerelement ermöglicht es Lesern, Beziehungen wie Region, Land und Stadt nachzuvollziehen, ohne separate Menüs durchsuchen zu müssen. Autoren können zudem Auswahlmöglichkeiten aus verschiedenen Ebenen kombinieren, darunter ein ganzes Land und eine Stadt in einem anderen Bereich. AWS zufolge ist die Funktion in jeder AWS Region verfügbar, in der Amazon Quick unterstützt wird.
Dabei handelt es sich weder um ein neues Analysemodell noch um eine Visualisierungs-Engine. Es ist eine konzentrierte Änderung der Benutzeroberfläche, die Komplexität von der Dashboard-Oberfläche in eine aufklappbare Baumstruktur verlagert. Damit steht der Amazon Quick Sight hierarchy filter der etablierten Praxis gegenüber, unabhängige Filter anzuzeigen, einschließlich kaskadierender Steuerelemente, die sich gegenseitig eingrenzen.
Die Veröffentlichung erhöht auch das Wettbewerbsniveau. Microsoft Power BI unterstützt bereits mehrere zusammenhängende Felder innerhalb eines Hierarchy Slicers. Amazon schließt eine sichtbare Interaktionslücke und fügt zugleich eigene Regeln für Auswahl, Suche, Geltungsbereich und Skalierung hinzu.
Amazon Quick Sight Hierarchy Filter ersetzt eine Reihe von Steuerelementen
Die unmittelbare Änderung ist einfach: Mehrere verbundene Filter können nun einen einzigen Platz auf einem Quick Sight-Dashboard einnehmen.
AWS kündigte die Funktion in seiner Ankündigung zum hierarchy filter vom 30. September an. Am 1. Oktober folgte eine detaillierte Produktvorstellung.
Das begleitende Beispiel beginnt mit sechs Dashboard-Steuerelementen. Vier davon repräsentieren geografische Dimensionen: Region, Sub-Region, Land und Stadt. Die übrigen Steuerelemente betreffen Segment und Produkt.
Dieses Layout bietet Lesern viele Wahlmöglichkeiten, beansprucht aber zugleich wertvollen Platz im Dashboard. Jedes geografische Steuerelement bringt eine weitere Liste, Bezeichnung und Interaktionsmöglichkeit mit sich. Leser müssen verstehen, wie die Felder zusammenhängen, bevor sie eine gültige Auswahlabfolge treffen können.
Der Amazon Quick Sight hierarchy filter verschiebt die zusammenhängenden geografischen Felder in eine Baumstruktur. Leser sehen zunächst die allgemeinste Ebene, etwa Region. Sie können eine Region aufklappen, um Länder anzuzeigen, und anschließend ein Land aufklappen, um Städte zu sehen.
Jede Auswahl grenzt den sichtbaren Zweig ein. Die Wahl eines Werts auf einer niedrigeren Ebene wählt auch dessen übergeordneten Pfad aus, sodass die Benutzeroberfläche die Beziehung zwischen diesem Wert und seinen umfassenderen Kategorien bewahrt.
Dieses Verhalten ist wichtig, weil unabhängige Filter eine fragmentierte Erfahrung schaffen können. Ein Leser könnte in einem Menü eine Region wählen, ein separates Ländermenü öffnen und anschließend nach einer Stadt suchen. Das Dashboard stellt zwar die Steuerelemente bereit, doch der Nutzer muss die Hierarchie selbst rekonstruieren.
Der neue Filter bildet diese Hierarchie direkt ab. Er kann bis zu fünf Dimensionsfelder enthalten, angeordnet von der allgemeinsten Kategorie bis zur detailliertesten. Geografische Felder sind nur ein Beispiel. Ein Unternehmen könnte Produktkategorie, Produktlinie, Produkt, Modell und Stock Keeping Unit verwenden.
AWS erlaubt außerdem Auswahlen aus unterschiedlichen Ebenen innerhalb desselben Steuerelements. Ein Leser kann einen breiten Knoten wie Japan auswählen und zugleich eine einzelne Stadt in einem anderen Zweig. Dadurch bleibt eine Flexibilität erhalten, die verloren ginge, wenn Nutzer auf Werte der Blattebene beschränkt wären.
Der Leitfaden zum hierarchy filter des Unternehmens unterscheidet dieses Steuerelement von kaskadierenden Filtern. Beide Ansätze führen Leser durch zusammenhängende Dimensionen, doch ihre Benutzeroberflächen unterscheiden sich.
Ein hierarchy filter verschachtelt den gesamten Pfad innerhalb eines Steuerelements. Kaskadierende Filter bleiben getrennte Steuerelemente, bei denen eine frühere Auswahl begrenzt, was in einem späteren Steuerelement erscheint.
Dieser Unterschied schafft die zentrale Spannung des Artikels. Amazon hat die Zahl sichtbarer Entscheidungen reduziert, jedoch nicht die zugrunde liegende Komplexität beseitigt. Stattdessen wurde diese Komplexität in eine kompaktere Interaktion überführt.
Die Änderung unterscheidet sich auch von visuellem Drill-down. Quick Sight ermöglicht Lesern bereits, in unterstützten Diagrammen durch Hierarchieebenen zu navigieren. Seine visuellen Drill-downs verfeinern ein ausgewähltes Diagrammelement, etwa beim Wechsel von einem Bundesstaat zu dessen Städten.
Der hierarchy filter arbeitet auf der Ebene der Dashboard-Steuerelemente. Je nach konfiguriertem Geltungsbereich kann er mehrere Visualisierungen oder ein gesamtes Dashboard mit mehreren Sheets ändern. Damit ist er ein Navigationsmechanismus für die Analyse und nicht nur für ein einzelnes Diagramm.
Dashboard-Autoren stehen unter Druck, Auswahlmöglichkeiten zu verdichten
Der hierarchy filter reagiert auf ein Oberflächenproblem, das mit zunehmenden Dimensionen, Sheets und Zielgruppen von Dashboards kostspieliger wird.
Business-Intelligence-Dashboards richten sich häufig an Leser mit unterschiedlichen Fragen. Eine regionale Führungskraft möchte möglicherweise einen gesamten Markt betrachten, während ein Filialleiter einen einzelnen Standort benötigt. Ein Produktverantwortlicher kann mit einer Kategorie beginnen und anschließend ein bestimmtes Modell untersuchen.
Um diese Wege zu unterstützen, müssen in der Regel Steuerelemente hinzugefügt werden. Jedes Steuerelement verlangt jedoch von Lesern, ein Feld zu erkennen, seine Werte zu verstehen und zu wissen, ob es von einem anderen Feld abhängt.
Dashboard-Autoren stehen daher vor zwei konkurrierenden Anforderungen. Sie müssen genügend Filter anbieten, um Erkundungen zu ermöglichen, und die Benutzeroberfläche zugleich für Leser verständlich halten, die die Analyse nicht selbst erstellt haben.
Der Amazon Quick Sight hierarchy filter begegnet diesem Druck, indem er niedrigere Ebenen ausblendet, bis sie relevant werden. Ein Leser sieht zunächst eine kleine Menge von Knoten der obersten Ebene statt jeder einzelnen Stadt, jedes Produkts oder jeder Abteilung.
Der Ansatz reduziert visuelle Unruhe, doch sein größerer Beitrag liegt in der Informationssequenzierung. Er präsentiert Auswahlmöglichkeiten in der vom Autor festgelegten Reihenfolge.
Diese Abfolge kann widersprüchliche oder verwirrende Kombinationen verhindern. Eine Stadt erscheint unter ihrem Land und ihrer Region, sodass das Steuerelement Kontext vermittelt, bevor der Leser eine Auswahl trifft.
AWS veranschaulicht dieses Verhalten mit einem Handelsdatensatz, der drei Regionen, acht Länder und vierzehn Städte enthält. Diese Zahlen sind überschaubar, machen aber das Navigationsmuster sichtbar. Der Wert wird deutlicher, wenn ein Produktionsdatensatz wesentlich mehr Elemente enthält.
Das Steuerelement kann außerdem ein gesamtes Dashboard filtern, wenn ein Autor seinen Geltungsbereich ändert. Quick Sight-Filter unterstützen ansonsten mehrere Geltungsbereiche, von einer Visualisierung bis zu allen zutreffenden Visualisierungen.
Die Dokumentation zum Filter Scope von Amazon weist darauf hin, dass Analysefilter in veröffentlichten Dashboards erhalten bleiben. Mehrere Filter der obersten Ebene werden gemeinsam mit AND-Logik angewendet, während gruppierte Filter OR-Logik verwenden können.
Dieses bestehende Verhalten erklärt, warum Konsolidierung wichtig ist. Die Verringerung der sichtbaren Anzahl an Steuerelementen reduziert nicht zwangsläufig die Zahl der auf die Daten angewendeten Bedingungen. Der hierarchy filter gibt diesen Bedingungen eine gemeinsame Benutzeroberfläche und eine explizite Eltern-Kind-Reihenfolge.
Autoren bestimmen weiterhin die Auswirkung jeder Auswahl. Eine Hierarchie kann auf eine Visualisierung, ein Sheet oder eine breitere Gruppe von Visualisierungen angewendet werden. Schlechte Entscheidungen beim Geltungsbereich können daher zu einem aufgeräumten Steuerelement führen, das sich unerwartet verhält.
Sheet-übergreifende Filterung erhöht den Einsatz. AWS führte vor diesem Hierarchie-Launch umfassendere cross-sheet controls ein, durch die eine Auswahl mehrere Sheets beeinflussen kann.
Der hierarchy filter baut auf dieser Grundlage auf. Eine einzelne Standort-Baumstruktur kann nun Leser durch ein Dashboard mit Übersichts-, Regional- und operativen Sheets führen.
Das ist besonders für Embedded Analytics nützlich, bei denen Dashboard-Fläche mit der umgebenden Anwendung konkurriert. Ein eingebettetes Dashboard kann weder von einer unbegrenzten Fläche noch von einem Leser ausgehen, der im BI-Tool geschult ist.
Eine kompakte Hierarchie verschafft Autoren zudem mehr Raum für jene Visualisierungen, die das eigentliche Argument tragen. Das Entfernen von drei Filterfeldern erhöht die analytische Tiefe nicht automatisch, kann aber den Oberflächenanteil verringern, der für die Bedienung des Dashboards reserviert ist.
Der Druck trifft Autoren, die filterlastige Analysen pflegen, am unmittelbarsten. Sie verfügen nun über eine native Option zur Konsolidierung, und Leser werden sie vernünftigerweise erwarten, wenn Dimensionen eine offensichtliche Hierarchie aufweisen.
Diese Erwartung schafft Arbeit. Autoren müssen bestehende Steuerelemente prüfen, Eltern-Kind-Beziehungen bestätigen, den Geltungsbereich festlegen und gespeicherte Auswahlen testen, bevor sie das alte Layout ersetzen.
Der Nutzen stellt sich daher nicht automatisch ein. Ein hierarchy filter verbessert die Nutzererfahrung nur, wenn die zugrunde liegenden Felder einen stabilen und verständlichen Pfad bilden.
Eine Hierarchie konkurriert nun mit vielen unabhängigen Filtern
Der zentrale Wettbewerb lautet nicht Amazon gegen einen anderen Anbieter. Es geht um eine geführte Hierarchie gegenüber der Freiheit separater Steuerelemente.
Unabhängige Filter bleiben die bessere Wahl, wenn Dimensionen keine natürliche Eltern-Kind-Beziehung teilen. Region und Produktkategorie können beispielsweise beide wichtig sein, ohne Teil derselben Hierarchie zu sein.
Separate Steuerelemente halten außerdem jede Dimension sichtbar. Das kann erfahrenen Lesern helfen, die mehrere Werte schnell ändern möchten, ohne wiederholt ein einzelnes Menü öffnen und darin navigieren zu müssen.
Eine Hierarchie funktioniert anders. Sie trifft eine redaktionelle Entscheidung darüber, wie Leser sich den Daten nähern sollen. Der Autor definiert den Pfad, und die Benutzeroberfläche ermutigt Leser, ihm von allgemein zu spezifisch zu folgen.
Das kann die Orientierung für gelegentliche Nutzer verbessern. Es kann jedoch auch jemanden verlangsamen, der den benötigten Wert auf einer niedrigeren Ebene bereits genau kennt.
Die Wahl wird beim Vergleich von hierarchy filters mit kaskadierenden Steuerelementen klarer. In einem kaskadierenden Design bleiben Region, Land und Stadt getrennt. Die Auswahl einer Region grenzt die Länderliste ein, während die Auswahl eines Landes die Städteliste einschränkt.
Dieses Layout zeigt die gesamte analytische Abfolge auf einen Blick. Es beansprucht jedoch mehr Platz und erfordert mehr Bewegung über das Dashboard hinweg.
Der Amazon Quick Sight hierarchy filter platziert dieselbe konzeptionelle Abfolge innerhalb eines aufklappbaren Steuerelements. Er opfert gleichzeitige Sichtbarkeit zugunsten von Kompaktheit.
Keines der Modelle ist universell überlegen. Die richtige Wahl hängt davon ab, ob Leser stärker davon profitieren, jede Stufe zu sehen, oder davon, die Dashboard-Oberfläche übersichtlich zu halten.
Das neue Steuerelement verändert auch, wie Autoren verfügbare Tiefe vermitteln. Fünf sichtbare Filter machen fünf Dimensionen deutlich erkennbar. Ein zusammengeklapptes Menü kann diesen Reichtum verbergen, bis ein Leser es öffnet.
Bezeichnungen und der umgebende Kontext werden daher wichtiger. Ein allgemeiner Titel wie „Standort“ verrät Lesern möglicherweise nicht, dass das Steuerelement Region, Land, Stadt und Filiale umfasst.
Darin liegt der eigentliche Mechanismus hinter dem Launch. Amazon beseitigt die Komplexität von Filtern nicht. Es verdichtet sie und verlässt sich auf hierarchische Offenlegung, um diese Komplexität beherrschbar zu machen.
Dieses Design kann besonders gut für Beziehungen funktionieren, die Nutzer bereits verstehen. Geografie, organisatorische Berichtslinien, Produktkataloge und Kontostrukturen weisen erkennbare Eltern-Kind-Muster auf.
Weniger zuverlässig wird es, wenn die Hierarchie künstlich ist. Ein Marketingteam könnte Kanäle, Kampagnen, Creatives und Zielgruppensegmente gruppieren, doch unterschiedliche Nutzer erwarten möglicherweise unterschiedliche Wege durch diese Daten.
Eine erzwungene Reihenfolge kann dann nützliche Kombinationen verbergen oder eine Beziehung nahelegen, die der zugrunde liegende Geschäftsprozess nicht unterstützt. Das Dashboard wirkt aufgeräumter, wird aber konzeptionell enger.
Autoren sollten zudem Filterung und Exploration innerhalb eines Visuals voneinander trennen. Ein Hierarchiefilter verändert, welche Datensätze innerhalb seines Geltungsbereichs verfügbar bleiben. Ein Drilldown in einem Diagramm verändert dagegen die angezeigte Detailtiefe innerhalb eines ausgewählten Visuals.
Die Kombination beider Ansätze kann wirksam sein. Ein Leser könnte das Dashboard auf eine Produktfamilie filtern und anschließend innerhalb eines Diagramms die monatliche Entwicklung detaillierter untersuchen.
Die Kombination kann Leser jedoch auch verwirren, wenn der aktive Filterstatus nicht offensichtlich ist. Ein Diagramm kann Daten scheinbar auslassen, weil eine übergeordnete Auswahl im kompakten Filter weiterhin aktiv ist.
Deshalb sollte der Launch anhand des Nutzerverhaltens beurteilt werden, nicht anhand der Dichte der Werkzeugleiste. Weniger sichtbare Bedienelemente sind nur dann nützlich, wenn Leser den aktuellen Zustand verstehen und ihn ohne Reibung ändern können.
Für Teams, die Dashboards auf Grundlage von Besprechungsnotizen, Anforderungen und Nutzerforschung erstellen, sollte dieses Verhalten gemeinsam mit der Analyse dokumentiert werden. Ein durchsuchbarer Produkt-Workflow kann Teams dabei helfen, festzuhalten, warum eine Hierarchie und ihr Geltungsbereich gewählt wurden.
Die zentrale Entscheidung lautet nicht, ob das neueste Bedienelement eingesetzt werden soll. Entscheidend ist, ob ein vorgegebener Pfad dazu passt, wie die vorgesehene Zielgruppe Fragen stellt.
Das kompakte Bedienelement hat Grenzen bei Suche und Skalierung
Der Hierarchiefilter reduziert sichtbare Unordnung, doch seine Einschränkungen können Reibung innerhalb des Menüs wieder einführen.
Die erste Einschränkung ist strukturell. Ein Hierarchiefilter unterstützt höchstens fünf Ebenen. Das reicht für viele geografische, organisatorische und produktbezogene Pfade aus, doch nicht jede Unternehmenstaxonomie passt in diese Grenze.
Autoren mit tieferen Strukturen müssen bei fünf Ebenen stoppen, Felder zusammenführen oder einige Dimensionen in separaten Bedienelementen belassen. Jede dieser Optionen verändert, wie Leser die Hierarchie interpretieren.
Der Filter akzeptiert außerdem Dimensionsfelder statt Kennzahlen. Text-, numerische Dimensions- und Boolean-Felder können als Ebenen dienen. Kennzahlen wie Sales oder Quantity hingegen nicht.
Diese Beschränkung ist logisch, da eine Hierarchie kategoriale Beziehungen beschreibt. Dennoch benötigen Autoren für Schwellenwerte, Bereiche und Leistungskennzahlen einen anderen Filtertyp.
Das Suchverhalten führt zu einem sichtbarer werdenden Kompromiss. Das Suchfeld oben in der Hierarchie durchsucht nur die oberste Ebene. Es durchsucht nicht jeden darunter verschachtelten Wert.
Ein Leser, der nach einer Stadt sucht, kann den Stadtnamen daher nicht unbedingt in das obere Suchfeld eingeben und direkt dorthin springen. Zunächst muss der Leser den relevanten Zweig öffnen oder erweitern.
Untere Ebenen können eigene Suchfelder bereitstellen. AWS zufolge erscheint eines, wenn eine Ebene mehr als 10 eindeutige Werte enthält.
Die Oberfläche verändert sich erneut, wenn eine Ebene mehr als 1.000 eindeutige Werte enthält. Dann zeigt das Bedienelement nur ein Suchfeld an, statt die Werte aufzulisten.
Dieses Design verhindert, dass ein enormes Menü den Leser überfordert. Es ersetzt jedoch das Durchsuchen durch Erinnern. Nutzer müssen genug vom Namen eines Werts kennen, um danach suchen zu können.
Der Unterschied ist bei Datensätzen mit uneinheitlichen Bezeichnungen, Abkürzungen oder unbekannten Kontonamen wichtig. Eine kompakte Hierarchie kann schwache Stammdaten nicht beheben.
Nullwerte bringen einen weiteren Aspekt ins Spiel. Autoren können wählen, wie Nullwerte die in Visuals angezeigten Zeilen beeinflussen, doch diese Wahl steuert nicht, wie Nullwerte innerhalb des Hierarchie-Bedienelements selbst erscheinen.
Dieser Unterschied sollte getestet werden, da Leser einen leeren Hierarchieknoten als fehlende Daten, nicht verfügbaren Zweig oder Fehlfunktion interpretieren könnten.
Auch der Auswahlstatus kann Autoren bei der Wartung überraschen. Das Umordnen von Hierarchiefeldern löscht bereits im Filter gespeicherte Auswahlen.
Eine scheinbar kleine Neugestaltung kann daher den Standardzustand verändern, den Leser erleben. Teams sollten die erwarteten Auswahlen vor einer Anpassung der Feldreihenfolge dokumentieren und das erneut veröffentlichte Dashboard anschließend validieren.
Die Hierarchie übernimmt außerdem den übergeordneten Status. Wird ein Wert einer unteren Ebene ausgewählt, markiert sie automatisch dessen übergeordnete Kette; breitere Knoten werden bei Bedarf als teilweise ausgewählt angezeigt.
Dieses Verhalten bewahrt den Kontext, doch eine Auswahl über mehrere Ebenen kann den resultierenden Datensatz schwerer zusammenfassen lassen. Die Auswahl eines ganzen Landes neben einer Stadt erzeugt einen bewusst ungleichmäßigen Vergleich.
Diese Flexibilität ist für Ad-hoc-Analysen wertvoll. In einem gemeinsam genutzten Dashboard kann sie riskant sein, wenn Leser davon ausgehen, dass jeder ausgewählte Zweig dieselbe Aggregationsebene repräsentiert.
Autoren sollten Titel, Untertitel und visuelle Beschriftungen unter gemischten Auswahlen testen. Ein Diagramm mit der Bezeichnung „Sales by City“ wird irreführend, wenn der Filter zusätzlich ein ganzes Land umfasst.
Der Geltungsbereich bleibt eine weitere Quelle der Unsicherheit. Die anfängliche Filterkonfiguration gilt nur für ein Visual, sofern der Autor dies nicht ändert. Eine oben prominent dargestellte Hierarchie kann daher global wirken, obwohl sie nur einen Teil des Dashboards beeinflusst.
Diese Diskrepanz ist schädlicher als sichtbare Unordnung, weil sie die Bedeutung einer Analyse verändern kann, ohne den Leser darauf hinzuweisen. Eine aufgeräumtere Oberfläche erhöht die Bedeutung klarer Rückmeldungen zum Status.
Das skeptische Fazit ist einfach. AWS hat gezeigt, wie die Funktion arbeitet, aber keine unabhängigen Belege veröffentlicht, dass Leser Filteraufgaben schneller abschließen oder weniger Fehler machen.
Die Ankündigung beschreibt weniger Schritte und geringere Verwirrung als Vorteile. Diese Aussagen sind plausibel, doch ihr Wert hängt von der Hierarchietiefe, der Anzahl der Mitglieder, der Datenqualität und der Vertrautheit der Zielgruppe ab.
Unternehmen sollten erfolgreiche Aufgabenabschlüsse, die Zeit bis zu einer Zielansicht, Filterzurücksetzungen und Supportanfragen messen, bevor sie das Redesign als Verbesserung bezeichnen.
Power BI zeigt, dass Hierarchiefilter eine Basiserwartung sind
Amazons Release verbessert Quick Sight, doch Hierarchiefilter existieren bereits als erkennbares Muster in konkurrierenden Business-Intelligence-Produkten.
Microsoft Power BI ermöglicht Berichtsautoren, mehrere verwandte Felder zu einem Slicer hinzuzufügen. Leser können Ebenen mit Chevron-Symbolen erweitern und reduzieren, während Autoren ein Dropdown-Menü oder eine vertikale Liste wählen können.
Die Dokumentation zum Hierarchie-Slicer von Microsoft beschreibt außerdem Formatierungsoptionen für Titel, Einrückungen sowie Symbole zum Erweitern oder Reduzieren.
Dieser Vergleich ordnet Amazons Launch ein. Quick Sight schafft keine vollständig neue Interaktionskategorie. Es ergänzt eine native Umsetzung eines Musters, das Käufer von Business-Intelligence-Lösungen bereits kennen.
Das ist für Organisationen bei der Werkzeugbewertung relevant, weil kleine Lücken in der Oberfläche im großen Maßstab teuer werden. Fehlt ein gewünschtes Bedienelement, müssen Autoren möglicherweise mehrere Komponenten hinzufügen, das Dashboard neu gestalten oder eine Umgehungslösung entwickeln.
Ein nativer Hierarchiefilter reduziert diesen Druck. Er ermöglicht Quick Sight-Autoren, einen vertrauten, aufklappbaren Baum bereitzustellen, ohne mehrere Bedienelemente auf einem Sheet einsetzen zu müssen.
Amazons Version betont gemischte Ebenenauswahlen und ein Maximum von fünf Dimensionen. Die Dokumentation zieht außerdem eine klare Grenze zwischen einem Hierarchiefilter und separaten kaskadierenden Filtern.
Power BI bietet rund um seinen Hierarchie-Slicer ein breiteres Spektrum an Darstellungsoptionen. Microsoft dokumentiert konfigurierbare Einrückungen und alternative Symbole zum Erweitern oder Reduzieren, Funktionen, die in Amazons Launch-Material nicht hervorgehoben werden.
Der Vergleich sollte nicht zu einem Produkturteil ausgeweitet werden. Filterung ist nur ein Teil einer BI-Plattform, und Organisationen wählen Werkzeuge anhand von Datenzugriff, Governance, Einbettung, Verwaltung, Visualisierung und bestehenden Cloud-Verpflichtungen.
Dennoch beeinflusst Funktionsgleichheit in der Oberfläche die tägliche Nutzung. Dashboard-Leser erleben Bedienelemente weitaus häufiger, als sie ein Architekturdiagramm betrachten.
Die Einführung des Amazon Quick Sight-Hierarchiefilters erhöht außerdem den Druck auf interne Analytics-Teams, nicht nur auf Anbieter. Sobald eine kompakte Option existiert, ist ein Dashboard mit zahlreichen verwandten Filtern schwerer zu rechtfertigen.
Autoren müssen erklären, wann unabhängige Bedienelemente beabsichtigt sind. Das ist gesund, weil es Dashboard-Design von Gewohnheit hin zu expliziten Leserbedürfnissen verschiebt.
Die Wettbewerbsfrage betrifft daher weniger das Zählen von Funktionen als die Umsetzung. Kann Amazons Bedienelement bei tiefen Hierarchien, gemischten Auswahlen, Nullwerten und Feldern mit hoher Kardinalität verständlich bleiben?
Die dokumentierten Einschränkungen von Microsoft erinnern daran, dass Hierarchieoberflächen Probleme aus dem zugrunde liegenden Modell übernehmen. Die Hinweise nennen Komplikationen bei unregelmäßigen Hierarchien, in denen einigen Mitgliedern Werte auf Zwischenebenen fehlen.
Amazons eigene Regeln zu Nullwerten und Suche weisen auf ähnliche praktische Grenzen hin. Ein Baum kann saubere Beziehungen elegant darstellen, doch unregelmäßige Strukturen erfordern sorgfältige Tests.
Diese Wettbewerbsbasis verändert auch die Erwartungen von Käufern an eingebettete Dashboards. Ein Nutzer, der daran gewöhnt ist, Kategorien in Power BI zu erweitern, erwartet ein entsprechendes Verhalten innerhalb einer Quick Sight-Anwendung.
Amazon hat nun eine direkte Antwort auf diese Erwartung. Die verbleibende Frage lautet, ob Autoren die Funktion konsistent genug einsetzen, damit Leser der Interaktion vertrauen.
Was nach dem Launch des Hierarchiefilters zu beobachten ist
Die nächste Phase hängt von Belegen für die Akzeptanz, breiterer Interaktionsunterstützung und Amazons Reaktion auf die aktuellen Grenzen des Bedienelements ab.
Das erste Signal ist die Akzeptanz durch Autoren in bestehenden Quick Sight-Dashboards. AWS hat die Funktion überall verfügbar gemacht, wo Amazon Quick unterstützt wird, doch Verfügbarkeit zeigt nicht, ob Teams etablierte Bedienelemente ersetzen werden.
Die Akzeptanz wird in Dashboards mit klaren geografischen, produktbezogenen oder organisatorischen Hierarchien am aussagekräftigsten sein. Nutzen Autoren das Bedienelement vor allem in neuen Demonstrationen, bleibt der Launch eine nützliche Option statt einer bedeutenden Designveränderung.
Die stärksten Belege würden aus gemessenen Ergebnissen für Leser stammen. Teams sollten die alten und neuen Layouts mit denselben Analyseaufgaben vergleichen.
Wenn Leser eine Zielposition schneller erreichen, weniger ungültige Kombinationen erstellen und Filter seltener zurücksetzen, gewinnt Amazons geführtes Modell an Unterstützung. Wenn Nutzer Schwierigkeiten haben, Werte auf unteren Ebenen zu finden, hat die kompakte Oberfläche die Reibung lediglich verlagert.
Das zweite Signal betrifft Produktverbesserungen bei Suche und Sichtbarkeit des Status. Eine Suche nur auf oberster Ebene ist in kleinen Hierarchien handhabbar, begrenzt jedoch den direkten Zugriff auf tief verschachtelte Werte.
Ein zukünftiger Suchmodus, der alle Ebenen umfasst, würde das Bedienelement für große Kataloge stärken. Er müsste zudem genügend Abstammungsinformationen anzeigen, damit Leser doppelte Namen unterscheiden können.
Verbesserte Zusammenfassungen gemischter Ebenenauswahlen wären ebenfalls wichtig. Wenn Leser einen breiten und einen engen Knoten wählen, müssen Dashboard-Titel und Beschriftungen des Bedienelements diesen ungleichmäßigen Geltungsbereich vermitteln.
Wenn Amazon diese Fähigkeiten ausbaut, wird der Hierarchiefilter auch jenseits sauberer Demonstrationsdatensätze leichter nutzbar. Bleiben die aktuellen Regeln bestehen, benötigen Autoren für komplexe Analysen ergänzende Beschriftungen und Schulungen.
Das dritte Signal ist, wie konkurrierende BI-Produkte ihre Hierarchie-Bedienelemente weiterentwickeln. Power BI bietet bereits ein ausgereiftes Slicer-Muster, sodass Amazon über die Integration mit dem Filterumfang von Quick Sight, eingebettete Analysen und sheetübergreifendes Verhalten konkurrieren muss.
Wettbewerber könnten mit einer besseren ebenenübergreifenden Suche, flexiblerer Hierarchietiefe oder klareren Auswahlzusammenfassungen reagieren. Diese Änderungen würden aus einer kleinen Oberflächenfunktion einen weiteren Differenzierungspunkt bei der Benutzerfreundlichkeit von Dashboards machen.
Der Launch sollte Teams außerdem dazu anregen, den Einsatz kaskadierender Filter zu prüfen. Separate Bedienelemente bleiben wertvoll, wenn Leser jede Stufe sichtbar benötigen oder Dimensionen nur lose miteinander verbunden sind.
Jede Kaskade zu ersetzen, würde das Design schwächen. Der bessere Test lautet, ob die Hierarchie den analytischen Pfad klarer vermittelt als die Bedienelemente, die sie entfernt.
Für Entwickler und Unternehmenskäufer verdient der Amazon Quick Sight-Hierarchiefilter Aufmerksamkeit, weil er eine häufige Interaktion verändert. Leser verwenden Filter immer dann, wenn sie ein operatives, finanzielles oder kundenbezogenes Dashboard eingrenzen.
Für Wissensarbeiter reicht die Erkenntnis über Business Intelligence hinaus. Kompakte Oberflächen funktionieren, wenn sie Strukturen genau dann sichtbar machen, wenn sie relevant werden. Sie scheitern, wenn die Verdichtung Zustände, unregelmäßige Daten oder Optionen verbirgt, die Nutzer vergleichen müssen.
Amazon hat den Mechanismus bereitgestellt. Die nächste Frage ist messbar: Werden Leser die richtigen Daten mit weniger Fehlern erreichen, oder tauschen Autoren lediglich sichtbare Unübersichtlichkeit gegen versteckte Navigation aus?
