Tabella dati o layout a card: quando conviene la tabella

Scegliere fra una tabella dati e un layout a card è una decisione di densità: stabilisce quanti record si vedono insieme, quanti attributi si possono confrontare e quanta fatica costa ogni confronto. Ogni schermata a elenco di un gestionale, di un'area admin o di un catalogo ci passa, di solito nella prima settimana di design, e la scelta resta lì finché qualcuno non ridisegna la schermata.

A decidere è il compito. Le ricerche di Nielsen Norman Group sulle tabelle dati spiegano perché la tabella vince nei confronti: due valori vicini si leggono insieme, mentre con le card bisogna riorientarsi nello spazio ogni volta che si passa da una scheda all'altra, e il confronto diventa lento e faticoso. Le card vincono altrove, e quasi tutto l'articolo parla di dove.

La risposta breve

La tabella serve quando si confrontano record sugli stessi attributi, si cerca un valore fuori scala in una colonna, si ordina, si filtra o si agisce su molte righe insieme. Le card servono quando ogni record ha una forma sua, quando è un'immagine a far scegliere, o quando la schermata è un ingresso verso poche pagine di dettaglio. Se nessuno sa dire qual è il compito principale della schermata, la domanda sul layout arriva troppo presto: prima si chiarisce il compito.

Tabella e griglia di card a confronto

Otto criteri risolvono quasi tutti i casi. Per ognuno, prima viene il layout che funziona meglio.

• Record visibili in una schermata: tabella. Su un portatile da 1440 per 900, con circa 720 px liberi per l'elenco sotto header e barra degli strumenti, una tabella con righe da 40 px, l'altezza predefinita del design system Carbon di IBM, mostra 18 record. Tre card per riga alte 280 px ne mostrano sei interi, e la terza fila resta tagliata dal bordo dello schermo.
• Confronto di un attributo fra più record: tabella. I valori stanno in colonna e l'occhio scende in linea retta.
• Record con forme diverse: card. Ogni card può avere un'altezza e un contenuto diversi. Le colonne fisse no.
• Immagini che decidono la scelta: card. La foto di un prodotto o l'anteprima di un template chiedono uno spazio che una riga di tabella non ha.
• Ordinamento e filtri: tabella. L'intestazione di colonna è il posto naturale per ordinare, e una colonna filtrata mostra subito l'effetto.
• Azioni su più record: tabella. Caselle di selezione sulle righe e una barra di azioni sono un pattern consolidato, che Carbon offre come variante della sua tabella.
• Area di tocco: card. Tutta la card può essere un unico link, un bersaglio più grande che NN/g collega alla legge di Fitts.
• Tecnologie assistive: tabella, se è una tabella vera. Il tutorial del W3C sulle tabelle spiega che le celle d'intestazione marcate come th danno agli screen reader il contesto di ogni valore. Una griglia di div non ne dà nessuno.

Quando una tabella batte una griglia di card?

La tabella vince quando la schermata serve i quattro compiti che NN/g individua per le tabelle dati: trovare i record che rispondono a certi criteri, confrontare i dati, vedere o modificare una singola riga, agire sui record. Quasi tutte le schermate operative di un SaaS fanno proprio questo: fatture, ordini, utenti, ticket, deploy, lead.

Gli attributi si ripetono su ogni record

Ogni fattura ha un numero, un cliente, un importo, una scadenza e uno stato. Quando gli attributi si ripetono, l'intestazione dice ogni etichetta una volta sola e le righe contengono solo valori. La card ripete l'etichetta su ogni record, oppure la toglie e lascia indovinare. Cinque attributi su 50 fatture fanno 250 valori: in tabella si leggono anche cinque etichette, in una griglia di card fino a 250.

Si cerca l'eccezione

Dietro quasi ogni elenco c'è un confronto. Quale ordine è in ritardo, quale cliente deve di più, quale deploy è fallito. Una colonna di importi si scorre dall'alto in basso in un solo passaggio. Gli stessi importi sparsi in una griglia, ognuno nella sua card, vanno cercati uno alla volta.

L'elenco cresce

Fra i vantaggi delle tabelle NN/g mette per prima la scalabilità: righe e colonne si aggiungono quando i dati cambiano. Una card disegnata su quattro attributi va ridisegnata al settimo. Alla tabella basta una colonna in più e la decisione su dove metterla.

Si agisce su molti record insieme

Archiviare 30 ticket, esportare un mese di ordini, riassegnare un gruppo di lead. Selezionare più righe, con il conteggio sempre visibile e una barra di azioni, è un pattern da tabella. Anche le card si possono rendere selezionabili, ma la casella entra in conflitto con il clic che apre la card.

Quando una griglia di card batte una tabella?

NN/g definisce la card come un contenitore per poche informazioni brevi e collegate fra loro, una rappresentazione breve e cliccabile di un solo concetto. La definizione traccia già il territorio: pochi attributi, un link verso il resto, un concetto per card.

Ogni record ha una forma sua

