No. 104

Nota degli editori: Siamo lieti di presentarvi un estratto dal Capitolo 7 di Responsive Design Workflow, il nuovo libro di Stephen Hay, disponibile in questo momento da New Riders.

Jeremy Keith fa notare che quello che succede tra i breakpoint è tanto importante quanto i breakpoint stessi, anzi, forse lo è addirittura di più. Sebbene io mi trovi d'accordo con questa affermazione, si deve pur cominciare da qualche parte. Per certi versi, questa parte del processo mi fa venire in mente la realizzazione di storyboard o la creazione di keyframe d'animazione, in cui i frame che si trovano tra questi "punti" verranno sviluppati in seguito. Qui faremo proprio questo.

I breakpoint principali sono condizioni che, una volta soddisfatte, attivano dei cambiamenti considerevoli nel proprio design. Un breakpoint principale potrebbe essere, ad esempio, dove l'intero layout passa da due colonne a quattro.

Supponiamo di aver scelto tra direzioni base del design dalle nostre thumbnail. Pensiamo a come appariranno questi breakpoint principali (Figura 7.6); qui sta il concetto principale: cercare di avere il minimo numero possibile di breakpoint principali. Potrebbe sembrare pazzesco, dal momento che stiamo parlando di responsive web design, dopo tutto, abbiamo le media query, quindi perché non usarne 12? No! Se un layout lineare funziona su ogni schermo ed è appropriato in particolare per il vostro concept, allora non c'è proprio bisogno di layout differenti. In quel caso, descrivete semplicemente quello che succederà quando lo schermo diventerà più largo. Cosa succede in generale? Rimarrà tutto uguale con dei cambiamenti relativi solo alla dimensione del font, alla line height e ai margin? Se sì, fate uno sketch di queste cose. Per queste variazioni, fate prima delle thumbnail, esplorate alcune opzioni e poi spostatevi su schizzi più grandi e con maggiori dettagli. Usate il vostro grafico dei breakpoint come guida all'inizio e fate degli schizzi a seconda dei breakpoint che avete individuato sul vostro grafico.

Quando pensate ai breakpoint più importanti, ricordatevi di pensare alle classi di device. Se state pensando a smartphone, tablet, laptop/desktop, TV e console di gioco, per esempio, vi state muovendo nella giusta direzione. Se state pensando in termini di nomi di brand e di specifici sistemi operativi, siete sulla strada sbagliata. L'idea è quella di pensare in termini di classificazioni generiche dei device e, a volte, di capacità dei device. Le capacità sono molto più importanti quando si progettano applicazioni web, dal momento che dovreste pensare a come appariranno gli schermi con e senza alcune particolari capacità.

Gli sketch rapidi dei breakpoint principali possono aiutarvi a determinare:

  • se c'è bisogno di più breakpoint o meno.
  • quale scelta di design sarà quella che richiede una maggior quantità di lavoro; potreste decidere di optare per un design che si adatti meglio ai vincoli di tempo e budget.
  • Se una particolare classe di device è stata dimenticata o ha bisogno di più considerazione.
  • Che tecnologie saranno necessarie per sviluppare il design in maniera responsive.
Gli schizzi rapidi sono più dettagliati delle thumbnail, ma non dovreste metterci molto tempo a crearli. In un breve lasso di tempo, dovreste avere uno sketch di ogni principale breakpoint per ciascuno dei design che avete scelto. Questo dovrebbe essere sufficiente per decidere per uno dei design.

Figura 7.6: la maggior parte dei siti web ha bisogno di pochi breakpoint principali.

I breakpoint meno importanti sono condizioni che, quando vengono soddisfatte, attivano cambiamenti minori nel vostro design. Un esempio potrebbe essere quello di spostare i label delle form da sopra i campi di testo alla sinistra di questi ultimi, mentre il resto del design rimane invariato.

Quindi, dove e quando si devono fare degli schizzi per i breakpoint meno importanti? Nel browser, quando fate il mockup web-based. Scoprirete perché e in che modo nel prossimo capitolo. Nel frattempo, concentriamoci semplicemente sul fare schizzi dello stato delle proprie pagine web o delle schermate dell'app rispetto ai breakpoint più importanti per ciascun design.

