Framework

Nel corso degli ultimi anni, abbiamo imparato come adattare i nostri layout alle infinite tele del web. I nostri design possono essere visualizzati su schermi di ogni dimensione, in ogni momento e il responsive design è un approccio che ci permette di gestire le forme variabili del web. Ma con tutte le sfide che stiamo affrontando e con quelle che verranno, dobbiamo cominciare a creare non solo dei pattern, ma dei principi per il responsive design, principi che ci permetteranno di concentrarsi non solo sul layout, ma sulla qualità del nostro lavoro.

Se ciascuna parte della nostra interfaccia responsive è più o meno autonoma, con le sue regole di layout, bisogni del contenuto e breakpoint, allora il codice dietro al design di ciascun elemento è molto meno importante del pensare attentamente al come e al perché si dovrebbe adattare un elemento. In altre parole, in che modo possiamo andare oltre il modo di ragionare in colonne e righe e cominciare a parlare della qualità dei nostri design responsive? E come dovrebbero essere i framework che supportano tutto questo?

Trovare le parole#section1

Onestamente, non c’è una risposta perfetta a questa domanda, ma, recentemente, un certo numero di designer e aziende hanno cominciato a condividere il vocabolario che usano per decidere in che modo e quando debbano adattare i propri design responsive. Per esempio, Vox Media pensa che il proprio contenuto esista all’interno di un fiume e, portando avanti la metafora, lo scorrere di tale contenuto possa essere interrotto in alcuni punti. Ecco come descrivono la front page di Vox.com:

Il contenuto scorre attorno a delle “rocce” in “ondate”, che sono moduli come potrebbe esserlo un elenco “Most Commented” o una riga di “Popular Videos”. Molti di questi comportamenti rimangono nel nuovo layout del sistema, ma la differenza principale è il livello di contesto aggiunto. Gli elementi nel fiume sono disposti in maniera da sottolineare meglio la diversità di contenuti su Vox: articoli, features, video, app editoriali, card stacks, giusto per nominarne alcuni. Ciascuno di questi viene mostrato in maniera diversa a seconda del suo tipo e dei contributi vicini.

Notate come il linguaggio che usano per parlare della qualità dei loro layout non ruota attorno a colonne o righe. Non c’è nemmeno una menzione alle griglie. Per Vox, il processo di design comincia con il dare priorità al contenuto ed evolve in un layout. Comprendendo il peso e l’importanza di ciascuna parte del contenuto che scorre nel fiume, il team di Vox può generare algoritmicamente un layout responsive che riflette l’importanza dell’informazione al suo interno.

Cominciare con un sistema astratto di colonne e righe sarebbe sbagliato per loro e, direi, per tutti i web designer. Dopo tutto, secondo Mark Boulton, ci sono tre benefici fondamentali in un grid system:

• I grid system creano connessioni. Una griglia ben fatta può connettere visivamente pezzi di contenuto correlati tra loro o, in maniera altrettanto importante, separare tra loro elementi non collegati. In altre parole, ci aiutano a creare delle narrazioni partendo dal layout.
• Stabilendo dei punti di allineamento predefiniti, i grid system aiutano i designer a risolvere problemi di layout.
• Un grid system ben progettato fornirà dei percorsi visuali che gli occhi dei lettori potranno seguire e permetterà loro di comprendere meglio la gerarchia visuale.

Come fa notare Boulton, storicamente abbiamo creato dei grid system adottando un metodo “canvas in”. Lavorando dai bordi di una pagina stampata, i designer suddividevano una pagina in un sistema di colonne e righe, e sistemavano le immagini e il testo sulla griglia in maniera piacevole, facendo aggiustamenti razionali. Ma il web non ha questi confini: dopo tutto, è il primo vero medium fluido nel design. Come risultato, Boulton sostiene che dovremmo invece adottare un approccio “content out” per progettare le nostre griglie: creare sistemi di layout più complessi partendo da pezzi di contenuto piccoli e modulari come base. E per fare ciò, Boulton propone tre principi guida:

