La battaglia dei cloni di documenti

Un web project manager produce molti e diversi documenti tra cui analisi, presentazioni, benchmark, debrief, a volte anche wireframe. Lavoro per diverse aziende e capita che sia invitato a utilizzare dei modelli già realizzati con loghi, colori e font istituzionali.

È qui che comincia la battaglia. Se per realizzare la documentazione ho impiegato un paio d’ore, cercare di farla rientrare nel modello che mi è stato consegnato è spesso un’impresa titanica.

Il problema è che non si tratta, nella maggior parte dei casi, di veri e propri modelli, ma di cloni di documenti che sono stati svuotati del contenuto e cui mancano delle vere linee guida di formattazione.

Il tipo e la dimensione dei font e le spaziature non sono stati realizzati come degli stili, ma sono stati applicati al testo all’occorrenza. E se anche sono stati utilizzati degli stili, lo si è fatto solo per il testo principale e (forse) per una tipologia di intestazione.

È un approccio inefficiente per diverse ragioni:

  • ogni volta che viene inserito un nuovo elemento, ad esempio un titolo, questo va copiato e incollato mutuandolo dal precedente
  • si perde il valore “semantico” del documento: un’intestazione dovrebbe essere tale perché questa informazione è stata specificata nel documento, mentre in questi documenti lo è semplicemente perché utilizza un font “più grande” rispetto alle altre
  • la qualità degraderà nel tempo: i primi due documenti rispetteranno in qualche modo lo standard, i successivi perderanno man mano la formattazione voluta
  • è impossibile applicare gli stili in un secondo momento, per esempio nel caso di documenti già realizzati, che devono essere modificati a mano voce per voce

Questo si verifica con i documenti Word, ma non solo. Anche Powerpoint e Keynote soffrono dello stesso problema. Piuttosto che investire una mezza giornata per realizzare delle diapositive master che possono poi essere applicate in ogni presentazione, si preferisce realizzare una presentazione con alcune slide che sono poi copiate e incollate più e più volte.

Quando mi viene proposto di utilizzare un modello aziendale per produrre documentazione, cerco se possibile di farmelo anticipare prima di iniziare il lavoro, così da capire come questi siano realizzati. Se la qualità non è secondo me soddisfacente, ma il numero di documenti che devo preparare è ridotto, inizio subito a utilizzare questi “modelli” per produrre la documentazione.

Se però si tratta di un’attività frequente, di solito preferisco investire un po’ di tempo e ricostruire completamente il modello. L’operazione, di solito, mi richiede circa un paio di ore (nel caso di una presentazione qualcosa di più), ma è tempo ben speso, soprattutto per me.

All’apparenza, rispetto al template che mi è stato consegnato, non cambia nulla. Ma il lavoro di produzione della documentazione diventa molto più efficiente, a tal punto da recuperare molto presto il tempo speso per la ricostruzione del modello.

A ogni cosa il suo nome

Mi trovo dal cliente con l’art director per illustrare la tavole grafiche del progetto. Ha apportato le ultime modifiche ieri sera e non siamo riusciti a rivederle insieme. Apre il portatile e fa doppio clic su figo.psd.

Il collega che si occupa del frontend manda un’email con le ennesime correzioni richieste dall’azienda che si occuperà dell’integrazione. Una volta decompresso il file, nel desktop compare la cartella che_palle.

Sono due esempi, ma potrei tranquillamente continuare per ore e ore senza mai ripetermi. Ok_bis_def.zipaltra_prova.psd, oggi_non_ho_idee.png: ho a disposizione un’intera letteratura di nomi insignificanti e imbarazzanti.

Stufo di passare le giornate a rinominare i file e inviarli ai diversi attori (ammesso che fossi ancora in tempo) ho messo a punto un semplice sistema di nomenclatura che cerco di applicare e  fare applicare.

Il consiglio è quello di partire già dalla stesura dei wireframe, per proseguire nel corso della progettazione grafica fino ad arrivare allo sviluppo delle pagine HTML. Ogni wireframe va correttamente nominato prima di consegnarlo all’art director, che solitamente è ben felice di conservare la creatività per altri compiti.

Ho provato in questi anni diversi tipi di nomenclature, ma quella che si è rilevata più efficace nasce da un compromesso tra nome dal contenuto altamente informativo e semplicità di applicazione della regola.

Un tipico esempio di nomenclatura potrebbe essere il seguente:

  • HP010
  • PR010
  • PA010

I primi due caratteri indicano la sezione del sito a cui la pagina fa riferimento (in questo caso HP sta per homepage, PR per scheda prodotto e PA per processo d’acquisto), mentre il numero indica il progressivo della pagina all’interno della sezione (HP010 potrebbe essere l’homepage generale, HP020 la declinazione per il periodo natalizio, ecc.). Utilizzo le decine e non le unità per rappresentare i progressivi perché, se ci accorgiamo di aver dimenticato un template che “logicamente” va inserito tra altri due, lo possiamo includere (ad esempio HP015).

