Dalla grafica al codice: rendiamoci amico lo sviluppatore

Negli ultimi mesi mi sono trovata a dover gestire dei progetti un po’ più complessi del solito, con scadenze particolari e una mole di lavoro abbastanza massiccia. Per seguire in modo ottimale questi progetti, ho cominciato a delegare una parte del lavoro – nello specifico la fase di sviluppo XHTML/CSS della grafica da me realizzata – a terze persone.

Generalmente, quando sono io ad occuparmi sia della grafica che del markup, tendo a lavorare in modo egoistico:  non mi metto certo ad ottimizzare i sorgenti di Photoshop per l’esportazione dei singoli elementi grafici. Essendo io a gestire il layout – dal primo mockup all’interfaccia definitiva – ovviamente saprò benissimo dove mettere le mani quando sarà il momento di convertire tutto in XHTML.

Quando si comincia a delegare questa fase, però, occorre lavorare in modo diverso. Bisogna approcciarsi in modo meno grossolano al progetto grafico e impostare il tutto in modo da semplificare la vita a chi dovrà analizzare la grafica e svilupparne il markup. Tradotto in termini spicci: dobbiamo farci amico lo sviluppatore, facendo in modo di rendergli il processo di sviluppo quanto più immediato e intuitivo possibile.

Vediamo come.

1- Un po’ di pulizia nei sorgenti grafici

Non so voi, ma generalmente in un sorgente di Photoshop sono capace di trovarmi anche 100 livelli! Anche se dovremmo sforzarci di ordinare e rinominare i vari livelli durante la fase di design, sono consapevole che generalmente l’ordine, nel bel mezzo di un processo creativo, è l’ultimo dei nostri pensieri: quando si è presi dall’ispirazione e dalla smania di mettere su schermo l’idea che abbiamo in testa, è difficile -e controproducente – interrompere il  flusso dei pensieri per riordinare i files del progetto.

Perciò, se i livelli del file sorgente sono in subbuglio, prima di passarli allo sviluppatore dedica una mezz’oretta a sistemare tutto in modo certosino: raggruppa i livelli, dai loro un ordine gerarchico, cominciando dai primi elementi grafici della pagina agli ultimi, dall’alto verso il basso. Scegli nomi chiari e intuitivi per i livelli e per i gruppi: se il file dell’ombra che hai importato si chiama “SX004”, rinominala con “ombra sotto box” e cosi via.

 2- Parola d’ordine: precisione

Da quando ho cominciato ad occuparmi solo della progettazione grafica dei siti web di alcune agenzie con cui collaboro, ho rimosso tutti i link dei siti online dal mio portfolio.

Mi irritava vedere come veniva stravolta la mia grafica durante il processo di sviluppo, senza cura nei dettagli, senza un minimo di occhio.

Le interlinee, le spaziature, i margini: tutte cose che mi facevano rodere il fegato. Per non parlare di elementi come form, pulsanti e call to action, che per semplicità venivano lasciati nello stile di default, ignorando volutamente l’impostazione grafica da me suggerita.

Se non fosse per Nando, a cui devo riconoscere una spiccata sensibilità su tutto ciò che è grafica nonostante non sia completamente il suo settore (sapeste quante accese discussioni, sul colore o sul font più giusto!), e poche altre perle rare che ho avuto modo di conoscere negli ultimi mesi, potrei dire che TUTTI – ma proprio TUTTI – gli sviluppatori con cui ho collaborato fino ad adesso mi hanno dimostrato di non avere la benché minima capacità di comprendere le infinite sfumature che fanno di un design un OTTIMO design, sia dal punto di vista estetico che da quello funzionale.

In poche parole: la maggior parte degli sviluppatori che attualmente si occupa di mettere in codice la mia grafica dimostra un senso estetico pari a ZERO, e questo ovviamente fa si che la qualità finale dei progetti, una volta messi online, ne risenta parecchio.

Per smussare il più possibile questa problematica, il mio consiglio è: siate precisi, in modo quanto più maniacale possibile. Se per una svista il testo inserito in un box apparirà disallineato in Photoshop, è facile che chi si occupa del markup non ci faccia caso, si limiti a fare spallucce e a mettere in codice il box cosi come lo vede, anche se l’effetto visivo finale lascerà a desiderare.

Non pensate cose come “si vede che non deve stare li” oppure “ma è chiaro che deve essere centrato, allineato a sinistra non avrebbe senso”. Lo sviluppatore non ha ideato la progettazione grafica del layout e di conseguenza non può sapere quello che avevamo in testa quando abbiamo disegnato la pagina web. Se vogliamo evitare errori di interpretazione, facciamo in modo che il progetto grafico che consegniamo rasenti la perfezione in ogni suo aspetto.

