Aggiornamenti

Social Networks

Sponsored by

ilariamauric.it è online dal 2009
13 novembre 2009

Arrivare alla grafica passando per il wireframe.


Avrei dovuto segnarmi il giorno, ma lo ritrovo spulciando il blog e-xtrategy e quello di Jacopo Romei: quindi sì, era un giorno di giugno, un pomeriggio normale durante una giornata di lavoro normale. Michele mi chiama in riunione per discutere di un nuovo progetto ed esordisce dicendo “da oggi dobbiamo lavorare in modo agile”.

Eh?

agilmente
(grazie a Daniele Canonici per il disegno!)

È passato qualche mese, ho sbattuto il naso su questa parola diverse volte, ho fatto domande a Lorenzo, scritto a Jacopo, riflettuto su alcuni aspetti di questa metodologia di lavoro e… sono appena agli inizi. Mi ci vorrebbe un personal coach!

Però, qualcosa è cambiato. Dopo quella famosa riunione a sorpresa, per quello che mi riguarda e in questi pochi mesi, è cambiato tutto l’approccio al progetto grafico per un sito web. In generale, le fasi ora sono più o meno queste: 1. spiegazione delle storie precedentemente definite con il cliente insieme al team di lavoro; 2. veloce schizzo dell’homepage per individuare gli ingredienti principali; 3. wireframe delle pagine più critiche; 4. sviluppo grafico delle pagine wireframizzate. E poi riunioni, correzioni, riunioni…

Il giorno che avrò imparato qualcosa di più sui primi due punti, dovrò scriverci un post. Sui punti 3 e 4, invece, anche se sono passati pochi mesi, mi sento di poter spendere parole di pura soddisfazione. In breve, il wireframe sta cambiando il mio modo di pensare a un progetto web dal punto di vista funzionale, così come il sistema a griglia sta cambiando l’aspetto visuale.
Prima di lavorare con i wireframe, grafica e interfaccia per me erano un tutt’uno. Il wireframe era uno schizzo veloce che facevo su carta e poi passavo direttamente alla grafica… È curioso, perché il wireframe in realtà è come un uovo di Colombo, una soluzione tanto semplice e funzionale quanto utile per dialogare con gli sviluppatori e discutere per tempo gli aspetti critici di un’interfaccia. In un caso abbiamo potuto usarlo per discutere in modo molto costruttivo con il cliente e spero che possa ricapitare. Dal giorno in cui ho iniziato a progettare usando i wireframe, le pagine che produco in questo modo diventano un supporto alla grafica: mentre la grafica risolve l’aspetto visivo, il wireframe permette di valutare vari aspetti funzionali del sito e lo studio della navigazione; in più apre le porte a una discussione con gli sviluppatori, che possono decidere fin dall’inizio dove e come risolvere eventuali criticità.

Secondo alcuni il wireframe è solo il disegno a matita, che può essere fatto durante la riunione di riepilogo delle user stories, dopodiché si passa alla grafica. Io non la penso così. Il gruppo Information Architects, in questo articolo sul redesign per Internazionale lo chiama “sweet spot“: in italiano potremmo definirlo come dolce equilibrio tra gli elementi, anche se “dolce equilibrio” non è la traduzione letterale esatta. Da quando uso questo nuovo metodo di progettazione, mi viene spontaneo cercare quello “sweet spot” proprio durante la fase di wireframing, perché è in quel tipo di visualizzazione che vengono fuori i buchi, si avverte una mancanza, un’incomprensione, un’ambiguità nell’interfaccia.
Ci sono altri due aspetti impliciti nei wireframes, che mi piacciono in modo particolare, che vanno sfruttati e che non possono quindi risolveresi in uno schizzo al volo: la loro trasparenza e versatilità. Trasparenza perché mostrano lo scheletro della navigazione, senza grafica, che in questa fase potrebbe avere un effetto simile al fumo negli occhi; versatilità perché sono comprensibili, pur essendo nudi. Per ipotesi, si potrebbero usare per discutere non solo con il team, ma anche per fare test con gli utenti o per fare le prime valutazioni con il cliente.
In definitiva, il wireframe è lo strumento chiave, che può davvero semplificare le successive iterazioni di un progetto e dar vita a un’esperienza di navigazione decisamente più approfondita.

Il metodo che uso attualmente è questo:
schizzo a matita l’homepage ed eventualmente una o due pagine interne, mettendo a fuoco tutti gli elementi richiesti nelle storie e individuando il tipo di griglia più adatto.

Lo schizzo iniziale per il blog Claet

