Come progettare tabelle responsive

Progettare una tabella responsive significa conservarne le relazioni utili quando cambia la larghezza disponibile. Far entrare tutte le colonne è soltanto una soluzione possibile. Una tabella leggibile che scorre può sostenere il confronto meglio di schede ordinate che separano i valori da confrontare.

Parti dal compito: confrontare record, trovarne uno, ispezionarlo o agire su un gruppo? La risposta decide cosa deve restare insieme e cosa può essere rivelato da un comando. Senza, si finisce con font minori, colonne nascoste e pulsanti sempre più stretti.

Gli esempi usano una coda fittizia con nome progetto, responsabile, stato, scadenza e numero di commenti aperti.

Trova la relazione da conservare

Una tabella è utile perché la posizione comunica significato. Puoi scendere lungo una colonna per confrontare valori oppure attraversare una riga per collegare un record ai suoi attributi. Una modifica responsive può conservare una relazione indebolendo l’altra.

Un manager potrebbe cercare il progetto con scadenza più vicina e commenti irrisolti. Data e conteggio servono insieme all’identità. Nascondere il conteggio perché è nell’ultima colonna rompe il compito, anche se pulisce la schermata.

Chi apre il progetto assegnato per una revisione ha un’esigenza diversa. Potrebbero contare nome, stato e un’azione chiara, con altri dettagli disponibili dopo. Una sintesi compatta con espansione potrebbe funzionare bene. Il dataset è lo stesso, ma la vista iniziale necessaria è diversa.

Segna quindi le informazioni necessarie per completare ogni compito. Una colonna usata da tutti i compiti appartiene alla vista principale. Un campo che serve soltanto dopo aver scelto un elemento può invece essere mostrato su richiesta. Questa è una decisione sul lavoro dell’utente, non un invito a cancellare i dati meno importanti.

Separa larghezza della tabella e pagina

Una tabella larga non deve far scorrere tutta la pagina lateralmente. In CSS, un contenitore overflow-x: auto offre scorrimento locale, lasciando titolo, descrizione, filtri e testo nel viewport. Anche il contenitore deve poter restringersi: un figlio a piena larghezza in una griglia rigida può ancora allargare la pagina. La bidimensionalità resta dove serve.

W3C ammette per Reflow un’eccezione ai contenuti che richiedono due dimensioni, comprese le tabelle. Distingue però il contenuto delle singole celle, che deve rifluire appropriatamente. Non è un permesso di far debordare ogni etichetta e paragrafo. Spiegazione W3C di Reflow.

Lascia andare a capo i nomi lunghi in celle ragionevoli. Non preservare spazio vuoto enorme solo perché esisteva sul desktop. Le relazioni possono richiedere movimento orizzontale e comunque beneficiare di celle curate.

Il confine deve essere riconoscibile. Se l’ultima colonna visibile coincide col bordo, si può pensare che non ci sia altro. Una parte della successiva, una scrollbar disponibile o una guida concisa chiariscono la continuazione. Non affidarti soltanto a una dissolvenza decorativa.

Mantieni titolo e contesto del compito fuori dalla regione scorrevole quando possibile. «Progetti in attesa di revisione» spiega cosa accomuna i record. Una breve nota può chiarire l’ordinamento iniziale o un fuso rilevante. Sono ausili di orientamento, non colonne aggiuntive in competizione per spazio.

USWDS mostra due pattern realmente diversi

Il componente tabella USWDS offre variante scorrevole e impilata. La prima conserva la matrice, la seconda presenta valori etichettati dentro singoli record su schermi stretti. Gli esempi funzionanti mostrano la differenza.

Conta più dei nomi: la matrice mette in relazione colonne per posizione; il record ripete le etichette per lettura indipendente. Dati identici possono richiedere molto più lavoro per il confronto.

Prova nella coda: trova la scadenza più lontana fra progetti con oltre cinque commenti. In tabella puoi scorrere insieme le colonne di conteggio e data. Nelle schede potresti dover attraversare ogni record e ricordare il candidato precedente. Poi chiedi «Leggi responsabile e scadenza di Cedar Lodge»: il formato impilato può essere comodo perché il confronto non è più centrale.

