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?