Il filtro gerarchico Amazon Quick Sight riduce il disordine nelle dashboard, ma introduce un nuovo compromesso progettuale
Amazon ha rilasciato il filtro gerarchico Amazon Quick Sight il 30 settembre, sostituendo diversi controlli correlati della dashboard con un unico menu espandibile che supporta fino a cinque livelli. Il cambiamento affronta un conflitto noto nella business intelligence: i lettori vogliono filtri flessibili, ma ogni controllo aggiuntivo rende una dashboard più difficile da navigare.
Il nuovo controllo consente ai lettori di muoversi tra relazioni come Regione, Paese e Città senza dover esaminare menu separati. Gli autori possono inoltre combinare selezioni provenienti da livelli diversi, includendo un intero Paese e una città in un'altra area. AWS afferma che la funzionalità è disponibile in tutte le regioni AWS in cui Amazon Quick è supportato.
Non si tratta di un nuovo modello analitico o di un motore di visualizzazione. È un cambiamento concentrato dell'interfaccia che sposta la complessità dalla superficie della dashboard a un albero espandibile. Ciò pone il filtro gerarchico Amazon Quick Sight in contrasto con la pratica consolidata di mostrare filtri indipendenti, compresi i controlli a cascata che si restringono reciprocamente.
Il rilascio alza anche l'asticella competitiva. Microsoft Power BI supporta già più campi correlati all'interno di un unico slicer gerarchico. Amazon colma un divario evidente nell'interazione, introducendo al contempo proprie regole per selezione, ricerca, ambito e scala.
Il filtro gerarchico Amazon Quick Sight sostituisce una fila di controlli
Il cambiamento immediato è semplice: diversi filtri connessi possono ora occupare un unico spazio in una dashboard Quick Sight.
AWS ha annunciato la funzionalità tramite il suo annuncio del filtro gerarchico del 30 settembre. Il 1° ottobre è seguito un approfondito walkthrough del prodotto.
L'esempio fornito parte da sei controlli della dashboard. Quattro rappresentano dimensioni geografiche: Regione, Sottoregione, Paese e Città. I controlli rimanenti riguardano Segmento e Prodotto.
Questo layout offre ai lettori molte opzioni, ma consuma anche prezioso spazio nella dashboard. Ogni controllo geografico espone un ulteriore elenco, etichetta e punto di interazione. Un lettore deve capire come si relazionano i campi prima di effettuare una sequenza valida di selezioni.
Il filtro gerarchico Amazon Quick Sight sposta i campi geografici correlati in un unico albero. I lettori vedono prima il livello più ampio, come la Regione. Possono espandere una regione per visualizzare i Paesi, quindi espandere un Paese per visualizzare le città.
Ogni selezione restringe il ramo visibile. Scegliere un valore di livello inferiore seleziona anche il relativo percorso padre, quindi l'interfaccia mantiene la relazione tra quel valore e le sue categorie più ampie.
Questo comportamento è importante perché i filtri indipendenti possono creare un'esperienza frammentata. Un lettore potrebbe selezionare una regione in un menu, aprire un menu Paese separato e poi cercare una città. La dashboard fornisce i controlli, ma l'utente deve ricostruire la gerarchia.
Il nuovo filtro codifica direttamente questa gerarchia. Può contenere fino a cinque campi di dimensione, disposti dalla categoria più ampia a quella più dettagliata. I campi geografici sono solo un esempio. Un'azienda potrebbe utilizzare Categoria prodotto, Linea di prodotto, Prodotto, Modello e Stock Keeping Unit.
AWS consente inoltre selezioni a livelli misti all'interno dello stesso controllo. Un lettore può selezionare un nodo ampio, come il Giappone, selezionando al contempo una singola città in un altro ramo. Questo preserva una flessibilità che andrebbe persa se gli utenti fossero limitati ai valori foglia.
La guida al filtro gerarchico dell'azienda distingue questo controllo dai filtri a cascata. Entrambi gli approcci guidano i lettori attraverso dimensioni correlate, ma le loro interfacce differiscono.
Un filtro gerarchico annida l'intero percorso all'interno di un unico controllo. I filtri a cascata restano controlli separati, in cui una scelta precedente limita ciò che appare in un controllo successivo.
Questa distinzione crea la tensione centrale dell'articolo. Amazon ha ridotto il numero di decisioni visibili, ma non ha eliminato la complessità sottostante. Ha riorganizzato quella complessità in un'interazione più compatta.
Il cambiamento differisce anche dal drill-down visivo. Quick Sight consente già ai lettori di muoversi tra livelli gerarchici all'interno dei grafici supportati. I suoi drill-down visivi perfezionano un elemento del grafico selezionato, ad esempio passando da uno stato alle sue città.
Il filtro gerarchico opera a livello dei controlli della dashboard. A seconda dell'ambito configurato, può modificare diverse visualizzazioni o un'intera dashboard con più fogli. Questo lo rende un meccanismo di navigazione per l'analisi, non solo per un singolo grafico.
Gli autori di dashboard sono sotto pressione per comprimere le scelte
Il filtro gerarchico risponde a un problema di interfaccia che diventa più oneroso man mano che le dashboard acquisiscono dimensioni, fogli e pubblici.
Le dashboard di business intelligence spesso servono lettori con domande differenti. Un responsabile regionale potrebbe voler analizzare un intero mercato, mentre il responsabile di un negozio necessita di una sola sede. Un dirigente di prodotto può iniziare da una categoria e poi esaminare un modello.
Supportare questi percorsi di solito significa aggiungere controlli. Tuttavia, ogni controllo richiede ai lettori di riconoscere un campo, comprenderne i valori e sapere se dipende da un altro campo.
Gli autori delle dashboard si trovano quindi di fronte a due esigenze contrastanti. Devono offrire filtri sufficienti a supportare l'esplorazione, mantenendo al contempo l'interfaccia comprensibile per lettori che non hanno creato l'analisi.
Il filtro gerarchico Amazon Quick Sight affronta questa pressione nascondendo i livelli inferiori finché non diventano rilevanti. Inizialmente un lettore vede un piccolo insieme di nodi di livello superiore anziché ogni città, prodotto o reparto.
L'approccio riduce il disordine visivo, ma il suo contributo più rilevante riguarda la sequenza informativa. Presenta le scelte nell'ordine stabilito dall'autore.
Questa sequenza può prevenire combinazioni contraddittorie o confuse. Una città appare sotto il proprio Paese e la propria regione, quindi il controllo comunica il contesto prima che il lettore si impegni in una selezione.
AWS illustra il comportamento con un dataset retail contenente tre regioni, otto Paesi e quattordici città. Questi numeri sono modesti, ma rendono visibile il modello di navigazione. Il valore diventa più evidente quando un dataset di produzione contiene molti più elementi.
Il controllo può anche filtrare un'intera dashboard quando un autore ne modifica l'ambito. I filtri Quick Sight supportano altrimenti diversi ambiti, che vanno da una singola visualizzazione a tutte le visualizzazioni applicabili.
La documentazione sull'ambito dei filtri di Amazon osserva che i filtri di analisi persistono nelle dashboard pubblicate. Più filtri di livello superiore vengono applicati insieme con logica AND, mentre i filtri raggruppati possono usare la logica OR.
Questo comportamento esistente spiega perché il consolidamento è importante. Ridurre il numero visibile di controlli non riduce necessariamente il numero di condizioni applicate ai dati. Il filtro gerarchico fornisce a tali condizioni un'interfaccia condivisa e un esplicito ordine padre-figlio.
Gli autori mantengono il controllo sulle conseguenze di ogni selezione. Una gerarchia può applicarsi a una visualizzazione, a un foglio o a un insieme più ampio di visualizzazioni. Scelte di ambito errate possono quindi produrre un controllo pulito che si comporta in modo inatteso.
Il filtraggio tra fogli aumenta la posta in gioco. AWS ha introdotto più ampi controlli tra fogli prima di questo lancio della gerarchia, consentendo a una selezione di influire su più fogli.
Il filtro gerarchico si basa su queste fondamenta. Un singolo albero delle località può ora guidare un lettore attraverso una dashboard che contiene fogli di panoramica, regionali e operativi.
Questo è utile per l'analisi incorporata, dove lo spazio della dashboard compete con l'applicazione circostante. Una dashboard incorporata non può presupporre una tela illimitata né un lettore formato sullo strumento BI.
Una gerarchia compatta offre inoltre agli autori più spazio per le visualizzazioni che veicolano l'argomentazione effettiva. Rimuovere tre caselle filtro non aumenta da solo la profondità analitica, ma può ridurre l'area dell'interfaccia dedicata all'uso della dashboard.
La pressione ricade più direttamente sugli autori che gestiscono analisi ricche di filtri. Ora dispongono di un'opzione nativa di consolidamento e i lettori si aspetteranno ragionevolmente di trovarla dove le dimensioni hanno una gerarchia evidente.
Questa aspettativa crea lavoro. Gli autori devono esaminare i controlli esistenti, confermare le relazioni padre-figlio, decidere l'ambito e testare le selezioni salvate prima di sostituire il vecchio layout.
Il vantaggio, quindi, non è automatico. Un filtro gerarchico migliora l'esperienza del lettore solo quando i campi sottostanti formano un percorso stabile e comprensibile.
Una gerarchia ora compete con molti filtri indipendenti
La competizione principale non è Amazon contro un altro fornitore. È una gerarchia guidata contro la libertà dei controlli separati.
I filtri indipendenti restano la scelta migliore quando le dimensioni non condividono una naturale relazione padre-figlio. Regione e Categoria prodotto, ad esempio, possono essere entrambe importanti senza appartenere a una stessa gerarchia.
I controlli separati mantengono inoltre visibile ogni dimensione. Questo può aiutare i lettori esperti che desiderano modificare rapidamente più valori senza dover aprire e navigare ripetutamente un unico menu.
Una gerarchia funziona diversamente. Prende una decisione editoriale sul modo in cui i lettori dovrebbero avvicinarsi ai dati. L'autore definisce il percorso e l'interfaccia incoraggia i lettori a seguirlo dall'ampio allo specifico.
Questo può migliorare l'orientamento per gli utenti occasionali. Può anche rallentare chi conosce già l'esatto valore di livello inferiore di cui ha bisogno.
La scelta risulta più chiara confrontando i filtri gerarchici con i controlli a cascata. In una progettazione a cascata, Regione, Paese e Città restano separati. La selezione di una regione restringe l'elenco dei Paesi, mentre la selezione di un Paese restringe l'elenco delle città.
Questo layout espone a colpo d'occhio l'intera sequenza analitica. Occupa però più spazio e richiede più spostamenti nella dashboard.
Il filtro gerarchico Amazon Quick Sight colloca la stessa sequenza concettuale all'interno di un unico controllo espandibile. Sacrifica la visibilità simultanea per ottenere maggiore compattezza.
Nessuno dei due modelli è universalmente superiore. La scelta corretta dipende dal fatto che i lettori traggano maggior beneficio dal vedere ogni fase oppure dal mantenere ordinata la superficie della dashboard.
Il nuovo controllo cambia anche il modo in cui gli autori comunicano la profondità disponibile. Cinque filtri visibili pubblicizzano chiaramente cinque dimensioni. Un menu chiuso può nascondere tale ricchezza finché un lettore non lo apre.
Etichette e contesto circostante diventano quindi più importanti. Un titolo generico come “Posizione” potrebbe non indicare ai lettori che il controllo include Regione, Paese, Città e Negozio.
Questo è il vero meccanismo alla base del lancio. Amazon non sta eliminando la complessità dei filtri. La sta comprimendo e si affida alla divulgazione gerarchica per renderla gestibile.
Questo design può funzionare particolarmente bene per relazioni che gli utenti già comprendono. Geografia, linee gerarchiche organizzative, cataloghi di prodotti e strutture di account possiedono schemi padre-figlio riconoscibili.
Diventa meno affidabile quando la gerarchia è artificiale. Un team di marketing potrebbe raggruppare canali, campagne, creatività e segmenti di pubblico, ma utenti diversi potrebbero aspettarsi percorsi differenti attraverso quei dati.
Un ordine imposto può quindi nascondere combinazioni utili o suggerire una relazione che il processo aziendale sottostante non supporta. La dashboard appare più pulita, mentre diventa concettualmente più ristretta.
Gli autori dovrebbero inoltre separare il filtraggio dall’esplorazione all’interno di un elemento visivo. Un filtro gerarchico modifica i record che restano disponibili nel proprio ambito. Un drill-down del grafico cambia il livello di dettaglio mostrato all’interno di un elemento visivo selezionato.
Combinare entrambi può essere efficace. Un lettore potrebbe filtrare la dashboard su una famiglia di prodotti, quindi approfondire le prestazioni mensili all’interno di un grafico.
Combinare entrambi può anche confondere i lettori se lo stato del filtro attivo non è evidente. Un grafico può sembrare omettere dati perché una selezione di livello superiore resta attiva nel filtro compatto.
Per questo il lancio dovrebbe essere valutato in base al comportamento dei lettori, non alla densità della barra degli strumenti. Un minor numero di controlli visibili è utile solo quando i lettori riescono a comprendere lo stato attuale e a modificarlo senza attriti.
Per i team che creano dashboard a partire da appunti di riunioni, requisiti e ricerca sugli utenti, tale comportamento dovrebbe essere documentato insieme all’analisi. Un workflow di prodotto ricercabile può aiutare i team a conservare il motivo per cui sono stati scelti una gerarchia e il relativo ambito.
La decisione chiave non è se utilizzare il controllo più recente. È se un percorso fisso corrisponde al modo in cui il pubblico previsto pone le domande.
Il controllo compatto ha limiti di ricerca e scala
Il filtro gerarchico riduce il disordine visivo, ma i suoi vincoli possono reintrodurre attriti all’interno del menu.
La prima limitazione è strutturale. Un filtro gerarchico supporta non più di cinque livelli. Questo è sufficiente per molti percorsi geografici, organizzativi e di prodotto, ma non tutte le tassonomie aziendali rientrano in tale limite.
Gli autori con strutture più profonde devono fermarsi a cinque livelli, combinare campi o lasciare alcune dimensioni in controlli separati. Ogni opzione modifica il modo in cui i lettori interpretano la gerarchia.
Il filtro accetta inoltre campi di dimensione anziché misure. Dimensioni testuali e numeriche, così come i campi Booleani, possono fungere da livelli. Misure come Sales o Quantity non possono farlo.
Questa restrizione è logica perché una gerarchia descrive relazioni categoriali. Ciò nonostante, significa che gli autori hanno bisogno di un altro tipo di filtro per soglie, intervalli e metriche di prestazione.
Il comportamento della ricerca introduce un compromesso più evidente. La casella di ricerca nella parte superiore della gerarchia cerca soltanto il livello più alto. Non cerca ogni valore annidato sotto quel livello.
Un lettore che cerca una città non può necessariamente digitare il nome della città nel campo di ricerca superiore e accedervi direttamente. Il lettore deve prima entrare nel ramo pertinente o espanderlo.
I livelli inferiori possono fornire le proprie caselle di ricerca. AWS afferma che ne appare una quando un livello contiene più di 10 valori univoci.
L’interfaccia cambia nuovamente quando un livello contiene più di 1.000 valori univoci. A quel punto, il controllo visualizza soltanto una casella di ricerca invece di elencare i valori.
Questo design impedisce che un menu enorme sovrasti il lettore. Tuttavia, sostituisce la navigazione con la capacità di ricordare. Gli utenti devono conoscere una parte sufficiente del nome di un valore per cercarlo.
La differenza conta nei set di dati con etichette incoerenti, abbreviazioni o nomi di account poco familiari. Una gerarchia compatta non può correggere dati anagrafici deboli.
I valori null introducono un’altra considerazione. Gli autori possono scegliere in che modo i null influenzano le righe visualizzate negli elementi visivi, ma tale scelta non controlla come i null appaiono all’interno del controllo gerarchico stesso.
Questa distinzione merita test perché i lettori potrebbero interpretare un nodo gerarchico vuoto come dati mancanti, un ramo non disponibile o un malfunzionamento.
Lo stato di selezione può inoltre sorprendere gli autori durante la manutenzione. Riordinare i campi della gerarchia cancella le selezioni già salvate nel filtro.
Una riprogettazione apparentemente minore può quindi modificare lo stato predefinito sperimentato dai lettori. I team dovrebbero registrare le selezioni previste prima di modificare l’ordine dei campi e convalidare la dashboard ripubblicata in seguito.
La gerarchia propaga anche lo stato del nodo padre. Selezionando un valore di livello inferiore, la relativa catena di nodi padre viene automaticamente contrassegnata, con nodi più ampi mostrati come parzialmente selezionati quando opportuno.
Questo comportamento preserva il contesto, ma la selezione a livelli misti può rendere più difficile riassumere il set di dati risultante. Selezionare un intero Paese accanto a una singola città crea un confronto intenzionalmente disomogeneo.
Tale flessibilità è preziosa per l’analisi ad hoc. Può essere rischiosa in una dashboard condivisa se i lettori presumono che ogni ramo selezionato rappresenti lo stesso livello di aggregazione.
Gli autori dovrebbero testare titoli, sottotitoli ed etichette visive con selezioni a livelli misti. Un grafico etichettato “Vendite per città” diventa fuorviante quando il filtro include anche un intero Paese.
L’ambito resta un’altra fonte di incertezza. La configurazione iniziale del filtro si applica a un solo elemento visivo, a meno che l’autore non la modifichi. Una gerarchia mostrata in evidenza nella parte superiore può quindi sembrare globale pur influenzando soltanto una parte della dashboard.
Questa discrepanza è più dannosa del disordine visibile perché può modificare il significato di un’analisi senza avvisare il lettore. Un’interfaccia più pulita aumenta l’importanza di un chiaro riscontro sullo stato.
La conclusione scettica è semplice. AWS ha mostrato come opera la funzionalità, ma non ha pubblicato prove indipendenti che i lettori completino le attività di filtraggio più rapidamente o commettano meno errori.
L’annuncio descrive meno passaggi e una minore confusione come vantaggi. Queste affermazioni sono plausibili, ma il loro valore varierà in base alla profondità della gerarchia, al numero di membri, alla qualità dei dati e alla familiarità del pubblico.
Le aziende dovrebbero misurare il completamento riuscito delle attività, il tempo per raggiungere una vista target, i ripristini dei filtri e le richieste di assistenza prima di dichiarare che la riprogettazione è un miglioramento.
Power BI dimostra che il filtraggio gerarchico è un’aspettativa di base
Il rilascio di Amazon migliora Quick Sight, ma il filtraggio gerarchico esiste già come modello riconoscibile nei prodotti concorrenti di business intelligence.
Microsoft Power BI consente agli autori dei report di aggiungere più campi correlati a un unico slicer. I lettori possono espandere e comprimere i livelli con i chevron, mentre gli autori possono scegliere un menu a discesa o un elenco verticale.
La documentazione sullo slicer gerarchico di Microsoft descrive anche i controlli di formattazione per titoli, rientri e icone di espansione o compressione.
Questo confronto colloca il lancio di Amazon nel suo contesto. Quick Sight non sta creando una categoria di interazione completamente nuova. Sta aggiungendo un’implementazione nativa di un modello che gli acquirenti di business intelligence possono già riconoscere.
Questo è importante per le organizzazioni che valutano gli strumenti perché piccoli divari nell’interfaccia diventano costosi su larga scala. Se manca un controllo desiderato, gli autori potrebbero aggiungere più componenti, riprogettare la dashboard o creare una soluzione alternativa.
Un filtro gerarchico nativo riduce questa pressione. Consente agli autori di Quick Sight di offrire un albero familiare e navigabile senza affidarsi a diversi controlli nel foglio.
La versione di Amazon enfatizza la selezione a livelli misti e un massimo di cinque dimensioni. La sua documentazione traccia inoltre una chiara distinzione tra un filtro gerarchico e filtri a cascata separati.
Power BI offre un insieme più ampio di opzioni di presentazione attorno al suo slicer gerarchico. Microsoft documenta rientri configurabili e icone alternative di espansione o compressione, funzionalità non messe in evidenza nel materiale di lancio di Amazon.
Il confronto non dovrebbe essere esteso fino a diventare un verdetto sui prodotti. Il filtraggio è solo una parte di una piattaforma BI, e le organizzazioni scelgono gli strumenti in base ad accesso ai dati, governance, incorporamento, amministrazione, visualizzazione e impegni cloud esistenti.
Tuttavia, la parità dell’interfaccia influenza l’uso quotidiano. I lettori delle dashboard interagiscono con i controlli molto più spesso di quanto esaminino un diagramma dell’architettura.
L’arrivo del filtro gerarchico Amazon Quick Sight esercita pressione anche sui team interni di analytics, non solo sui fornitori. Una volta disponibile un’opzione compatta, una dashboard affollata di filtri correlati diventa più difficile da giustificare.
Gli autori dovranno spiegare quando i controlli indipendenti sono intenzionali. Questo è positivo perché sposta il design della dashboard dall’abitudine verso esigenze esplicite dei lettori.
La questione competitiva riguarda quindi meno il conteggio delle funzionalità e più l’esecuzione. Il controllo di Amazon può restare comprensibile con gerarchie profonde, selezioni miste, null e campi ad alta cardinalità?
Le limitazioni documentate da Microsoft ricordano che le interfacce gerarchiche ereditano problemi dal modello sottostante. La sua guida segnala complicazioni con le gerarchie irregolari, in cui alcuni membri non hanno valori a livelli intermedi.
Le regole di Amazon su null e ricerca indicano limiti pratici analoghi. Un albero può rappresentare elegantemente relazioni pulite, ma le strutture irregolari richiedono test accurati.
Questa base competitiva modifica anche le aspettative degli acquirenti per le dashboard integrate. Un utente abituato a espandere categorie in Power BI si aspetterà un comportamento equivalente all’interno di un’applicazione Quick Sight.
Amazon dispone ora di una risposta diretta a tale aspettativa. La domanda restante è se gli autori lo adotteranno con sufficiente coerenza affinché i lettori si fidino dell’interazione.
Cosa osservare dopo il lancio del filtro gerarchico
La fase successiva dipende dalle prove di adozione, da un supporto più ampio alle interazioni e da come Amazon risponderà ai limiti attuali del controllo.
Il primo segnale è l’adozione da parte degli autori nelle dashboard Quick Sight esistenti. AWS ha reso disponibile la funzionalità ovunque sia supportato Amazon Quick, ma la disponibilità non dimostra se i team sostituiranno i controlli consolidati.
L’adozione sarà più significativa nelle dashboard con gerarchie geografiche, di prodotto o organizzative chiare. Se gli autori useranno il controllo principalmente in nuove dimostrazioni, il lancio resterà un’opzione utile anziché un importante cambiamento di design.
Le prove più solide deriverebbero da risultati misurati sui lettori. I team dovrebbero confrontare i layout vecchi e nuovi utilizzando le stesse attività analitiche.
Se i lettori raggiungono più rapidamente una posizione target, creano meno combinazioni non valide e ripristinano i filtri meno spesso, il modello guidato di Amazon acquisisce sostegno. Se gli utenti faticano a individuare valori di livello inferiore, l’interfaccia compatta ha soltanto spostato l’attrito.
Il secondo segnale è il perfezionamento del prodotto attorno alla ricerca e alla visibilità dello stato. La ricerca solo al livello superiore è gestibile nelle gerarchie piccole, ma limita l’accesso diretto a valori profondamente annidati.
Una futura modalità di ricerca che abbracci tutti i livelli rafforzerebbe il controllo per cataloghi di grandi dimensioni. Dovrebbe inoltre mostrare una quantità sufficiente di discendenza gerarchica affinché i lettori possano distinguere nomi duplicati.
Sarebbero importanti anche riepiloghi migliori delle selezioni a livelli misti. Quando i lettori scelgono un nodo ampio e uno ristretto, i titoli della dashboard e le etichette dei controlli devono comunicare tale ambito disomogeneo.
Se Amazon espanderà queste capacità, il filtro gerarchico diventerà più facile da usare oltre i set di dati dimostrativi puliti. Se le regole attuali persisteranno, gli autori avranno bisogno di etichette supplementari e formazione per analisi complesse.
Il terzo segnale è il modo in cui i prodotti BI concorrenti evolveranno i propri controlli gerarchici. Power BI fornisce già un modello di slicer maturo, quindi Amazon deve competere attraverso l’integrazione con l’ambito di filtraggio di Quick Sight, l’analytics incorporata e il comportamento tra fogli.
I concorrenti potrebbero rispondere con una migliore ricerca tra livelli, una profondità gerarchica più flessibile o riepiloghi delle selezioni più chiari. Tali cambiamenti trasformerebbero una piccola funzionalità dell’interfaccia in un ulteriore elemento di differenziazione nell’usabilità delle dashboard.
Il lancio dovrebbe inoltre spingere i team a verificare dove utilizzano filtri a cascata. I controlli separati restano preziosi quando i lettori devono vedere ogni fase o quando le dimensioni sono correlate solo in modo debole.
Sostituire ogni cascata indebolirebbe il design. Il test migliore è stabilire se la gerarchia comunica il percorso analitico più chiaramente dei controlli che rimuove.
Per gli sviluppatori e gli acquirenti aziendali, il filtro gerarchico Amazon Quick Sight merita attenzione perché modifica un’interazione ad alta frequenza. I lettori interagiscono con i filtri ogni volta che restringono una dashboard operativa, finanziaria o clienti.
Per i knowledge worker, la lezione va oltre la business intelligence. Le interfacce compatte funzionano quando rivelano la struttura nel momento in cui diventa utile. Falliscono quando la compressione nasconde lo stato, dati irregolari o scelte che gli utenti devono confrontare.
Amazon ha fornito il meccanismo. La prossima domanda è misurabile: i lettori raggiungeranno i dati giusti con meno errori, oppure gli autori si limiteranno a sostituire il disordine visibile con una navigazione nascosta?