Valuta il costo della trasformazione

Nella consegna specifica alcune invarianti: identificatore della riga disponibile, unità associata al valore, campo ordinato comprensibile e ambito della selezione stabile dopo il resize. Sono più durevoli del requisito che ogni colonna desktop entri sul telefono. Consentono di cambiare presentazione senza cambiare silenziosamente il compito.

Testa l’estremo scomodo del pattern. Scorri completamente a destra con un nome riga lungo. Espandi record adiacenti con contenuti di lunghezza diversa. Seleziona un elemento, cambia viewport e continua la stessa azione. Uno screenshot iniziale pulito non mostra un conteggio di selezione vecchio, una colonna fissa che copre valori o dettagli associati al record sbagliato.

Quattro pattern e i loro compromessi

1. Conservare la tabella e scorrere

È un buon candidato quando il confronto allineato è principale e tutte le colonne restano significative. Conserva la matrice anziché cambiarne la struttura. Serve però una navigazione intenzionale nella larghezza.

Nella tabella di revisione, metti il nome progetto vicino all’inizio e mantienilo visibile se l’implementazione supporta una colonna fissa affidabile. Altrimenti scorrendo alla scadenza si può perdere l’identità della riga letta. La colonna nome deve essere abbastanza stretta da lasciare spazio utile agli altri dati.

Non bloccare metà tabella. Su uno schermo stretto, due o tre colonne fisse possono occupare quasi tutto il viewport e lasciare soltanto una piccola porzione per i dati che scorrono. Parti dall’identificatore più compatto che permetta di riconoscere la riga. Se i nomi dei progetti sono lunghi, consenti il ritorno a capo oppure valuta con attenzione un identificatore secondario, anziché fissare un blocco troppo largo.

Le intersezioni fisse richiedono cura visiva. La cella in alto a sinistra può stare sopra sia l’intestazione fissa sia la prima colonna. Senza ordine chiaro dei livelli e sfondo opaco, i valori possono trasparire o sovrapporsi. È un dettaglio che sembra corretto da fermo e fallisce durante lo scorrimento.

Non limitare la verifica ai gesti touch. Chi usa la tastiera deve poter raggiungere e azionare la regione scorrevole quando serve, mentre il focus deve restare visibile sugli elementi interattivi. Verifica il comportamento effettivo nei browser e con le tecnologie assistive pertinenti: disegnare una cornice di focus nel mockup non dimostra che la regione sia accessibile da tastiera.

2. Colonne prioritarie e dettagli rivelati

Le colonne prioritarie funzionano quando la maggior parte delle decisioni quotidiane dipende da pochi campi. Mantieni questi visibili e offri un modo chiaro di vedere gli altri. Riduci la larghezza senza sacrificare il compito principale solo se la priorità scelta è corretta.

Per un revisore, nome, stato e scadenza possono formare una vista compatta utile, con responsabile e commenti nella riga espansa. Per il manager che cerca lavoro scaduto con commenti irrisolti, nascondere il conteggio sarebbe una scelta scadente. Non esiste un elenco universalmente corretto di colonne mobili indipendente dal compito.

Usa un comando di espansione il cui stato sia chiaro. I dettagli devono risultare visibilmente associati al record corretto, soprattutto quando le righe vicine si assomigliano. Se la posizione del pannello lascia dubbi, ripeti al suo interno il nome del progetto. Evita etichette vaghe che non permettano di capire se il comando apre i dettagli, un menu o una nuova pagina.

Non richiedere di espandere la riga per trovare un’azione necessaria su quasi tutti i record. In una coda di revisione, il comando per aprire la revisione può meritare di essere sempre visibile. Nasconderlo insieme a metadati usati di rado riduce la larghezza, ma costringe a ripetere lo stesso lavoro. Valuta la frequenza delle interazioni, non soltanto lo spazio occupato dai campi.

Dichiara le colonne omesse. Se sul desktop ci si aspetta il responsabile e sullo stretto scompare, offri un percorso comprensibile per raggiungerlo: dettagli accessibili, selettore colonne o sintesi espansa. Rimuovere silenziosamente cambia le informazioni disponibili.