Questo significa: lasciare visibili le guide e i righelli, cosi che lo sviluppatore capisca in modo immediato che la pagina è progettata su uno schema simmetrico e ben visibile, e che ogni elemento ha una propria disposizione e un suo perché;  utilizzare gli elementi con coerenza: se abbiamo provato font diversi per i titoli cercando di capire qual è quello più appropriato, nella bozza definitiva facciamo in modo di eliminare le varie prove e di lasciare solo le scelte definitive, e cosi via.

In questo modo avremo anche diritto a recriminare nel caso le nostre direttive non venissero seguite in modo corretto :)

3- Il file di testo “info” per velocizzare il processo di sviluppo

Per velocizzare il processo di sviluppo ho cominciato a fornire agli sviluppatori un file testuale (chiamato genericamente “info”) in cui riassumo le informazioni utili al processo di slicing.

In questo file riporto le informazioni circa i colori (colore del testo, colore dei links, dei links nello stato hover, colore dei titoli, del background del footer e cosi via), la tipografia (i font usati nelle varie sezioni, i link ai font su Google Font in caso di font integrati con questo sistema, ecc.) e informazioni generali circa l’impostazione strutturale del layout (“questa sezione con il tempo potrebbe crescere, la dimensione dell’immagine nell’header è di 960pixel per 350pixel, ecc”).

Si tratta di informazioni che snelliscono notevolmente il lavoro dello sviluppatore, che non sarà più costretto ad analizzare le grafiche alla ricerca dei dati utili al suo lavoro.

4- La cartella con il materiale grafico

La maggior parte degli sviluppatori che conosco si occupa anche della fase di ritaglio del layout e di esportazione dei singoli elementi grafici che compongono lo stesso. Tuttavia, sempre per agevolare la fase di sviluppo, può essere utile impostare una cartella contenente il materiale grafico che lo sviluppatore dovrà utilizzare per realizzare il markup della pagina web. Per esempio, potremmo creare una cartella “slider” contenente le cinque immagini dello slider che sarà inserito in home page; potremmo definire una cartella “buttons” inserendo i vari pulsanti, nei vari stati (active e hover) e cosi via.

E’ utile anche inserire una variante della pagina web che fornisca tutte le informazioni necessarie sugli stili hover: per quanto mi riguarda metto sempre uno screenshot della pagina con tanti cursori posizionati sui links, sulle call to actions, sui pulsanti, su tutto ciò che in un modo o nell’altro prevede interattività con l’utente. In questo modo evidenzio il colore diverso all’hover, lo stato hover del pulsante, o l’effetto fade delle thumbnails al passaggio del mouse: tutti dettagli che altrimenti andrebbero persi durante la fase di sviluppo.

In conclusione

Gironzolando in diversi blog, forum e gruppi di Facebook ho avuto modo di notare che tra designers (inteso come “grafici” nonostante il termine possa sembrare improprio) e sviluppatori c’è sempre una qualche forma di attrito, quasi di rivalità. I grafici dichiarano che la grafica è tutto, che se un sito non fosse accattivante un  utente scapperebbe entro tot secondi, e che alla fine l’utente finale vede e interagisce con l’interfaccia, non con il codice che sta dietro di essa.

Gli sviluppatori rispondono che anche “il codice è arte”, che un sito non deve essere bello ma usabile, eccetera eccetera. Con questo articolo ho evitato di fomentare questa discussione (del resto ho già manifestato in più sedi il mio pensiero al proposito), anzi, ho voluto dare qualche piccolo spunto per rendere la collaborazione grafici/sviluppatori più semplice e veloce.

Voi che ne pensate? Quanti di voi delegano la fase di sviluppo o, al contrario, si occupano solo dello sviluppo, barcamenandosi con progetti grafici di terze persone? E cosa pensate del luogo comune che vede grafici e sviluppatori come “cane e gatto” del web design?

Tag:

L'autore

Web designer, lavora nel campo della grafica e dello sviluppo web da sei anni e al momento oltre a collaborare con una web agency gestisce con successo la sua attività di freelance sotto il nome di mascara design. Come molti freelance si è abituata a gestire più ruoli, spaziando dalla grafica cartacea allo sviluppo del codice xhtml e css; nonostante questo la sua passione rimane, sempre e comunque, la grafica per il web.

Sito web dell'autore | Altri articoli scritti da

Articoli correlati

Potresti essere interessato anche ai seguenti articoli:

74 commenti

Trackback e pingback

  1. Articoli della settimana 25/12/2011 | Saverio Gravagnola
    [...] Dalla grafica al codice: rendiamoci amico lo sviluppatore (Your Inspiration Web) [...]