![](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2012\/11\/n63grid-web.png\")
I grid system sono uno strumento fondamentale della grafica, ma sono sempre stati progettati per oggetti con dimensioni fisse. Finora. Oggi progettiamo per un medium che non ha dimensioni fisse, che \u00e8 in grado di cambiare forma per meglio adattarsi all’ambiente, un medium capace di mostrare un unico layout su uno smartphone, su un cartellone a Times Square e su tutto quello che si trova tra questi due estremi.<\/p>\n
Progettiamo per una tela infinita e perci\u00f2 abbiamo bisogno di grid system infiniti.<\/p>\n
Solitamente si pensa al responsive layout come ad un insieme di layout: mobile, tablet, desktop, etc. Il problema sono le dimensioni tra i vari layout: si finisce con l’avere dei layout fantastici a dimensioni specifiche (320, 720, 960), ma che lo sono molto meno a tutte le altre dimensioni. Quindi, anche se un sito pu\u00f2 sembrare perfetto sul vostro iPhone 4 a 640×960, apparir\u00e0 un po’ strano sul Nokia Lumia (480×800) di un visitatore o nella finestra del browser a 685×308 che tenete aperta sul vostro computer desktop. Potrebbe sembrare distorta anche sul nuovissimo iPhone 5 (640×1136) che tuo cugino ha appena comprato, per non parlare degli infiniti e meno popolari altri device che si trovano in giro.<\/p>\n
All’aumentare dello spettro delle risoluzioni dei device, sia per ampiezza sia per omogeneit\u00e0, concentrarci solo sulle “dimensioni chiave” di ogni pagina avr\u00e0 come conseguenza un’esperienza non all’altezza per sempre pi\u00f9 utenti. Al contrario, dobbiamo creare un grid system che adotti la mancanza di dimensioni fisse proprie di questo medium, volto ad ottenere un singolo layout con diversi stati che variano da uno all’altro in maniera trasparente e portano struttura al contenuto per qualunque dimensione di schermo.<\/p>\n
Le griglie sono semplicemente uno strumento per risolvere un problema in maniera visuale. Creare un layout \u00e8 come fare un puzzle: si ha un certo numero di pezzi e si deve capire come metterli insieme. Quando creiamo una griglia, creiamo dei confini per il layout: relazioni e vincoli noti che definiscono un ambiente all’interno del quale si pu\u00f2 trovare una soluzione appropriata. Ma quando costruiamo una griglia infinita<\/em>, non impostiamo solo i confini del layout, ma un sistema<\/em> per il layout con troppe variabili a cui far aderire tutto. Se definiamo le relazioni importanti, gli spazi vuoti si riempiranno da soli.<\/p>\n Perch\u00e9 una griglia sia utile, deve essere basata sulle cose che conosciamo. Nei media tradizionali, le dimensioni della pagina sono un vincolo noto, quindi ha senso che cominciamo con i bordi e definiamo le relazioni della griglia relative a quelli. Tuttavia, con il digitale non sappiamo quale sia la dimensione della pagina, perci\u00f2 questo vincolo non va troppo bene per essere il fondamento del nostro layout.<\/p>\n Dobbiamo invece basare la nostra costruzione su quello che effettivamente<\/em> conosciamo: il contenuto.<\/p>\n Per adottare i layout nativi del web, indipendentemente dal device, dobbiamo scrollarci di dosso la convinzione che possiamo creare dei layout solo a partire dal canvas. Dobbiamo capovolgere questa nozione e creare i layout a partire dal contenuto.<\/p>\n \u2014 Mark Boulton, \u201cA Richer Canvas”<\/a><\/cite><\/p>\n<\/blockquote>\n Quando progettiamo a partire dal canvas, le sue dimensioni sono la costante a cui si ancora la nostra griglia: tutto viene dimensionato e posizionato in base a quelle misure. Progettare a partire dal contenuto vuol dire trovare una costante nel proprio contenuto, che sia la misura ideale di un paragrafo o le dimensioni di una pubblicit\u00e0, e creare la propria griglia a partire da quella costante, per riempire tutto lo spazio disponibile.<\/p>\n Ora, i layout che si espandono fino a riempire lo spazio a disposizione non sono niente di nuovo, dopo tutto: i layout fluidi sono praticamente di default per il web, ma davvero pochi layout possono essere ingranditi o ristretti indefinitamente senza che si rompano le relazioni tra le loro componenti e qui \u00e8 dove entrano in gioco gli stati.<\/p>\n I layout fluidi vengono spesso paragonati all’acqua<\/a>, ma l’acqua non \u00e8 sempre fluida. L’H2<\/sub> ha tre stati differenti a seconda della temperatura: solido, liquido e gassoso. Passa senza strappi da uno stato all’altro a punti specifici (0\u00b0C, 100\u00b0C). Una griglia infinita ha pi\u00f9 stati (colonna singola, multi-colonna, etc.) e dovrebbe passare da uno all’altro di questi stati senza strappi e in punti precisi, come l’acqua. Per esempio, proprio come il ghiaccio \u00e8 uno stato appropriato per l’acqua quando la temperatura \u00e8 bassa, cos\u00ec un layout a singola colonna potrebbe essere lo stato appropriato per una griglia infinita sui device pi\u00f9 piccoli.<\/p>\n I cambiamenti di stato dell’acqua sono causati da un riposizionamento delle sue molecole. Quando una griglia infinita cambia stato, dobbiamo risistemare le sue componenti<\/em>.<\/p>\n Ciascuno stato nel responsive layout tende ad essere fatto con le stesse componenti, come una galleria di immagini o un menu di navigazione. Tuttavia, come ha recentemente sottolineato Ethan Marcotte<\/a>, la forma che assumono queste componenti pu\u00f2 variare radicalmente tra uno stato e l’altro, coinvolgendo di solito un cambiamento in uno o pi\u00f9 dei seguenti attributi:<\/p>\n Considerare quanto possano cambiare gli attributi di ciascuna componente tra i vari stati aiuta ad essere sicuri che il grid system produrr\u00e0 il layout pi\u00f9 adatto allo spazio disponibile. Osservato come le diverse componenti adattano la propria larghezza (fissa e flessibile) e posizione a seconda dei vari stati in questo esempio<\/a>.<\/p>\n<\/div>\n Sebbene stiamo solo cominciando a grattare la superficie del progettare griglie infinite, ci sono gi\u00e0 alcune tecniche utili. Per cominciare, ecco della linee guida:<\/p>\n Progettare una griglia vuol dire decidere cosa deve essere proporzionato a cosa. Quando scegliete un’unit\u00e0, legate una dimensione ad una particolare variabile:<\/p>\n Le unit\u00e0 assolute come i pixel danno effettivamente una data di scadenza al layout, bloccandolo a un range limitato di risoluzione nel quale “funziona”. Le unit\u00e0 proporzionali (em, rem e percentuali) permettono di definire relazioni<\/em> importanti tra gli elementi e sono un primo step cruciale sula strada verso l’indipendenza dalla risoluzione.<\/p>\n Ogni layout ha un range naturale “ottimale” per il suo contenuto. Quanto potete allargarlo prima che si cominci a sfaldare? Quanto potete ridurlo prima che cominci a collassare? Per esempio, se la larghezza disponibile \u00e8 minore di 45 caratteri per riga, il layout comincia ad apparire illeggibile. Se c’\u00e8 pi\u00f9 spazio bianco di una colonna su ciascun lato del layout, il contenuto comincia a sembrare schiacciato. Questi estremi variano per ogni design, in stretta dipendenza dal contenuto.<\/p>\n Pensare prima agli estremi obbliga a considerare il miglior modo per rappresentare il proprio contenuto ai due punti estremi delle spettro. Considerate la gerarchia, la densit\u00e0, l’interazione e la larghezza di ciascuna componente nello stato pi\u00f9 piccolo, poi fate lo stesso nello stato pi\u00f9 largo.<\/p>\n Per esempio, supponiamo che il mio stato pi\u00f9 largo sia di 75em (pi\u00f9 largo di cos\u00ec e lo spazio bianco comincia a rimpicciolire il contenuto) e il mio stato pi\u00f9 piccolo sia 34em (pi\u00f9 piccolo di cos\u00ec e la misura risulta molto meno che ottimale). Nello stato pi\u00f9 largo<\/a> ha senso che la navigazione sia una lista orizzontale (interazione) posizionata in alto (gerarchia), ma nello stato pi\u00f9 piccolo<\/a> potrebbe avere pi\u00f9 senso spostarla in basso al layout (gerarchia), o ridurla in una lista che si pu\u00f2 aprire e nascondere (interazione). Progettare questi aspetti indipendentemente gli uni dagli altri aiuta ad essere pi\u00f9 obiettivi su cosa funzioni meglio in ogni stato, piuttosto che far adattare un’unica soluzione ai vari stati.<\/p>\n Una volta che avete trovato una soluzione per gli estremi, \u00e8 tempo di considerare in che modo e dove uno stato dovrebbe fare una transizione verso un altro stato. Proprio come l’acqua si trasforma in vapore quando le sue molecole si allontanano troppo, uno stato dovrebbe cambiare in un altro quando le relazioni tra le sue componenti cominciano a non funzionare pi\u00f9, come ad esempio quando la misura diventa troppo larga, o il logo allineato a sinistra \u00e8 cos\u00ec lontano dal menu allineato a destra che sembra che non ci sia alcuna connessione visuale tra i due.<\/p>\n Qui \u00e8 dove i prototipi “live” vengono comodi. \u00c8 incredibilmente difficile predire esattamente a quale larghezza (in relazione al contenuto) un layout abbia bisogno di cambiare da uno stato a un altro. Un prototipo vi permette di ridimensionare il browser per trovare il punto esatto<\/em> in cui le relazioni non funzionano pi\u00f9, cos\u00ec che possiate aggiungervi un breakpoint. Alcuni nuovi strumenti (come Gridset<\/a> e Responsive.is<\/a>) rendono pi\u00f9 semplice che mai creare e testare i prototipi responsive, quindi non avete pi\u00f9 alcuna scusa per non farlo.<\/p>\n Il numero di stati che richiedete dipender\u00e0 da quanto cambia il layout da un estremo all’altro. Per esempio, il mio stato pi\u00f9 piccolo ha una singola colonna e un menu “collapsed” e il mio stato pi\u00f9 largo ha tre colonne e un menu espanso. Tuttavia, nessuno dei due stati sembra a posto tra i 34em e i 53em, cos\u00ec ho aggiunto uno stato \u201cnel mezzo\u201d<\/a> che mantiene la singola colonna per “article” dello stato pi\u00f9 piccolo, ma espande il menu e divide il footer in tre colonne per utilizzare al meglio lo spazio disponibile. Questo fa s\u00ec che la transizione da un estremo all’altro sia pi\u00f9 fluida.<\/p>\n Ricordatevi di riconsiderare la gerarchia, la densit\u00e0, l’interazione e la larghezza di ciascuna componente ad ogni cambiamento di stato. Pu\u00f2 essere cha la colonna con il contenuto principale debba avere una larghezza fissa adesso per essere sicuri che la misura non diventi troppo grande o che abbiate spazio per aggiungere pi\u00f9 informazione (densit\u00e0) alla navigazione?<\/p>\n Quindi adesso abbiamo un layout responsive con pi\u00f9 stati che passano dal pi\u00f9 piccolo al pi\u00f9 grande in maniera fluida. Ma si tratta solo dell’intervallo tra i 34 e i 75em. Cosa succede quando lo spazio disponibile \u00e8 pi\u00f9 piccolo o pi\u00f9 grande di quegli stati? Come otteniamo un layout che va davvero da 0 all’infinito?<\/p>\n Lo spazio \u00e8 prezioso nella zona pi\u00f9 piccola della scala, quindi dobbiamo ottenere il massimo da quello che abbiamo. Per le dimensioni sotto ai 20em<\/a>, ho ridotto (ma non rimosso) i margini, diminuito la line height e indentato gli elenchi puntati. Praticamente, ho fatto quello che posso per ottimizzare la leggibilit\u00e0, anche se ho una quantit\u00e0 meno che ottimale di spazio a disposizione.<\/p>\n Dal lato opposto della scala, il problema \u00e8 che c’\u00e8 troppo spazio<\/em>, in particolare troppo “whitespace”. Il contenuto appare in questo caso schiacciato, quindi dobbiamo trovare dei modi per bilanciarlo. Sfortunatamente, ampliare semplicemente un layout indiscriminatamente non funziona sempre, perch\u00e9 cominciano ad apparire i problemi legati alla leggibilit\u00e0 causati dalle grandi dimensioni. Se aumentate la dimensione del testo per mantenere circa sessanta caratteri per riga, ma il carattere \u00e8 cos\u00ec grande che si deve in effetti muovere la testa per poter leggere, allora non si tratta di una buona esperienza.<\/p>\n Al contrario, cercate elementi come gli header, i divisori o le immagini che potete ingrandire con il canvas, che aiutano ad ancorare un layout visivamente senza rovinarne la leggibilit\u00e0. Nel mio esempio<\/a>, l’elemento righello che si allarga a larghezza piena aiuta ad “ancorare” il design al whitespace e a 75em comincio ad ingrandire gli elementi relativamente alla dimensione della viewport usando le unit\u00e0 VW. Il corpo del testo comincia a diventare scomodo a 90em, pertanto uso le unit\u00e0 rem per tenerlo a una dimensione di lettura comoda mentre gli altri elementi si ridimensionano attorno ad esso.<\/p>\n In entrambe i casi, l’obiettivo \u00e8 quello di sfruttare al meglio lo spazio a disposizione, relativamente al contenuto, per massimizzare la leggibilit\u00e0 e la presentazione.<\/p>\n<\/div>\n\n
Stati<\/h3>\n
Componenti<\/h3>\n
\n
\nProgettare un grid system infinito<\/h2>\n
1. Usate unit\u00e0 proporzionali<\/h3>\n
\n
2. Cominciate dagli estremi, poi lavorate su quello che c’\u00e8 in mezzo<\/h3>\n
3. Cambiate stato nei punti in cui le relazioni non funzionano pi\u00f9<\/h3>\n
4. Andate oltre gli estremi<\/h3>\n