Commenti a: Arrivare alla grafica passando per il wireframe.

Di: Marco Miele

Marco Miele — Thu, 08 Jul 2010 11:02:37 +0000

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.

Di: Alessandro

Alessandro — Thu, 08 Jul 2010 10:48:15 +0000

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

Di: Ilaria Mauric

Ilaria Mauric — Thu, 08 Jul 2010 10:40:39 +0000

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.

Di: Marco Miele

Marco Miele — Thu, 08 Jul 2010 09:14:45 +0000

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.

Di: Gaetano Anzisi

Gaetano Anzisi — Thu, 19 Nov 2009 15:04:15 +0000

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

Di: Ilaria Mauric

Ilaria Mauric — Wed, 18 Nov 2009 10:37:05 +0000

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!

Di: Gaetano Anzisi

Gaetano Anzisi — Wed, 18 Nov 2009 10:22:03 +0000

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

Di: Ilaria Mauric

Ilaria Mauric — Wed, 18 Nov 2009 06:43:47 +0000

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.

Di: Leonardo

Leonardo — Tue, 17 Nov 2009 14:21:51 +0000

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)

Di: Ilaria Mauric

Ilaria Mauric — Fri, 13 Nov 2009 13:50:04 +0000

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.