{"id":386,"date":"2013-06-25T17:16:51","date_gmt":"2013-06-25T15:16:51","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/progettare-per-i-breakpoint\/"},"modified":"2013-06-25T17:16:51","modified_gmt":"2013-06-25T15:16:51","slug":"progettare-per-i-breakpoint","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/progettare-per-i-breakpoint\/","title":{"rendered":"Progettare per i breakpoint"},"content":{"rendered":"<div class=\"paragrafo\">\n<p class=\"editors-note\"><strong>Nota degli editori:<\/strong> Siamo lieti di presentarvi un estratto dal Capitolo 7 di <cite><a href=\"http:\/\/www.peachpit.com\/store\/responsive-design-workflow-9780321887863\">Responsive Design Workflow<\/a><\/cite>, il nuovo libro di Stephen Hay, disponibile in questo momento da New Riders.<\/p>\n<p>Jeremy Keith fa notare che quello che succede tra i breakpoint \u00e8 tanto importante quanto i breakpoint stessi, anzi, forse lo \u00e8 addirittura di pi\u00f9. Sebbene io mi trovi d&#8217;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&#8217;animazione, in cui i frame che si trovano tra questi &#8220;punti&#8221; verranno sviluppati in seguito. Qui faremo proprio questo.<\/p>\n<div class=\"supplement\">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&#8217;intero layout passa da due colonne a quattro.<\/div>\n<p>Supponiamo di aver scelto tra direzioni base del design dalle nostre thumbnail. Pensiamo a come appariranno questi <strong>breakpoint principali<\/strong> (Figura 7.6); qui sta il concetto principale: <em>cercare di avere il minimo numero possibile di breakpoint principali<\/em>. Potrebbe sembrare pazzesco, dal momento che stiamo parlando di responsive web design, dopo tutto, abbiamo le media query, quindi perch\u00e9 non usarne 12? No! Se un layout lineare funziona su ogni schermo ed \u00e8 <em>appropriato<\/em> in particolare per il vostro concept, allora non c&#8217;\u00e8 proprio bisogno di layout differenti. In quel caso, descrivete semplicemente quello che succeder\u00e0 quando lo schermo diventer\u00e0 pi\u00f9 largo. Cosa succede in generale? Rimarr\u00e0 tutto uguale con dei cambiamenti relativi solo alla dimensione del font, alla line height e ai margin? Se s\u00ec, fate uno sketch di queste cose. Per queste variazioni, fate prima delle thumbnail, esplorate alcune opzioni e poi spostatevi su schizzi pi\u00f9 grandi e con maggiori dettagli. Usate il vostro grafico dei breakpoint come guida all&#8217;inizio e fate degli schizzi a seconda dei breakpoint che avete individuato sul vostro grafico.<\/p>\n<p>Quando pensate ai breakpoint pi\u00f9 importanti, ricordatevi di pensare alle <em>classi di device<\/em>. 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&#8217;idea \u00e8 quella di pensare in termini di classificazioni generiche dei device e, a volte, di capacit\u00e0 dei device. Le capacit\u00e0 sono molto pi\u00f9 importanti quando si progettano applicazioni web, dal momento che dovreste pensare a come appariranno gli schermi con e <em>senza<\/em> alcune particolari capacit\u00e0.<\/p>\n<p><strong>Gli sketch rapidi<\/strong> dei breakpoint principali possono aiutarvi a determinare:<\/p>\n<ul>\n<li>se c&#8217;\u00e8 bisogno di pi\u00f9 breakpoint o meno.<\/li>\n<li>quale scelta di design sar\u00e0 quella che richiede una maggior quantit\u00e0 di lavoro; potreste decidere di optare per un design che si adatti meglio ai vincoli di tempo e budget.<\/li>\n<li>Se una particolare classe di device \u00e8 stata dimenticata o ha bisogno di pi\u00f9 considerazione.<\/li>\n<li>Che tecnologie saranno necessarie per sviluppare il design in maniera responsive.<\/li>\n<\/ul>\n<div class=\"supplement\"><strong>Gli schizzi rapidi<\/strong> sono pi\u00f9 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.<\/div>\n<div class=\"illustration full left\"><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2013\/06\/ch07-06_full.png\" border=\"0\" width=\"100%\" \/><\/p>\n<p>Figura 7.6: la maggior parte dei siti web ha bisogno di pochi breakpoint principali.<\/p>\n<\/div>\n<div class=\"supplement\"><strong>I breakpoint meno importanti<\/strong> 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.<\/div>\n<p>Quindi, dove e quando si devono fare degli schizzi per i <strong>breakpoint meno importanti<\/strong>? <em>Nel browser<\/em>, quando fate il mockup web-based. Scoprirete perch\u00e9 e in che modo nel prossimo capitolo. Nel frattempo, concentriamoci semplicemente sul fare schizzi dello stato delle proprie pagine web o delle schermate dell&#8217;app rispetto ai breakpoint pi\u00f9 importanti per ciascun design.<\/p>\n<p>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.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Pensate al vostro contenuto mentre realizzate gli sketch<\/h2>\n<p>Mentre fate gli schizzi di prova, certamente penserete al modo in cui appariranno le cose. La mia esperienza \u00e8 che la gran parte dell&#8217;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\u00e0 al contenuto nelle diverse situazioni. Quando si progetta in maniera responsive, pu\u00f2 essere utile considerare il modo in cui gestirete in particolare il seguente contenuto:<\/p>\n<ul>\n<li>Testo<\/li>\n<li>Navigazione<\/li>\n<li>Tabelle<\/li>\n<\/ul>\n<p>Oh, sicuramente, ci saranno molte altre cose da considerare e finirete con il creare la vostra lista di &#8220;cose a cui pensare ancora un po&#8217;&#8221; man mano che il progetto avanza. Per ora, diamo un&#8217;occhiata ai tipi elencati qui sopra.<\/p>\n<h3>Testo<\/h3>\n<p>Prima che diciate &#8220;Hey, aspetta un attimo, non mi hai appena detto che non devo disegnare il testo mentre faccio gli sketch?&#8221;, 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 <em>in proporzione allo schermo e agli altri elementi sulla pagina<\/em>.<\/p>\n<p>La larghezza delle colonne \u00e8 piuttosto ovvia, ma pu\u00f2 essere difficile stimare quanto sar\u00e0 larga una colonna con il testo <em>reale<\/em>. In questo caso, fare degli sketch su un device potrebbe darvi un&#8217;idea migliore dello spazio reale con cui dovrete lavorare. Un altro metodo che ho usato \u00e8 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\u00e0 pur sempre un&#8217;impressione pi\u00f9 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&#8217; pi\u00f9 realistici i vostri schizzi.<\/p>\n<div class=\"supplement\"><strong>Nota:<\/strong> Distringuete tra <strong>&#8220;toccabilit\u00e0&#8221;(touchability)<\/strong> e <strong>&#8220;cliccabilit\u00e0&#8221; (clickability)<\/strong>. Molti designer, me incluso, hanno fatto l&#8217;errore di raffinare i link per le persone che ci cliccano con un mouse o addirittura con la tastiera, senza considerare quanto &#8220;toccabili&#8221; siano questi link per le persone che utilizzano device touch.<\/div>\n<p>Pensate alla dimensione dei link, non solo alla dimensione del testo, ma anche alla quantit\u00e0 di spazio attorno a loro. Entrambe questi fattori giocano un ruolo nella <strong>touchability<\/strong> o <strong>clickability<\/strong> dei link (e dei pulsanti): link e pulsanti grandi sono degli obiettivi pi\u00f9 facili, ma link leggermente pi\u00f9 piccoli con molto spazio tra loro possono funzionare altrettanto bene. Detto cil, c&#8217;\u00e8 una discreta probabilit\u00e0 che non importa cosa scegliate di abbozzare, finirete col fare dei cambiamenti ancora quando creerete i mockup.<\/p>\n<p>Questo \u00e8 l&#8217;aspetto positivo degli sketch e che non ripeter\u00f2 mai abbastanza: raffinerete comunque il vostro design nel browser, perci\u00f2 la velocit\u00e0 con cui proverete le cose quando fate gli sketch implica che non dovrete fare un lavoro dettagliato pi\u00f9 di una volta (a meno che il vostro cliente abbia dei cambiamenti da fare, ma sappiamo tutti che non accade mai).<\/p>\n<h3>Navigazione<\/h3>\n<p>La navigazione \u00e8 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\u00f9 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.<\/p>\n<p>Ripensiamo alla pratica di Bryan Rieger di progettare prima nel testo e di riflettere su quello che faremmo <em>prima<\/em> 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\u00f2 avere un menu &#8220;collassabile&#8221; in cima allo schermo e dargli un effetto drop down quando qualcuno lo tocca. Se il vostro menu si trova in cima, \u00e8 nella sua forma espansa e occupa tutto lo spazio verticale che occuperebbe normalmente.<\/p>\n<p>Si tratta di un argomento abbastanza controverso, che vede in disaccordo anche i guru dell&#8217;accessibilit\u00e0: JavaScript, dopo tutto, \u00e8 attualmente considerato come una tecnologia che &#8220;supportata dall&#8217;accessibilit\u00e0&#8221;, ma questo non riguarda necessariamente l&#8217;accessibilit\u00e0, quanto piuttosto <em>pensare<\/em> a cosa succede quando un browser non supporta JavaScript o se la versione di JavaScript disponibile sul device \u00e8 diversa da quello che vi aspettereste. Il vostro contenuto sar\u00e0 presentato in un certo modo prima che JavaScript ci lavori su, indipendentemente dal browser. Quindi, perch\u00e9 non pensiamo a quale sar\u00e0 lo stato iniziale?<\/p>\n<p>Nel capitolo sui wireframe, ho parlato del mio pattern preferito per la navigazione sugli schermi pi\u00f9 piccoli: lasciarla sul fondo dello schermo e mettere un link a quella navigazione vicino al top dello schermo. JavaScript, quando \u00e8 disponibile e funziona come ci aspetteremmo, pu\u00f2 spostare quella navigazione fino al top e creare un menu drop-down al volo.<\/p>\n<p>Ma un pattern non \u00e8 una legge del design, quindi il modo in cui decidete di gestire gli schermi pi\u00f9 piccoli dipende dal vostro progetto. Se avessi solo pochi link nella mia navigazione, potrei benissimo mettere il menu in cima fin dall&#8217;inizio e ci starebbe per ogni breakpoint.<\/p>\n<p>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 \u00e8 l&#8217;essenza del progressive enhancement.<\/p>\n<h3>Tabelle<\/h3>\n<p>Tabelle! Oh, la disgrazia del responsive designer (no, aspettate, non erano le immagini? O i video? O i layout? Ehm&#8230;). \u00c8 difficile gestire le tabelle su uno schermo piccolo. Mi piacerebbe dirvi che ho tutte le risposte, ma al contrario, ho pi\u00f9 domande che risposte. Spero che vi portino a una soluzione. Va bene pensare a queste durante la fase di sketching.<\/p>\n<p>Per prima cosa, con che tipo di tabelle avrete a che fare? Piccole? Grandi? Numeriche? Testuali? L&#8217;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):<\/p>\n<ul>\n<li><strong>Piccole tabelle &#8220;screen-friendly&#8221;<\/strong>, che probabilmente lascerete cos\u00ec come sono perch\u00e9 sono sufficientemente piccole e funzioneranno bene sulla maggior parte dei piccoli schermi.<\/li>\n<li><strong>Tabelle che possono essere rese come blocchi<\/strong>, che potete modificare con CSS cos\u00ec che ciascuna riga nella tabella funga visivamente da block item in una lista (Figura 7.8).<\/li>\n<li><strong>Tabelle che possono essere rese come grafici<\/strong>, che contengono certi dati numerici che possono essere trasformati in un grafico, un diagramma o in un&#8217;altra visualizzazione che occuper\u00e0 meno spazio su un piccolo schermo.<\/li>\n<li><strong>Tabelle difficili<\/strong>, 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.<\/li>\n<\/ul>\n<div class=\"illustration full left\"><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2013\/06\/ch07-07_full.png\" border=\"0\" width=\"100%\" \/><\/p>\n<p>Figura 7.7: Ci sono svariati tipi di tabelle e diversi modi per gestirle sui piccoli schermi. (Fonte: <a href=\"http:\/\/mobilism.nl\">mobilism.nl<\/a> e <a href=\"http:\/\/eu-verantwoording.nl\/\">eu-verantwoording.nl<\/a>)<\/p>\n<\/div>\n<div class=\"illustration full left\"><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2013\/06\/ch07-08_full.png\" border=\"0\" width=\"100%\" \/><\/p>\n<p>Figura 7.8: Un modo per gestire le tabelle su piccoli schermi \u00e8 quello di trattare ogni riga come un blocco.<\/p>\n<\/div>\n<p>Pensando ancora in termini di progressive enhancement, il design di base dovrebbe probabilmente includere l&#8217;intera tabella, il che significa che, in molti casi, l&#8217;utente dovr\u00e0 fare uno scroll orizzontale per visualizzarne tutto il contenuto. Oltre a ci\u00f2, possiamo utilizzare CSS e JavaScript quando sono disponibili, per usare un po&#8217; di magia. Le tabelle che possono essere rese come blocchi e grafici possono essere rese come <em>blocco<\/em> con CSS e come <em>grafico<\/em> 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.<\/p>\n<p>La parte divertente \u00e8 che quello che fate su uno schermo piccolo non \u00e8 necessariamente quello che farete sugli schermi pi\u00f9 grandi. \u00c8 il motivo per cui ora, quanto tutto quello che dovete fare \u00e8 uno schizzo che non vi prender\u00e0 molto tempo, \u00e8 il momento giusto per pensare ai cambiamenti che farete ad ogni breakpoint.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Cosa fare se ci si blocca<\/h2>\n<p>Tutti i designer prima o poi si bloccano. Non \u00e8 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 <em>e se<\/em> (&#8220;E se non ci fosse una tabella ma una lista?&#8221; \u00e8 quello che mi sono chiesto prima di sbloccarmi sulla tabella dei partecipanti per il sito Mobilism) fino al clich\u00e9 del <em>farsi una doccia<\/em>, che spero vi facciate regolarmente, comunque. La ragione per cui questo capitolo si concentra cos\u00ec tanto sul fare schizzi \u00e8 perch\u00e9 l&#8217;atto stesso del disegnare pu\u00f2 in effetti stimolare il cervello affinch\u00e9 se ne esca con pi\u00f9 idee, a condizione che vi spremiate le meningi cos\u00ec tanto da fare sketch al di fuori della vostra &#8220;comfort zone&#8221; delle prime idee che vi saltano in mente.<\/p>\n<p>Se il vostro problema \u00e8 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\u00e0 stessa (provate un classico come quello di Edward de Bono <em>Lateral Thinking<\/em>), la pi\u00f9 grande ispirazione pu\u00f2 arrivare da fonti al di fuori dello spazio del design.<sup>1<\/sup> Cercare di combinare cose che normalmente non stanno insieme pu\u00f2 portare a risultati sorprendenti. \u00c8 un trucco semplice, ma spesso ho usato le <em>Oblique Strategies<\/em> di Brian Eno e Peter Shmidt per forzarmi ad avere un approccio diverso.<sup>2<\/sup> Nel caso peggiore, vi divertirete moltissimo. Nel caso migliore, avrete una grande idea!<\/p>\n<p>Se il vostro problema \u00e8 che non siete sicuri su come gestire qualcosa nel contesto del responsive design, non c&#8217;\u00e8 niente di male nel cercare come gli altri hanno risolto dei problemi come il vostro. Assicuratevi solo di usare la vostra creativit\u00e0 e di adattare alla vostra situazione qualsiasi idea potreste trovare: dopo tutto, siete designer! Al momento in cui scrivo, trovo <em>This Is Responsive<\/em> di Brad Frost una delle collezioni e delle risorse pi\u00f9 esaustive dei pattern di responsive web design disponibili.<sup>3<\/sup> Potete passare ore sfogliandole e troverete sicuramente qualcosa che vi sbloccher\u00e0.<\/p>\n<p><small>Tratto da <em>Responsive Design Workflow<\/em> di Stephen Hay, Copyright \u00a9 2013.<br \/> Riprodotto con il permesso di Pearson Education, Inc. e New Riders.<\/small><\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2>Note<\/h2>\n<ul class=\"the-footnotes\">\n<li id=\"note1\"><a class=\"count\" href=\"#ref1\">1. <\/a>Edward de Bono, <em>Lateral Thinking<\/em> (Viking, 2009).<\/li>\n<li id=\"note2\"><a class=\"count\" href=\"#ref2\">2. <\/a><a href=\"http:\/\/en.wikipedia.org\/wiki\/Oblique_Strategies\">http:\/\/en.wikipedia.org\/wiki\/Oblique_Strategies<\/a><\/li>\n<li id=\"note3\"><a class=\"count\" href=\"#ref3\">3. <\/a><a href=\"http:\/\/bradfrost.github.com\/this-is-responsive\/\">http:\/\/bradfrost.github.com\/this-is-responsive\/<\/a><\/li>\n<\/ul>\n<p>Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Testo, navigazione e tabelle&#8230; Oh cielo! Cosa deve fare un responsive web designer? Come potete vincolare il vostro design al minimo numero possibile di breakpoint importanti? Dove e quando farete gli sketch per i breakpoint minori? In che modo si deve pensare al contenuto mentre fate gli schizzi? \u00c8 possibile fare degli schizzi sui device reali e che implicazioni di accessibilit\u00e0 ci sono nel fare questo? Potete trovare le risposte a queste e ad altre profonde domande in questo esclusivo estratto dal Capitolo 7 di Responsive Design Workflow, il nuovo libro di Stephen Hay, disponibile presso New Riders.<\/p>\n","protected":false},"author":818,"featured_media":7000702,"comment_status":"open","ping_status":"open","template":"","categories":[254,258,93,274],"tags":[],"coauthors":[394],"class_list":["post-386","article","type-article","status-publish","has-post-thumbnail","hentry","category-content-strategy","category-graphic-design","category-numero-76-25-giugno-2013","category-responsive-design"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/386","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=386"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000702"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=386"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=386"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=386"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=386"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}