Poi passo ai wireframe delle singole pagine: dato che ormai lavoro su pagine costruite tenendo conto di griglie e ritmo, mi preparo un file in Photoshop con le griglie visibili: questo file è il livello base per tutti i miei wireframe, che costruisco in Illustrator, in modo asciutto, senza grafica: solo contenuti e link, bottoni, etichette. Su questi wireframes aggiungo un livello con tutti i dubbi, note e ipotesi di funzionamento. Li discuto con il team di sviluppo e li correggo secondo tutte le valutazioni fatte insieme.

Il wireframe del blog Claet

Infine, esporto il file Illustrator come psd e inizio a lavorare sulla grafica.

Il blog Claet finito, con griglia visibile

Forse questi passaggi Photoshop-Illustrator-Photoshop possono sembrare un po’ macchinosi, ma per ora mi ci trovo bene. Nel frattempo, sul sito http://wireframes.linowski.ca, ho trovato molte risorse per cominciare a ragionare la progettazione usando i wireframes. Ho iniziato a provare uno dei tool suggeriti, ma lo trovo un po’ legnoso. Ci proverò ancora, perché vorrei trovare un modo più rapido di produrre il wireframe. In fase di wireframing, credo di poter evitare di pensare alle griglie, così da recuperare tempo e freschezza durante la fase creativa, cioè il momento in cui passo a vestire di grafica il progetto.

Segnalo un ulteriore approfondimento in questa slide di Alberto Mucignat che giustamente definisce il wireframe come tool definitivo per la progettazione di una user experience.