• Definite le relazioni partendo dal contenuto. Una griglia per il web dovrebbe essere definita dal contenuto, non dai limiti di una pagina immaginaria.
• Usate rapporti o misure relazionali piuttosto che misure fisse.
• Legate il contenuto al device. Usate le media query CSS e tecniche quali il responsive web design per creare layout che reagiscano alla viewport.

Comprendendo la forma del nostro contenuto, possiamo creare layout flessibili che supportino la connessione, non solo tra pezzi di informazione collegati, ma tra i layout e il device. Possiamo creare grid system responsive che non solo vanno bene per un numero sempre più grande di schermi, ma che sembra che siano stati creati ad hoc ovunque li si guardi.

Trovare le linee#section2

Ovviamente i principi sono meravigliosi ma dobbiamo ancora trovare un modo per implementarli, per tradurre questi ideali in pattern pratici e layout responsive. Per me, questo processo “content out” comincia osservando la versione più piccola di un pezzo di contenuto, poi espandendo tale elemento finché cominciano a vedersi le sue linee e comincia a perdere la sua forma. Quando succede, ho l’opportunità di fare un cambiamento: introdurre un breakpoint che ridia forma all’elemento e ne preservi l’integrità.

Ma prima, abbiamo bisogno di un metodo per trovare le linee di un elemento e comprendere come perda la sua forma. Per me, questo processo comincia con l’osservare quattro caratteristiche: larghezza, gerarchia, interazione e densità.

Larghezza#section3

La larghezza potrebbe sembrare un po’ troppo auto-esplicativa. Al cambiare della larghezza di una viewport, deve cambiare la larghezza di un design responsive. Ma quando il design diventa troppo largo o troppo stretto, devono diventarlo anche gli elementi al suo interno e man mano che questi moduli si espandono o si contraggono, potrebbero esserci delle opportunità per aggiungere un breakpoint.

Nel suo impressionante portfolio responsive, Meagan Fisher aggiusta la tipografia di certi elementi, non solo il loro layout, a seconda che la loro larghezza aumenti o diminuisca.

Gerarchia#section4

Sono sicuro che sarete d’accordo nell’affermare che la larghezza è la caratteristica più comune di un design responsive, ma non è la sola. Al cambiare della forma di un elemento, potrebbe essere necessario cambiare anche la gerarchia degli elementi.

Diamo una rapida occhiata a una pagina prodotto sul sito ecommerce responsive di Tattly. Quando lo si guarda su schermi più grandi, l’area di contenuto primaria ha due pezzi di informazione: un carosello di foto del prodotto sulla sinistra e una call to action per l’acquisto del prodotto sulla destra.

Sul sito di ecommerce responsive di Tattly, il contenuto prodotto viene disposto in una piacevole griglia a due colonne sugli schermi più grandi.

Ma questa è solo una visualizzazione di questa particolare parte del design, perché quando gli schermi diventano più stretti, perdiamo l’abilità di sistemare più colonne l’una accanto all’altra. Qui è dove sorge la questione della gerarchia: in un layout a colonna singola, quale pezzo di contenuto deve apparire prima? Tattly ha optato, piuttosto correttamente, per usare le foto del prodotto come guida, ma voi potete rispondere in maniera diversa alle domande sulla gerarchia sul vostro sito.

Nelle viewport più strette, la gerarchia delle informazioni sul prodotto cambia da due a una colonna.

La gerarchia è generalmente un reminder per essere più coscienti della dimensione verticale nei nostri design. Dopo tutto, abbiamo le media query min-width e max-width, ma possiamo anche avvalerci più spesso delle query min-height e max-height. Penso che il menu di navigazione di Field Museum bilanci meravigliosamente i layout verticale ed orizzontale.

La navigazione responsive d Field Museum, che occupa l’altezza del design. Sotto a una certa larghezza, la navigazione si sposta dalla cima dello schermo per evitare il cropping.