Come è facile vedere la regola è banale, ma proprio per questo altrettanto semplice da applicare. A me ha risparmiato molto tempo, ma soprattutto ha permesso di verificare a colpo d’occhio se i template realizzati erano, in ogni fase, tutti quelli previsti.

P.S.: se, come me, avete il pallino delle nomenclature, vi rimando a un articolo che ho scritto quasi 10 anni fa (il tempo passa) e che affronta tra le altre cose il tema dei nomi da dare e non dare alle regole CSS: Chi ha paura di Xhtml 8?

L’homepage del Guardian secondo chi l’ha fatta

I weblog che seguo con più attenzione sono quelli che parlano di progetti e casi di studio reali, più che di teorie. Tra questi c’è il weblog di Nik Silver, che in qualche modo lavora al team di sviluppo dei siti del Guardian Unlimited.

In un intervento di Maggio Nik fornisce qualche elemento sulle strategie adottate nella progettazione dei template per la nuova homepage del Guardian.

Si parla di Velocity, di Css e di Domain Driven Design e la lettura è talmente interessante che a ogni rilettura emerge qualche nuova idea.

Non volevo però parlare di questo, ma di come sia sempre molto difficile trovare siti e weblog che trattino argomenti concreti. E’ molto più probabile avere a che fare con semplici esempi creati ad hoc il che, quando l’argomento è complesso, possono anche andare bene, ma che molto spesso forniscono un quadro troppo semplicistico.

A parte qualche intervento sul Guardian o sui siti della BBC e un manuale di qualche anno fa, Usability: The Site Speaks for Itself, non ho trovato molto altro, ma potrei aver cercato male.

In Italia, che mi risulti, non c’è proprio nessun tecnico o designer che si esponga a parlare dei propri progetti di un certo livello. Troppo fumo?

Guida di stile per il web: il design grafico

Realizzare progetti web di una certa complessità – della durata di almeno un mese, e che siano seguiti da una fase di manutenzione dei contenuti più o menu lunga – richiede molto organizzazione, ma anche qualche standard.

Solitamente quando mi trovo coinvolto in questo tipo di progetti consiglio di stendere una serie di linee guida da seguire nello sviluppo del processo. Questa serie di linee guida le ho sempre chiamate guide di stile, anche se solitamente questo termine viene impiegato soprattutto per indicare le linee guida relative ai contenuti.

Sono principalmente due le fasi di un progetto web in cui è applicabile il concetto di guida di stile:

  • nella costruzione del layout della pagina e dei diversi elementi
  • nella organizzazione e stesura dei contenuti

Esploriamo qui il primo punto, lasciando il secondo a un successivo intervento.

Una guida di stile per la grafica di un sito dovrebbe essere un documento che si pone due obiettivi: servire come riferimento durante il processo di costruzione del layout delle pagine del sito, ma dovrebbe anche essere consegnato al cliente che si occupa di caricare in contenuti insieme alla guida di stile per i contenuti.

In questo modo chi si trova a dover realizzare nuove pagine nel corso della manutenzione del sito può, se gli è concessa questa possibilità, verificare se le nuove immagini, icone, foto, spalle, box che si appresta a costruire sono in linea con lo “spirito” del sito.

Ecco cosa dovrebbe contenere, sottoforma di testo e immagini, una guida di stile per il design grafico:

  • una rappresentazione dei diversi tipi di template del sito, motivando quando andrebbe usato uno e quando l’altro. Qui varebbe la pena sottolineare eventuali particolarità da prendere in considerazione quando la grafica verrà portata in Html e completata da codice lato server. Questo è utile perché chi si trova a lavorare con in template potrebbe sottovalutare l’impatto di lievi “personalizzazioni” alla grafica
  • l’elenco di tutte le icone usate nella grafica, con la spiegazione del loro utilizzo
  • qualche linea guida per la produzione di nuove immagini e loghi per i contenuti (dimensioni, posizione, in che formato salvarle, ecc.)
  • indicazioni sulla tipografica
  • indicazioni sui tipi di font e stile ai caratteri ammessi (sottolineato, colorato, ecc.)
  • suggerimenti sui diversi tipi di intestazione e link ammessi nel sito, con spiegazione, dovessero essere più d’uno, del loro impiego

Andrebbe quindi presentato un documento che contenga la grafica da usarsi all’interno del sito, arricchito però da qualche linea guida che permetta di capire da come partire da questa grafica per realizzare il codice.

Questo documento aiuta a non ritrovarsi nella frequente situazione per cui, dopo pochi mesi dalla messa online del sito, il designer grafico che l’ha creato vorrebbe non riconoscerne la paternità per colpa dei contenuti non in linea con quanto da lui progettato.