Un feed di progetti dove uno ha un'immagine di copertina, il successivo una citazione e il terzo un grafico. Una tabella li costringerebbe nelle stesse colonne e lascerebbe vuota la maggior parte delle celle. Le card mantengono la larghezza fissa e lasciano che l'altezza segua il contenuto.

Si sceglie guardando

Template, temi, prodotti, immobili, persone. Quando l'utente sceglie guardando, l'immagine è l'attributo principale, e una riga da 40 px non la mostra. Una colonna di miniature va bene per riconoscere, cioè ritrovare un file che si conosce già. Non va bene per scegliere un elemento mai visto prima.

La schermata è un ingresso

La home di una dashboard, un elenco di workspace, un catalogo di corsi. Pochi record, ognuno da aprire più che da confrontare. La card deve dare abbastanza informazioni da far venire voglia di cliccare, e tutta la sua area può essere il bersaglio.

Cosa succede a una tabella sul telefono?

Il riflesso più comune è trasformare ogni riga in una card impilata sotto un certo breakpoint. Il problema della larghezza sparisce, e con lui il confronto per cui la tabella esisteva. L'accessibilità non lo chiede. Il criterio di successo 1.4.10 delle WCAG 2.2, Reflow, chiede che i contenuti stiano in 320 px CSS di larghezza senza scorrere in due direzioni, e cita le tabelle dati fra i contenuti che hanno bisogno di un layout bidimensionale e possono scorrere in entrambi i sensi. Ogni singola cella, invece, deve adattarsi.

Le indicazioni di NN/g sulle tabelle su mobile tengono la tabella e la rendono usabile: colonne abbastanza larghe da leggerle (su uno schermo stretto entrano due colonne di testo, di più se i valori sono numeri), intestazioni fisse, prima colonna fissa, un segnale visibile che altre colonne stanno fuori dallo schermo, e la possibilità di scegliere quali colonne vedere. Le righe diventano card impilate solo quando sul telefono si cerca un singolo record, come un tecnico che apre il prossimo intervento. Se anche sul telefono si confronta, la tabella resta, ridotta alle colonne che servono a quel confronto.

La densità si regola, il layout resta

Spesso si passa alle card perché la tabella sembra affollata. Contro l'affollamento si lavora su altezza delle righe e spaziature. La tabella di Carbon prevede cinque altezze di riga: 24 px per i layout molto densi, 32, 40 come predefinita, 48, e 64 px per righe su due linee. Si sceglie l'altezza in base a cosa c'è nella riga, poi si usano corpo del testo, peso e contrasto per separare l'identificativo dai valori secondari.

Fra i due layout c'è la riga di elenco ricca: un record per riga, un'etichetta principale, due o tre valori secondari, magari un avatar. Va bene per record con pochi attributi, quando conta leggere in sequenza più che allineare le colonne, come nei messaggi o nelle attività recenti. Quando gli utenti cominciano a chiedere di ordinare per uno di quei valori, l'elenco è diventato una tabella.

Due errori tornano spesso, uno per parte. Il primo è la griglia di card per dati da confrontare: fatture in forma di card, con importo, data e stato in un angolo diverso di ognuna, così per trovare quelle scadute bisogna leggerle tutte. Il secondo è la tabella per contenuti visivi: una galleria di template ridotta a nomi in fila, così per scegliere bisogna aprirli uno per uno. In entrambi i casi il layout è stato scelto prima di mettere per iscritto il compito.

Come scegliamo su una schermata vera

Prima di disegnare l'elenco rispondiamo a cinque domande, in quest'ordine.

1. Qual è l'unico compito di questa schermata? Trovare, confrontare, agire, oppure sfogliare e aprire. Confrontare e agire portano alla tabella. Sfogliare e aprire portano alle card.
2. Quanti record, in un giorno normale e nel caso peggiore? Una schermata con 8 record al lancio e 800 un anno dopo è una tabella fin dal primo rilascio.
3. I record hanno gli stessi attributi? Se sì, gli attributi diventano colonne. Se ogni record ha una forma sua, card.
4. È un'immagine a decidere la scelta? Se sì, card, oppure una tabella con l'anteprima grande della riga selezionata accanto.
5. Qual è il compito sul telefono? Se si confronta, resta la tabella, con intestazioni fisse e meno colonne. Se si cerca un solo record, le righe si possono impilare.

Nei prodotti che progettiamo, gli elenchi operativi (ordini, utenti, fatture, log) partono come tabella, con la densità regolata dall'altezza delle righe. Le card restano per gallerie, template e i riquadri di sintesi in cima a una dashboard. La tabella si disegna insieme ai suoi stati vuoto, di caricamento e di errore, come facciamo con gli empty state in ogni schermata.

Un controllo intercetta quasi tutte le scelte sbagliate. Scrivi come frase la domanda con cui l'utente arriva sulla schermata. Se contiene "quale" e un superlativo (quale cliente deve di più, quale job è fallito stanotte), la schermata è una tabella.