Nella creazione di un sito internet succede spesso che un web designer si ritrovi a dover ricoprire un po’ tutte le figure, ma nei grandi progetti è pressoché naturale che i ruoli vengano distinti affidando ogni fase a diversi collaboratori.
Questo non significa che la creazione di un sito debba trasformarsi in una catena di montaggio, ovvero dove finisce il lavoro di una persona non inizia quello di un’altra. In ogni fase devono intrecciarsi i ruoli per ottenere il massimo, con un risultato finale di qualità migliore e ottenuto in minor tempo.
Se siamo dei web designer e dovremo occuparci della sola parte grafica forse può essere utile avere in mente alcuni concetti.
Il giusto approccio
Potremmo essere convinti che qualsiasi bozza su foglio possa essere tradotta efficacemente in codice e di avere la massima libertà nelle scelte, ma non è così. Questo è un atteggiamento che appartiene per lo più ai grafici che non hanno mai montato un sito ma, in parte, può coinvolgere anche il webdesigner alle prime armi.
La maggior parte degli errori del designer può risiedere nel concentrarsi troppo sulla resa grafica nel foglio di lavoro (che è di per sè statico) dimenticando il carattere dinamico delle pagine web, sia per dimensioni che per contenuti.
Il giusto approccio è quindi il costante chiedersi: “sto considerando la dinamicità dell’elemento? Come varia la grafica se decido di cambiare il testo qui o tolgo un elemento qua?”.
L’obiettivo è slegarci dal foglio di lavoro e proiettarci direttamente all’interno della pagina web. In questo modo eviteremo anche errori banali come creare un elemento grafico ad hoc per un contenuto variabile.
Il web designer poi ha un notevole vantaggio rispetto al “grafico puro” e dovrebbe sfruttarlo per chiedersi : “come monterei questo elemento in codice? E’ fattibile?”.
Evitiamo l’approccio menefreghista del tipo : “tanto poi se ne occupa il developer” perchè gli effetti possono essere due:
– vedere stravolta la grafica;
– essere ricontattati per effettuare le giuste modifiche (con malcontento generale).
Mai smettere di comunicare
E’ però vero che anche con il giusto approccio potremmo non avere abbastanza conoscenze e quindi dobbiamo far capo al nostro sviluppatore per valutare se una data cosa è fattibile o meno in termini di conflitti, capacità, tempo e costi.
Molte volte possiamo avere delle idee molto creative ma che il nostro developer valuta troppo laboriose da realizzare, quindi potremmo trovarci a dover cambiare idea se il budget del progetto non è sufficiente.
Questa è una delle ragioni per cui è necessario che ci sia una costante comunicazione con il nostro collaboratore, per evitare di perdere tempo su delle cose che andrebbero in futuro scartate.
Non bisogna quindi essere timidi ma, se possibile, mostrare spesso ciò che abbiamo in mente per assicurarci che tutto possa essere realizzato così come l’abbiamo immaginato.
In questo modo si ottimizzeranno i tempi e lo sviluppatore non avrà sorprese alla bozza finale perché si è già fatta un’analisi in precedenza.
E poi? Organizzazione
Dal momento in cui riteniamo di aver concluso la bozza per la consegna definitiva dobbiamo organizzare e ottimizzare il tutto in modo che il nostro collaboratore possa ben giostrarsi nel file sorgente e nella cartella del tema.
Oltre all’organizzazione dovremmo andare anche alla ricerca di evenutali errori dati spesso dal non aver seguito il giusto approccio. Un esempio banale potrebbe essere l’aver utilizzato pattern di dimensioni troppo elevate e non ripetibili.
Se nella creazione del design utilizzate photoshop allora vi consiglio di studiare TUTTO e ripeto TUTTO quello che c’è scritto in questa fantastica guida che spiega come organizzarvi al meglio: photoshopetiquette.com
Vi consiglio di aprire e studiare anche i link di approfondimento suggeriti nella guida.
Metto l’accento sull’articolo dove viene spiegato come rendere visibili/non alcuni livelli in contemporanea e può essere molto utile, per esempio, per la visualizzazione degli stati hover: http://methodandcraft.com/videos/states-and-layer-comps
questo ci permetterà di farci comprendere in modo semplice e senza fraintendimenti.
Lavoro finito? Ni
Anche quando tutto il processo si è svolto tra giusto approccio, comunicazione e abbiamo dato tutti gli elementi ordinati al nostro collaboratore può succedere che durante lo sviluppo in codice vengano disattese alcune regole di stile tra cui dimensioni, margini e allineamenti.
Questo è un problema sentito da parte del grafico che spesso vede stravolta l’armonia della sua grafica talvolta nell’inconsapevolezza dello sviluppatore.
Sì potrebbe pensare che la causa sia il semplice poco gusto del nostro collaboratore, ma in realtà può dipendere anche da alcune scelte che noi stessi abbiamo fatto (ad esempio un font con cattivo rendering oppure il non aver considerato a sufficienza la dinamicità o la presenza di elementi imprescindibili).
Se si tratta di una vera collaborazione e siamo dei web designer potremmo noi stessi mettere mano al lavoro e dare una “sistemata” al foglio di stile per raggiungere l’effetto visivo che avevamo auspicato. Questo non significa revisionare il lavoro altrui ma fare il nostro lavoro, ovvero ricostruire ciò che avevamo in mente che inevitabilmente va sempre un po’ a perdersi in un contesto diverso come le pagine web.
Per concludere altri piccoli consigli:
- Dare i sorgenti in un formato concordato in precedenza:
non sempre la grafica può essere costruita su photoshop ma potremmo utilizzare fireworks. Questo potrebbe essere un problema per un developer che conosce solo photoshop, dovremmo quindi accordarci inizialmente su quale formato utilizzare. - Considerare lo stile predefinito degli input dei browser:
ricordiamoci che le checkbox, radio e le select hanno uno stile differente per ogni browser e non possono essere personalizzate normalmente con i css. Per modificarne lo stile si può eventualmente usare qualche script Javascript, ma anche in questo caso è bene tenere informato di ciò lo sviluppatore. - Grafica per un cms:
In questo caso più che mai occorre una continua comunicazione con il nostro sviluppatore.
Creare una grafica per un cms è molto diverso che per una pagina che dovrà essere costruita da zero in html. In questo caso dobbiamo tenere in considerazione che certe strutture, posizione dei blocchi ed elementi che vengono inseriti dinamicamente non sono facilmente scomponibili e variabili di posizione. Non possiamo in genere fare tabula rasa e mescolare a caso gli elementi, ma sarebbe più opportuno partire da una grafica base e rispettarne la struttura, variando comunque lo stile. Questo non deve essere un freno alla nostra creatività ma una scelta funzionale perché è la nostra grafica, come un vestito, a doversi adattare alla struttura del cms e non viceversa. Possiamo comunque decidere di inserire delle variazioni ma dobbiamo sempre prontamente farne menzione al nostro sviluppatore che deve dirci quanto fattibile e complessa può essere l’operazione di adattamento.