3. Record come schede etichettate

I record impilati sono utili quando si legge un elemento alla volta. Ogni valore riceve un’etichetta visibile e la riga diventa una piccola sintesi verticale. Può funzionare per dettagli d’ordine o appuntamenti in cui il confronto fra record è secondario.

Nella tabella fittizia, una scheda può mostrare Cedar Lodge come titolo, poi stato, scadenza, responsabile e commenti aperti. È facile da leggere come singolo record. Ma confrontare i commenti di dieci progetti richiede di ritrovare ripetutamente la stessa etichetta su una pagina molto più alta.

Prima di scegliere questo pattern, chiedi a qualcuno di confrontare uno stesso attributo in più record. Se deve scorrere avanti e indietro per ricordare i valori, le schede hanno sostituito lo spostamento orizzontale con un confronto verticale che richiede più memoria. Il compromesso può essere accettabile, ma va scelto consapevolmente.

Mantieni coerente l’ordine etichetta-valore fra le schede. Non mettere lo stato in alto in una e dopo il responsabile nell’altra solo perché manca un valore. Rappresenta il dato mancante con testo significativo per conservare la prevedibilità.

Evita di inserire le etichette soltanto come contenuto generato a scopo decorativo senza verificarne il risultato accessibile. Mostrare la parola «Scadenza» e rendere disponibile la relazione tra etichetta e valore a livello di codice sono due aspetti distinti. Il markup finale deve comunicare i dati in modo coerente anche a chi non vede la scheda.

Se la versione desktop usa una tabella semantica e quella stretta ne modifica la presentazione visiva, verifica che le relazioni della tabella restino disponibili come previsto. Se nella pagina convivono presentazioni separate, assicurati che il contenuto nascosto non produca controlli duplicati o una lettura ripetuta con le tecnologie assistive. La trasformazione richiede una verifica dell’implementazione, non soltanto dello stile responsive.

4. Scegliere cosa confrontare

Alcune tabelle hanno molte colonne legittime, ma raramente servono tutte insieme. Un selettore aiuta a costruire una vista utile. Un confronto dedicato permette di scegliere pochi record e guardare insieme gli attributi rilevanti.

Questi controlli introducono lavoro. Un nuovo utente potrebbe non sapere quali colonne contino o credere completo il default. Fornisci una vista iniziale sensata e rendi chiaro quando alcune colonne sono nascoste. La personalizzazione sostiene la competenza, non deve subordinare la comprensione di base a una configurazione.

Il default della tabella può includere progetto, stato, scadenza e commenti. Un coordinatore potrebbe aggiungere il responsabile, mentre un singolo revisore potrebbe rimuoverlo. L’identificatore progetto resta disponibile per non trasformare i record in righe di numeri scollegati.

Una modalità di confronto è più adatta a scegliere fra poche alternative che a lavorare su una lunga coda. Selezionare tre prodotti per confrontarli può essere ragionevole; selezionare tutti i progetti soltanto per scoprire quali siano in ritardo è un passaggio superfluo. Non aggiungere un controllo di confronto solo perché la tabella è larga.

Se gli utenti possono salvare una vista, definisci che cosa viene salvato. Visibilità e ordine delle colonne, ordinamento dei dati e filtri sono preferenze distinte. Una disposizione salvata delle colonne non dovrebbe conservare inaspettatamente un vecchio filtro e nascondere nuovi record. In un prototipo visivo, annota questi comportamenti come requisiti: un pulsante Salva disegnato non dimostra che la persistenza sia già disponibile.

Conserva senso di etichette, numeri e vuoti

Il responsive espone spesso convenzioni deboli. «04/05» è ambiguo anche sul largo, ma senza spazio per spiegazioni il problema emerge di più. Preferisci un formato adatto al pubblico e fornisci fusi o contesto delle date relative quando influiscono sul compito.