A questo punto, non preoccupatevi troppo se notate che i breakpoint iniziali sul vostro grafico dei breakpoint semplicemente non vanno bene. Quelli erano solo dei punti di partenza e siete liberi di rivedere le vostre stime basandovi sui vostri sketch. Potreste perfino decidere di aver bisogno di un breakpoint extra per un certo design e registrarlo sotto forma di schizzo. Potete aggiungere questo breakpoint al vostro grafico. Si tratta di un ciclo di scoperta, apprendimento e revisione.

Pensate al vostro contenuto mentre realizzate gli sketch

Mentre fate gli schizzi di prova, certamente penserete al modo in cui appariranno le cose. La mia esperienza è che la gran parte dell'UI sketching di questo tipo gira attorno il layout degli elementi sullo schermo. Trovo utile continuare a pensare al contenuto durante la fase di sketching e considerare cosa accadrà al contenuto nelle diverse situazioni. Quando si progetta in maniera responsive, può essere utile considerare il modo in cui gestirete in particolare il seguente contenuto:

  • Testo
  • Navigazione
  • Tabelle

Oh, sicuramente, ci saranno molte altre cose da considerare e finirete con il creare la vostra lista di "cose a cui pensare ancora un po'" man mano che il progetto avanza. Per ora, diamo un'occhiata ai tipi elencati qui sopra.

Testo

Prima che diciate "Hey, aspetta un attimo, non mi hai appena detto che non devo disegnare il testo mentre faccio gli sketch?", ascoltatemi fino in fondo. Mentre fate gli sketch, ci sono un paio di questioni legate al testo che dovrete affrontare: la larghezza della colonna e la dimensione del testo, entrambe le quali sono rilevanti in proporzione allo schermo e agli altri elementi sulla pagina.

La larghezza delle colonne è piuttosto ovvia, ma può essere difficile stimare quanto sarà larga una colonna con il testo reale. In questo caso, fare degli sketch su un device potrebbe darvi un'idea migliore dello spazio reale con cui dovrete lavorare. Un altro metodo che ho usato è quello di fare una semplice pagina HTML che contenga solo testo e lo carichi nel browser del device (o anche un emulatore, che, seppur non ottimale, dà pur sempre un'impressione più realistica delle righe sulla carta). Quando il testo sembra troppo grande o troppo piccolo, potete aggiustare di conseguenza la dimensione del font. Una volta che vi sembra corretto, sarete in grado di rendere un po' più realistici i vostri schizzi.

Nota: Distringuete tra "toccabilità"(touchability) e "cliccabilità" (clickability). Molti designer, me incluso, hanno fatto l'errore di raffinare i link per le persone che ci cliccano con un mouse o addirittura con la tastiera, senza considerare quanto "toccabili" siano questi link per le persone che utilizzano device touch.

Pensate alla dimensione dei link, non solo alla dimensione del testo, ma anche alla quantità di spazio attorno a loro. Entrambe questi fattori giocano un ruolo nella touchability o clickability dei link (e dei pulsanti): link e pulsanti grandi sono degli obiettivi più facili, ma link leggermente più piccoli con molto spazio tra loro possono funzionare altrettanto bene. Detto cil, c'è una discreta probabilità che non importa cosa scegliate di abbozzare, finirete col fare dei cambiamenti ancora quando creerete i mockup.

Questo è l'aspetto positivo degli sketch e che non ripeterò mai abbastanza: raffinerete comunque il vostro design nel browser, perciò la velocità con cui proverete le cose quando fate gli sketch implica che non dovrete fare un lavoro dettagliato più di una volta (a meno che il vostro cliente abbia dei cambiamenti da fare, ma sappiamo tutti che non accade mai).

Navigazione