13 Commenti
  • Bello, mi piace il wireframe… molto utile sia per progetti con poco budget in cui puoi evitare di buttarti alla cieca su diverse proposte, sia in progetti complessi in cui ti puoi soffermare a ragionare la fruizione.

    Quello che mi preoccupa un po’ è che la mente creativa se si avvia dall’ispirazione produce un risultato. Se si avvia dopo una serie di ragionamenti che in qualche modo fissano dei paletti ne produce un altro. In poche parole temo che il wireframe (ancor di più se unito a griglie e ritmi) strozzi un po’ la creatività.

    Ma sono convinto che siano le strade giuste quindi immagno si tratti solo di fidelizzare con questi metodi e prenderci mano.

  • Anche oggi Mucignat ha scritto un post sui molti aspetti utili di un wireframe (http://www.mucignat.com/blog/archives/1489-wireframe-rulez.html) . Anch’io penso che più avremo dimestichezza con questo strumento, più ci tornerà utile sia a livello di sviluppo che a livello di creatività. Lo stesso vale per le griglie: sono solo un modo più ordinato di impaginare e possono portare a un maggiore equilibrio della pagina, quindi semplificare la lettura e la navigazione.

  • Diciamo che il concetto più generale di modellazione, di astrazione e sopratutto di separazione dei layer (che è una conseguenza dei primi due) è sicuramente vincente e basilare per una buona riuscita del processo di sviluppo. Il grosso della mia esperienza è sullo sviluppo di back-end piuttosto che sul front-end (che invece è il vostro pane) ma in quello che scrivi si evidenziano proprio gli aspetti di separazione delle “competenze”. Riuscire a disaccoppiare la parte di presentazone (grafica) da quella di modellazione (navigazione) e controllo (recupero dei dati) è sicuramente il modo più facile per poter avere un reale riutilizzo del codice (basilare per ridurre i tempi disviluppo) e per poter definire delle interfacce comuni per poter far lavorare team eterogenei (programmatori e grafici per esempio) che altrimenti parlerebbero una lingua diversa. Così facendo, inoltre, si parallelizza molto di più il lavoro potendo utilizzare layer “dummy” di test sviluppati secondo quelle interfacce. è chiaro che il rovescio della medaglia è una fase di analisi e modellazione sicuramente più lunga che nonostante porti innumerevoli vantaggi a lungo termine, non sempre si sposa con le tempistiche e con i budget allocati per quel progetto. Qualche volta l’approccio “quick and dirty” è ancora vincente (specie se non sei tu che devi fare manutenzione) :)

  • Ciao Leo, tu provieni dallo sviluppo software. Quest’estate abbiamo discusso un bel pezzetto sullo sviluppo agile, che tu chiami “quick and dirty”. Nel web, queste metodologie di lavoro sono in ascesa, mentre nello sviluppo software, salvo rari casi, mi dici che ormai le metodologie agili non hanno dato molti frutti, alla lunga. Per vari motivi “quick and dirty” è diventato sinonimo di sviluppo agile. La separazione delle competenze funziona, eppure la progettazione grafica continua a essere uno degli aspetti più difficilmente integrabili in un sistema agile O___o Da quello che scrivi tu, sembra invece che possa essere uno dei pochi aspetti in cui lo sviluppo agile funzioni un po’ meglio. In questi giorni parteciperò a un paio di conferenze a riguardo (http://www.agileday.it/front/ e http://is.gd/4XH5m), vediamo se riusciremo a trovare qualche spunto per migliorare.

  • Ciao Ilaria, mi fa molto piacere quando trovo dei ‘colleghi’ che raccontano la loro esperienza nella progettazione web che finalmente inizia ad assumere una sua identità e una sua metodologia. Ovviamente mi riferisco alla realtà italiana dove il WEBMASTER era colui che tutto sapeva del misterioso mondo di Internet. Il WebMaster era un onniscente che conosceva le reti, i server, la programmazione, l’HTML e la grafica…finalmente siamo arrivati alla suddivisione dei ruoli ma la cosa più importante è che si inizia a documentare la progettazione di un prdotto web. Documentare un progetto web serve sia ad uso interno per condividere e indicare cosa devono fare le vari figure coinvolte (programmatori, sviluppatori, web designer, content editor) ma serve anche per condividere con il committente cosa si sta realizzando. Nel tampo ho notato che documentare (anche se può essere faticoso) serve per lasciare una traccia ma anche per rendere tangibile l’impegno del nostro lavoro (soprattutto verso il cliente). Nell’ultimo progetto che ho cutrato in questo anno oltre ai wireframe abbiamo proposto al cliente un qualcosa di ancora più snello. Lo abbiamo chiamato ‘TEXT ONLY’ ed è in prartica un wireframe ancora più scarno che serve però a capire l’architettura dell’informazione, la navigazione utente, gli spazi di cui si dispone per i contenuti ecc. In pratica è un wireframe in html navigabile ed è stato molto utile per far capire al cliente cosa si stava facendo senza presentargli solo il prodotto finito oppure dei layout. Inoltre è facile da aggiornare e modificare in caso di modifiche.
    Spero di aver dato un contributo al tuo blog.
    Complimenti per gli argomenti trattati e per lo stile grafico.

    P.S.
    Attenta al Mucignat è un brutto ceffo :-)

  • Ciao Gaetano, grazie per i complimenti e il commento. Il “Text Only” di cui parli è un wireframe navigabile, senza grafica, se ho ben capito: lo avete realizzato voi internamente o avete usato applicazioni pronte? Io per esempio nei prossimi giorni vorrei provare a usare OmniGraffle e, soprattutto, Mockflow (http://mockflow.com/). Quest’ultima applicazione è utilizzabile online e gran parte delle cose fattibili sono gratuite. Devo vederlo bene, ma in pratica il wireframe si può modificare anche a più mani. Appena mi sarò fatta un’idea ci tornerò su. Fammi sapere, se puoi!

  • Ciao Ilaria, si esatto si tratta di un wireframe navigabile ma è più scarno di un wireframe. E’ soprattutto per definire l’architettura dell’informazione e la navigazione utente. Inoltre è molto comodo per presentarlo al cliente e fargli capire in che direzione si sta andando. CI sono molti software valdi uno di questi a pagamento è Axure http://www.axure.com/ un altro per realizzare dei veri e propri schizzi è balsamiq mockup http://www.balsamiq.com/ ma è meno professionale di Axure.
    A presto, Gae

  • Ilaria, sono “leggermente” in ritardo con questo post ma spero ugualmente di poter partecipare alla discussione. Sono convinto della necessità di usare griglie e vorrei fare il punto riguardo le difficoltà in cui ancora mi imbatto. In quanto (voi) esperti, vi prego di tollerare il livello del post:

    1) misure: intuisco che la dimensione di colonne (e righe) debba essere scelta sulla base dei contenuti della pagina. Se così è corretto, è possibile definire criteri sufficientemente rigorosi a riguardo? Al contrario, una griglia “molto fitta” non permetterebbe di risolvere la gran parte delle situazioni layout?

    2) Margini/padding: probabilmente non uso metodi corretti, ma mi trovo a dover scegliere se allineare alla griglia il testo o il box contenitore a motivo del padding normalmente necessario; capisco che piazzando, sulla stessa colonna, contenitori con stessa caratteristica (stesso padding) ottengo un risultato indifferente all’una o all’altra opzione … ma è sempre così? Non si ostacola il successivo lavoro grafico?

    Grazie. Buon lavoro.

  • Ciao Marco, se è per il ritardo non preoccuparti, sono in ritardo anch’io con la pubblicazione di nuove cose, ma gli eventi incalzano… La conversazione è sempre aperta :)

    Domanda 1: la risposta dovrebbe essere sì, ma per ora sto continuando a prendere confidenza con layout a 12 e 16 colonne. Anche se di recente ho iniziato a usare un trucco: divido le colonne in ulteriori colonnine strette e mi ritrovo quasi con un layout a quadretti sotto gli occhi, così posso cambiare il peso di una colonna senza per forza dover rispettare una griglia troppo rigida. Per il ritmo, invece, dopo i primi esperimenti ho deciso di aggiungere un’ulteriore divisione. Inizialmente sono partita attenendomi rigidamente a un ritmo di 18 pixel. Per alcuni lavori, però, ho visto che questo ritmo mi obbligava a tenere un respiro troppo ampio. Dopo aver letto il libro “Stop stealing sheep” di Spiekermann, ho trovato la risposta. In uno dei paragrafi, Spiekerman mostra la griglia sotto il layout del libro e si vede chiaramente che i testi principali hanno un’interlinea più ampia (per esempio un corpo 18), mentre i testi secondari (didascalie e altro) un’interlinea ridotta a 9 (la metà di 18). E così ho iniziato anch’io a usare questo sistema.

    Per rispondere più direttamente alla tua domanda, la griglia non è un blocco rigido, tutt’altro. Ti semplifica la risoluzione dei problemi di impaginazione. Più è “fitta”, più devi studiare macroblocchi logici in base ai contenuti. Rimane il fatto che, senza la griglia, l’impaginazione rimane comunque più casuale, sregolata e fluttuante… e questo, a mio parere, non va.

    Rimane purtroppo da dire che la gestione del ritmo su un progetto web è piuttosto onerosa in termini di tempo per chi scrive css. Così, in fase di progettazione, io costruisco i miei schemi, mentre il webdesigner decide cosa “segare” in base al tempo e al budget che ha… e il ritmo quasi sempre la prima cosa che “salta”.

    Domanda 2: spero che ti risponda Alessandro, che ha studiato il sistema a griglia/ritmo con me lato css.

  • Ciao Marco,
    riguardo al punto 1) posso dirti che la griglia non è altro che un’insieme di linee guida che orientano e aiutano il grafico a dosare bene lo spazio. E questo non ha niente a che fare con il ritmo dei testi. Tanto che a livello di XHTML e CSS puoi rispettare la griglia anche con il tableform se uno volesse. Se usassimo una griglia per assurdo di 1px avremmo lo stesso effetto di come se non ce l’avessimo. Questo ci indica che la griglia va proporzionata agli spazi e alla tipologia di pagina che andiamo a realizzare. Per esempio, provando a definire dei canoni, una griglia fatta di colonne più sottili faciliterà una pagina fitta di testi come potrebbe essere un quotidiano on line o un portale informativo. Una griglia piu spaziosa invece faciliterà un contenuto misto e perchè no multimediale tenendo conto di ingombri di foto e video. Per esempio se si parla di video dovremmo decidere la griglia tenendo conto dei formati dei video che ospiteremo. Il mio consiglio è di attenersi a quelle più usate che guardacaso sono buone per molti tipi di contenuti e sono molto contemplate anche a livello di codice.

    Riguardo il punto 2) ti faccio presente che se non adoperi il ritmo nel CSS dovrai dosare manualmente i padding e i margin per rispettare la griglia. Escludendo sempre il ritmo (che è implementabile separatamente) devi fare attenzione alle porzioni di testo e agli elementi grafici che escono dall’ingombro del testo. Per esperienza personale non attribuisco più i padding al div contenitore ma lo attribuisco ai singoli elementi che ci stanno dentro. Per esempio un titolo da una p e una tabella o una lista possono avere padding diversi a seconda di come sono rappresentati graficamente.

    Ti segnalo un articolo che ho scritto proprio sull’uso di griglie e ritmo…tratto poco la parte di creatività ma troverai spunti per quella tecnica:
    http://css.html.it/articoli/leggi/3224/web-design-con-griglie-e-ritmo/

    Alessandro

  • Rispondo al volo per ringraziarvi entrambi per la cortesia e la completezza delle risposte. Leggerò attentamente e magari tornerò a parlarne ancora. Alessandro, ho letto quell’articolo appena dopo aver inviato post.
    Buone cose a voi.

  • Lascia un commento

    Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

    Informazioni e licenza


    Questo blog utilizza Wordpress è basato sul tema Gutenberg, modificato da me con i preziosi consigli di Nicolò e il fondamentale supporto di Luca
    Eccetto dove diversamente specificato, i contenuti del mio blog sono pubblicati con Licenza Creative Commons Attribuzione Non commerciale - Condividi allo stesso modo 3.0 (Italia License).