Su schermi più grandi, la navigazione è ancorata al lato sinistro del design e si espande per tutta l’altezza della viewport. Potete notare che stanno usando il flexible box model o flexbox, un metodo di layout CSS avanzato che vedremo più avanti in questo capitolo. Ma dal momento che flexbox permette agli elementi di riempire automaticamente lo spazio a loro disposizione, man mano che il menu diventa più alto o più basso, gli elementi della navigazione si ridimensionano verticalmente, ma sotto una certa larghezza o altezza, il menu è posto in cima alla pagina.

Prestando attenzione ai bordi verticali della navigazione, Field Museum è stato in grado di introdurre layout alternativi per essere sicuro che il contenuto all’interno del loro menu di navigazione non fosse mai celato, oscurato o troncato. In altre parole, i breakpoint che introduciamo nei nostri design responsive non sono legati alla forma dello schermo di un device. Al contrario, le nostre media query difendono l’integrità del contenuto che stiamo progettando.

Interazione#section5

Il modo in cui interagiamo con un elemento può cambiare con il design. I sistemi di navigazione responsive sono probabilmente l’esempio più ovvio di questo. Come abbiamo visto nel Capitolo 2, i menu vengono spesso mostrati per intero nei breakpoint più larghi, ma vengono celati in quelli più piccoli, magari nascosti dietro a icone espandibili o a link quando lo spazio è scarso.

Il sito dell’azienda di Karen McGrane ha una navigazione dall’aspetto tradizionale nei breakpoint più larghi, ma sulle viewport più strette l’utente attiva la visibilità del menu. Stessi link, ma con un nuovo modello di interazione.

Ma la navigazione non è il solo tipo di contenuto che potrebbe richiedere dei cambi di interazione. Per esempio, prendete i tornei sportivi responsive progettati da SB Nation. Mentre appaiono come grafici dall’aspetto complesso nei breakpoint più grandi, viene mostrata una visuale più semplice e più lineare dei tornei sugli schermi più piccoli.

Non so nulla di sport, ma so che mi piace la visualizzazione responsive dei tornei di SB Nation: grafici complessi su grandi schermi, ma un carosello sulle viewport più piccole. Stesse informazioni, diverse interazioni.

Insieme al layout semplificato, i tornei vengono presentati come caroselli nelle visualizzazioni più piccole, in cui lo spazio è prezioso. Ognuna delle quattro regioni per il torneo è una singola slide nel carosello, permettendo all’utente di muoversi in un ciclo per i dettagli. L’informazione in entrambe gli stati visuali è la stessa ma cambia il modello di interazione.

Densità#section6

Infine, la quantità di informazione che mostrate in un elemento potrebbe dover variare nel tempo. In altre parole, potrebbe cambiare la densità dell’informazione. La feature del Guardian sugli Oscar del 2015 ne è un esempio completo, con timeline progettate in maniera responsive che mostrano una quantità di dati significativa sui film. Sopra a una certa larghezza, vengono caricate le immagini thumbnail, aumentando leggermente la densità visuale (e informativa) della timeline.

Le timeline cinematografiche responsive del Guardian crescono gradualmente in densità, mostrando un’immagine extra sopra ad una certa larghezza.

La densità è, come potreste aver indovinato, un’area in cui dovreste camminare molto attentamente. Come abbiamo discusso prima, rimuovere o nascondere informazioni perché non ci stanno può essere problematico.

Tattly nasconde completamente i suoi sotto-menu, riducendo la sua navigazione a una lista di sezioni primarie sugli schermi più piccoli.

Personalmente, penso che le timeline del Guardian funzionino così bene perché le immagini mostrate nei breakpoint più larghi sono degli enhancement: non sono critici per la comprensione delle informazioni attorno ad essi. Avrebbero potuto progettare versioni alternative delle timeline che mostrassero immagini a tutti i breakpoint? Penso di sì, ma ritengo che questo sia un esempio meraviglioso di densità usata per alleggerire l’impatto visuale di un design, rimuovendo informazioni estranee senza impedire l’accesso al contenuto.

Illustrazioni: {carlok}