La navigazione è un altro esempio di elemento di cui fare sketch sui device veri. Le questioni delle dimensioni sono le stesse dei link, ma ci sono molte più cose a cui pensare in termini di design della navigazione per i vari device, il che vuol dire che la navigazione potrebbe cambiare in maniera significativa a ciascun breakpoint principale.

Ripensiamo alla pratica di Bryan Rieger di progettare prima nel testo e di riflettere su quello che faremmo prima del primissimo breakpoint se avessimo sono del semplice HTML e CSS a nostra disposizione, ossia, se non avessimo JavaScript. Questo significa che non si può avere un menu "collassabile" in cima allo schermo e dargli un effetto drop down quando qualcuno lo tocca. Se il vostro menu si trova in cima, è nella sua forma espansa e occupa tutto lo spazio verticale che occuperebbe normalmente.

Si tratta di un argomento abbastanza controverso, che vede in disaccordo anche i guru dell'accessibilità: JavaScript, dopo tutto, è attualmente considerato come una tecnologia che "supportata dall'accessibilità", ma questo non riguarda necessariamente l'accessibilità, quanto piuttosto pensare a cosa succede quando un browser non supporta JavaScript o se la versione di JavaScript disponibile sul device è diversa da quello che vi aspettereste. Il vostro contenuto sarà presentato in un certo modo prima che JavaScript ci lavori su, indipendentemente dal browser. Quindi, perché non pensiamo a quale sarà lo stato iniziale?

Nel capitolo sui wireframe, ho parlato del mio pattern preferito per la navigazione sugli schermi più piccoli: lasciarla sul fondo dello schermo e mettere un link a quella navigazione vicino al top dello schermo. JavaScript, quando è disponibile e funziona come ci aspetteremmo, può spostare quella navigazione fino al top e creare un menu drop-down al volo.

Ma un pattern non è una legge del design, quindi il modo in cui decidete di gestire gli schermi più piccoli dipende dal vostro progetto. Se avessi solo pochi link nella mia navigazione, potrei benissimo mettere il menu in cima fin dall'inizio e ci starebbe per ogni breakpoint.

Ricordatevi che JavaScript e CSS vi permettono di risistemare molte cose sullo schermo. Questa conoscenza dovrebbe darvi il potere di progettare in maniera sicura una gran pagina con del semplice HTML ed usare JavaScript e CSS per ravvivarlo come vogliamo. Questa è l'essenza del progressive enhancement.

Tabelle

Tabelle! Oh, la disgrazia del responsive designer (no, aspettate, non erano le immagini? O i video? O i layout? Ehm...). È difficile gestire le tabelle su uno schermo piccolo. Mi piacerebbe dirvi che ho tutte le risposte, ma al contrario, ho più domande che risposte. Spero che vi portino a una soluzione. Va bene pensare a queste durante la fase di sketching.

Per prima cosa, con che tipo di tabelle avrete a che fare? Piccole? Grandi? Numeriche? Testuali? L'inventario del contenuto dovrebbe darvi sufficienti informazioni per rispondere a queste semplici domande. Una volta che le avrete prese in considerazione, provate a categorizzare i tipi di tabelle che avete in qualcosa come le classi seguenti (Figura 7.7):

  • Piccole tabelle "screen-friendly", che probabilmente lascerete così come sono perché sono sufficientemente piccole e funzioneranno bene sulla maggior parte dei piccoli schermi.
  • Tabelle che possono essere rese come blocchi, che potete modificare con CSS così che ciascuna riga nella tabella funga visivamente da block item in una lista (Figura 7.8).
  • Tabelle che possono essere rese come grafici, che contengono certi dati numerici che possono essere trasformati in un grafico, un diagramma o in un'altra visualizzazione che occuperà meno spazio su un piccolo schermo.
  • Tabelle difficili, che sono sufficientemente difficili da gestire, tanto che avrete bisogno un altro piano per gestirle, a volte addirittura su una base caso-per-caso. Questo sono le nostre nemiche, ma sfortunatamente, sono amiche dei nostri clienti, che amano tutti Microsoft Excel. Va beh.

Figura 7.7: Ci sono svariati tipi di tabelle e diversi modi per gestirle sui piccoli schermi. (Fonte: mobilism.nl e eu-verantwoording.nl)

