![](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2012\/11\/n63mok-web.png\")
Se create siti web, ci sono buone probabilit\u00e0 che abbiate pensato un po’ a quale potrebbe essere un processo di design “responsive-friendly” e probabilmente avrete capito che aggiungere un mockup per ogni breakpoint non \u00e8 un approccio sostenibile.<\/p>\n
Perlomeno questo \u00e8 quello che \u00e8 successo nella mia azienda, Bearded<\/a>, dove abbiamo passato anni a creare siti web in Photoshop o Illustrator, a farci approvare quei mockup dai nostri clienti, per poi ricreare gli stessi progetti con CSS.<\/p>\n Fino ad ora. Qualche mese fa abbiamo smesso di fare dei mockup basati su immagini statiche per cominciare a progettare con il codice. Questa non \u00e8 una nuova idea (diamine, Andy Clarke aveva suggerito di progettare nel browser nel 2008<\/a>), tuttavia, nuovo o meno, potreste ancora non sapere da dove cominciare o sentirvi disorientati dalla prospettiva di abbandonare l’approccio su cui avete fatto affidamento per tanto tempo.<\/p>\n Ma non temete, gentili lettori. Guardiamo come funziona il nostro nuovo processo di web design “mockup-less” e vediamo come possa essere facile scrollarsi di dosso la scimmia di Photoshop e ricominciare da capo con il vostro vecchio amico, il browser web.<\/p>\n Prima di cominciare a progettare, noi lavoriamo con i nostri clienti<\/a> per definire chiaramente il contenuto e assegnare delle priorit\u00e0 all’informazione che andr\u00e0 sul sito. La mia prima domanda \u00e8 semplice: perch\u00e9 avete bisogno di un sito web? Poi chiedo: “Cosa sperate di ottenere come azienda e cosa cerca il vostro pubblico?” Le risposte a queste domande ci aiutano a definire la funzionalit\u00e0 e la gerarchia dell’informazione del sito.<\/p>\n Una volta compreso lo scopo del sito nel suo insieme, applicheremo quell’obiettivo a qualcosa di finito e che si possa realizzare, come la homepage. Prima ancora di passare ai wireframe, possiamo esprimere la gerarchia dell’informazione sul sito nella maniera pi\u00f9 semplice possibile: mediante un elenco numerato. Per uno dei nostri clienti recenti, la American Association for Homecare<\/a>, abbiamo fatto una lista in homepage che si presentava cos\u00ec:<\/p>\n Senza nemmeno pensare ad alcuna decisione visuale sul suo aspetto, abbiamo creato un’accurata gerarchia dell’informazione di primo livello per la homepage del sito. Ora sappiamo che, indipendentemente da come apparir\u00e0 la pagina, se possiamo presentare correttamente questa informazione, sar\u00e0 una vittoria per l’azienda e per gli utenti del sito.<\/p>\n Una volta che comprendiamo il contenuto e le priorit\u00e0 del sito, il nostro primo step in ambito visuale \u00e8 quello di creare dei wireframe. Ma come avrete gi\u00e0 notato, spostare il testo in un file Photoshop pu\u00f2 essere frustrante e richiede molto tempo.<\/p>\n Ma sapete cosa va davvero alla grande per la disposizione del contenuto in un modo che esprima accuratamente la sua gerarchia? Avete indovinato: HTML e CSS! Quindi, facciamo fare a Photoshop un meritato riposino, lanciamo il nostro editor di testo preferito e il nostro browser WebKit, e cominciamo ad assegnare dei tag semantici al nostro contenuto usando un approccio mobile-first<\/a>.<\/p>\n Quando avete solo qualche centinaio di pixel di larghezza con cui lavorare, le priorit\u00e0 diventano ancora pi\u00f9 chiare e le decisioni difficili ancora pi\u00f9 necessarie. Potreste chiedervi spesso: “Questa cosa deve davvero stare qui?”. Concentrandosi sul mobile first, possiamo anticipare queste discussioni e lavorarci in maniera pi\u00f9 efficace; quanta pi\u00f9 informazione riusciamo a togliere in questo punto tanto pi\u00f9 i nostri utenti ci ringrazieranno.<\/p>\n Una volta che la nostra gerarchia mobile<\/a> \u00e8 chiara, \u00e8 ora di allargare progressivamente il browser e di prendere in considerazione delle decisioni di layout pi\u00f9 complesse. Ogni volta che incontriamo una larghezza in cui le cose cominciano a non stare pi\u00f9 insieme, possiamo aggiungere una nuova media query per aggiustare il layout.<\/p>\n In Bearded, per aiutarci con lo sviluppo del layout nel browser, abbiamo sviluppato un grid system responsive<\/a> che ci permette di applicare rapidamente delle propriet\u00e0 alle colonne annidabili tramite CSS (o, pi\u00f9 accuratamente, con SASS<\/a> e Compass<\/a>). Con questi comodi mix-ins a nostra disposizione, possiamo sperimentare rapidamente diversi approcci al layout responsive senza sforzi eccessivi.<\/p>\n A questo punto, i nostri wireframe HTML\/CSS<\/a> appaiono piuttosto gradevoli e dal momento che stiamo lavorando con lo stesso medium (codice e browser) per tutto il processo, possiamo far evolvere naturalmente i nostri wireframe nel design finale.<\/p>\n \u00c8 proprio a questo punto che ci allontaniamo un attimo dal nostro HTML per definire degli elementi di stile sensibili (simili alle style tile di Samantha Warren<\/a> o ai prototipi di stile di Sparkbox<\/a>). Di solito, si tratta di un piccolo canvas Photoshop in cui riportiamo la tipografia con cui stiamo lavorando nei wireframe e cominciamo a sperimentare con il colore, la texture e le immagini. Una volta definiti, possiamo usare questi “mattoni” visuali per far evolvere i nostri wireframe verso un vero e proprio sito web.<\/p>\n Man mano che inseriamo nuovi elementi visuali, passiamo avanti e indietro tra l’editor di testo e Photoshop, ma quest’ultimo non \u00e8 pi\u00f9 il canvas di design primario: adesso \u00e8 pi\u00f9 simile a un blocco per gli schizzi. \u00c8 necessario rendere perfetta la tipografia? No. Possiamo buttare uno screenshot del browser in Photoshop e cambiargli la grafica del background? Certo! Non volete mostrare questi schizzi mezzo-completati al cliente? Non c’\u00e8 problema, non glieli mostrerete mai.<\/p>\n Non solo questo metodo rinforza l’approccio guidato dal contenuto nel design, ma crea anche qualcosa che \u00e8 utile per il prodotto finale. L’HTML che create per il vostro comp permetter\u00e0 agli sviluppatori di sapere che tipo di markup volete dal CMS. E se fate bene entrambe i lavori, vorr\u00e0 dire che il CSS che state per scrivere verr\u00e0 immesso nel sito finale semplicemente con dei piccoli aggiustamenti.<\/p>\n Non butterete pi\u00f9 via i pomeriggi con i pixel di Photoshop, per perfezionare semplicemente una cosa che butterete via e ricreerete comunque in CSS. Alcune cose si ottengono pi\u00f9 efficientemente con CSS, mentre altre sono pi\u00f9 rapide in Photoshop, quindi scegliamo gli strumenti che ci sembrano pi\u00f9 adatti in quel momento. In fin dei conti, finisce tutto nel browser. \u00c8 il modo in cui progettiamo ed \u00e8 il modo in cui lo vedono i nostri clienti.<\/p>\n<\/div>\n Starete pensando: “Oh s\u00ec, i clienti! Come si inserisce questo mondo mockup-less nel nostro processo di approvazione del design?” Mi fa piacere che l’avete chiesto.<\/p>\n Abbiamo scoperto che mandare ai clienti i comp realizzati nel browser \u00e8 estremamente semplice: mandiamo un URL via e-mail. I clienti possono guardare il design in diversi browser e su diversi dispositivi, ridimensionarlo, cliccare sui link e sulla navigazione e provare i vari stati di hover. Invece di chiedere ai clienti di fingere che un’immagine sia un sito web, gli mostriamo… un sito web!<\/p>\n Forniamo sempre un URL permanente con un \/v1 alla fine, come ad esempio aafh-css.heroku.com\/v1<\/a>. Da quel punto, la versione uno non cambier\u00e0 mai e le versioni seguenti avranno un loro URL, come aafh-css.heroku.com\/v2<\/a>. Procediamo cos\u00ec finch\u00e9 non raggiungiamo una versione approvata<\/a>.<<\/p>\n Poich\u00e9 ciascuna versione ha un URL permanente diverso (usiamo l’hosting gratuito Heroku per gli ambienti non di produzione come questo), possiamo anche mettere un certo numero di revisioni nel contratto, proprio come facevamo con i comp. Se il progetto richiede pi\u00f9 modifiche di quelle previste, potrebbe essere ora di discutere l’aggiunta di ulteriori ore al budget.<\/p>\n Questo permette a ciascuno di ritornare indietro facilmente e di rivedere ogni comp ogni volta che lo desidera. Quando abbiamo finito le revisioni, i clienti ricevono la stessa form di accettazione che abbiamo sempre usato, ma al posto del nome del file, i design finali sono specificati dall’URL permanente di quella versione.<\/p>\n\nParliamo del processo<\/h2>\n
Gerarchia, gerarchia, gerarchia<\/h3>\n
\n
L’altro mio wireframe \u00e8 un HTML<\/h3>\n
Il mio wireframe da grande vuole fare il design di un sito<\/h3>\n
\nLa paura uccide la mente<\/h2>\n
Firmate sulla riga tratteggiata<\/h3>\n