Usa unità coerenti nelle colonne numeriche. Un conteggio commenti non dovrebbe condividere il campo con uno stato testuale salvo spiegazione nell’intestazione e nel formato. Allinea coerentemente i numeri per facilitarne il confronto. Non ridurre precisione o unità solo sullo stretto senza chiederti se conservino lo stesso senso.

Decidi come rappresentare dati vuoti. «Non assegnato», «Nessun commento» e «Non disponibile» descrivono stati diversi; una cella bianca no. Un responsabile non assegnato non dovrebbe avere lo stesso aspetto di un campo che non si è caricato.

Le etichette lunghe dovrebbero poter andare a capo quando questo ne preserva il significato. I tooltip possono aggiungere contesto, ma non sostituiscono bene un’etichetta necessaria che l’utente deve ritrovare più volte. Se il titolo di una colonna è troppo lungo in ogni configurazione, valuta una formulazione più precisa prima di troncarlo.

Il tutorial W3C spiega che intestazioni e dati richiedono markup strutturale e associazioni appropriate. Aiutano a navigare mantenendo contesto oltre l’allineamento visivo. Segui la guida nell’implementazione, soprattutto quando intestazioni di righe e colonne contribuiscono entrambe al significato. Tutorial W3C sulle tabelle accessibili.

Collega i controlli all’ambito corretto

L’ordinamento riguarda una raccolta, i dettagli un record e l’azione multipla i record selezionati. Questi ambiti restano distinti restringendo il layout. Comprimere ogni controllo nello stesso menu può rendere poco chiaro cosa cambierà l’azione.

Mantieni ogni azione di riga visivamente associata al suo record. Un menu all’estrema destra può uscire dalla vista durante lo scorrimento orizzontale. Se aprire il progetto è il compito principale, il nome del progetto può essere un link che offre un percorso stabile, lasciando nel menu le azioni meno frequenti. La disposizione migliore dipende da quale azione richiede accesso immediato.

La selezione richiede attenzione aggiuntiva. Una checkbox nella prima colonna fissa può essere comoda, ma non deve scalzare l’identità della riga. Con più record selezionati, mostra il conteggio e chiarisci se copra la pagina corrente o l’intero risultato filtrato. Il responsive non cambia silenziosamente questo significato.

Il controllo d’ordine dovrebbe spiegare la direzione attiva senza affidarsi solo a una freccia minuscola. Verifica che il campo ordinato resti comprensibile se la colonna è nascosta. A volte spostare la scelta in un controllo etichettato sopra la tabella è più chiaro di un’intestazione invisibile.

Esamina filtri e paginazione sullo stretto. La tabella può essere leggibile mentre la toolbar esce dalla pagina o i comandi diventano affollati. Appartengono allo stesso compito anche fuori dalla griglia. Prova il percorso completo dal trovare record all’agire su di essi.

Contenuti scomodi e compiti reali

Usa contenuti impegnativi: nome lungo, responsabile non assegnato, molti commenti, data assente e stato a capo. Includi righe sufficienti a richiedere movimento nella direzione supportata. Tre record perfettamente uniformi rivelano pochissimo.

Nella versione scorrevole, chiedi a chi revisiona di associare una scadenza lontana al nome del progetto dopo essersi spostato lateralmente. Nella versione espandibile, chiedi di trovare un dettaglio e poi proseguire con il record successivo. Nelle schede impilate, chiedi di confrontare uno stesso valore fra più progetti. Questi compiti rivelano se la relazione conservata dal layout è davvero quella di cui l’utente ha bisogno.

Testa lo zoom del browser oltre alle larghezze dei dispositivi. Un utente desktop che ingrandisce può incontrare lo stesso vincolo per un motivo diverso. Controlla che testo resti leggibile, comandi raggiungibili e aree fisse non coprano la maggior parte dello spazio utile.

In OpenDesign puoi visualizzare un layout HTML di tabella nei diversi viewport predefiniti, aggiungere commenti a un’area troppo affollata e affinare testo o stili. Mantieni i record di esempio e il compito scelto nel contesto di progettazione. Verifica invece il markup semantico, lo scorrimento da tastiera, l’ordinamento e lo stato salvato nella tabella implementata.