Figura 7.8: Un modo per gestire le tabelle su piccoli schermi è quello di trattare ogni riga come un blocco.

Pensando ancora in termini di progressive enhancement, il design di base dovrebbe probabilmente includere l'intera tabella, il che significa che, in molti casi, l'utente dovrà fare uno scroll orizzontale per visualizzarne tutto il contenuto. Oltre a ciò, possiamo utilizzare CSS e JavaScript quando sono disponibili, per usare un po' di magia. Le tabelle che possono essere rese come blocchi e grafici possono essere rese come blocco con CSS e come grafico con JavaScript. Molti designer e developer hanno sperimentato varie opzioni per le tabelle, dal rendere semplicemente scrollabile la tabella fino allo scambio di righe con colonne.

La parte divertente è che quello che fate su uno schermo piccolo non è necessariamente quello che farete sugli schermi più grandi. È il motivo per cui ora, quanto tutto quello che dovete fare è uno schizzo che non vi prenderà molto tempo, è il momento giusto per pensare ai cambiamenti che farete ad ogni breakpoint.

Cosa fare se ci si blocca

Tutti i designer prima o poi si bloccano. Non è un grande problema a meno che non lo trattiate come tale. Ci sono innumerevoli modi per gestire un blocco, dal porvi delle domande del tipo e se ("E se non ci fosse una tabella ma una lista?" è quello che mi sono chiesto prima di sbloccarmi sulla tabella dei partecipanti per il sito Mobilism) fino al cliché del farsi una doccia, che spero vi facciate regolarmente, comunque. La ragione per cui questo capitolo si concentra così tanto sul fare schizzi è perché l'atto stesso del disegnare può in effetti stimolare il cervello affinché se ne esca con più idee, a condizione che vi spremiate le meningi così tanto da fare sketch al di fuori della vostra "comfort zone" delle prime idee che vi saltano in mente.

Se il vostro problema è un blocco creativo, ci sono molti libri e risorse a cui ispirarsi per far partire il vostro motore creativo durante il gelo del blocco del designer. Sebbene ci siano moltissime risorse sul design e sulla creatività stessa (provate un classico come quello di Edward de Bono Lateral Thinking), la più grande ispirazione può arrivare da fonti al di fuori dello spazio del design.1 Cercare di combinare cose che normalmente non stanno insieme può portare a risultati sorprendenti. È un trucco semplice, ma spesso ho usato le Oblique Strategies di Brian Eno e Peter Shmidt per forzarmi ad avere un approccio diverso.2 Nel caso peggiore, vi divertirete moltissimo. Nel caso migliore, avrete una grande idea!

Se il vostro problema è che non siete sicuri su come gestire qualcosa nel contesto del responsive design, non c'è niente di male nel cercare come gli altri hanno risolto dei problemi come il vostro. Assicuratevi solo di usare la vostra creatività e di adattare alla vostra situazione qualsiasi idea potreste trovare: dopo tutto, siete designer! Al momento in cui scrivo, trovo This Is Responsive di Brad Frost una delle collezioni e delle risorse più esaustive dei pattern di responsive web design disponibili.3 Potete passare ore sfogliandole e troverete sicuramente qualcosa che vi sbloccherà.

Tratto da Responsive Design Workflow di Stephen Hay, Copyright © 2013.
Riprodotto con il permesso di Pearson Education, Inc. e New Riders.

Share/Save/Bookmark
 

Discutiamone

Ti sembra interessante? Scrivi tu il primo commento


Cenni sull'autore

Stephen Hay

Stephen Hay è un consulente front-end designer and developer che vive nei Paesi Bassi. È l'autore di Responsive Design Workflow (Peachpit/New Riders 2013), è stato contributor per lo Smashing Book #3 e parla frequentemente alle conferenze. Quando non lavora fino ad ammazzarsi per il suo studio di consulenze, Zero Interface, apprezza la buona birra Belga e scrive sul suo blog circa due volte l'anno su the-haystack.com.