Vivaddio, l’Italia ha la sua style guide

---

Aggiornamento a cinque ore dalla pubblicazione

Su design.italia.it non si scherza per niente :-)
Pur restando valide le considerazioni che ho fatto su due piedi, devo constatare che c'è molta più vita di quanta non immaginassi riguardo questo progetto.

Le Issue su GitHub fioccano e c'è già una bella (nuova) community attiva e sveglia.
Chapeaux.

Prendi quindi questo post come commento "a caldo" riguardo il progetto design.italia.it e subito dopo averlo letto, rallegrati e vai a vedere quanto è attivo e bello l'account di GitHub.

---

Grazie al bel bollettino di Emmaboshi ho scoperto che è stata pubblicata, un po’ sulla falsariga di gov.uk, una style guide per la pubblica amministrazione italiana: http://design.italia.it/
L’occasione è quella buona per tornare con un post un tantino tecnico ma non troppo. Se sai come funziona il web e cosa sono html e css vedrai che quello di cui parliamo non è poi così difficile.
Se invece non lo sai, ti consiglio caldamente di rimediare al più presto (in sintesi: sono il codice che sta dietro a tutte le pagine web che navighi quotidianamente. Se vuoi approfondire prova a cercare su http://italiani.digital/. Oops! 😬).

Qualcosa si muove

Primo commento che sento il bisogno di fare e primi entusiasmi da sottolineare: Bene! Finalmente! Viva!
Pubblicare una style guide per la pubblica amministrazione è un’azione di vitale importanza per la vita delle PA sul web, che mostra una bella sensibilità per i temi digitali e che - soprattutto - ha delle implicazioni pratiche.
L'idea che i servizi della PA siano accessibili e coordinati tra loro è un grande passo in avanti.
Insomma: dal mio punto di vista è un piccolo passo per l’umanità, un grande passo per il paese intero.

Cose che mi piacciono (anche parecchio)

Il fatto che esista un sito del genere non è banale.
Come non è banale che quel sito sia valido con il validatore del W3C.
Non è banale che sia su un repository su GitHub e che, per crearlo, abbiano utilizzato Grunt e Gulp - mica pizza e fichi.
Bravi caspita, bravi.
Per assicurarmi che l'account GitHub non fosse solo di facciata, ho scaricato il codice e l'ho compilato e, udite udite, funziona (quasi) tutto out of the box. Che è un altro aspetto non banale.
Quindi, ancora una volta, bravi.

Design.italia.it is the new gov.uk (ti piacerebbe!).

Non è tutt’oro quello che luccica

Ora arriva la parte delle lamentele :-)
Le scelte tecniche progettuali sono frutto di una visione o di vincoli tecnici. Non sarebbe male sapere chi ha preso queste scelte e perché lo ha fatto; intendo dire che sarebbe utile conoscere non solo il nome dell'ente o associazione dietro il progetto ma proprio le persone (o il team di persone) che stanno dietro le quinte.
Poi, a dirla tutta, c'è una cosa che proprio non mi torna: la style guide, seppur allo stato embrionale nel quale si trova, è allo stesso tempo molto dettagliata e molto generica - e questa mi sembra una contraddizione.
Della serie: se devi comunicarmi un concetto e un modo di approcciare i lavori, non soffermarti sulle scelte tecniche.
Se invece devi comunicarmi dei vincoli tecnici soffermati su questi e lascia stare le visioni e i concetti.

Analizziamo un paio di temi, quelli più evidenti e che mi sono saltati all'occhio ad una prima lettura. Sempre tenendo conto che è tutto ad uno stato embrionale.

Architettura delle informazioni

Come anticipavo prima, tra tutti gli aspetti il primo che è a mio avviso sacrificato è quello dell’architettura delle informazioni.
Una style guide del genere si interessa di parecchi temi - dalla progettazione allo sviluppo di servizi, passando per i layout e l’accessibilità - ma ogni tema potrebbe e dovrebbe essere trattato con il dovuto spessore, senza necessariamente sacrificare la velocità di lettura e la sintesi. Cosa che qui, come dicevo prima, non accade.

Una piccola lancia da spezzare a favore di design.italia.it sono invece le url: sono parlanti e parlano davvero bene. Speriamo che reggano nel tempo.

Paragone con gov.uk

L'organizzazione dei contenuti di gov.uk è da manuale. Prima si trattano tutti i temi e poi, se necessario, si va nel dettaglio. Insomma puoi restare ad un livello generico o decidere di addentrarti il giusto. È sicuramente il miglior modello da seguire.

Per fare giusto un paio di esempi:

• i principi secondo cui si progetta, per forza di cose a grandi linee, sono raggruppati nella pagina design-principles
• gli aspetti più tecnici sono differenziati in base alla categoria di professionisti che vi dovranno lavorare (designer, developer, content designer etc.). Pagina service manual sotto “Guides and resources for…”. Questa scansione è effettivamente molto comoda se si vuole progettare una guida che deve essere realmente utilizzata "sul campo".

In generale poi, via via che le tematiche crescono e si fanno più approfondite, vengono "spostate" su spazi ad hoc.

HTML e CSS

Spostandomi sull'aspetto più tecnico la cosa si fa un po' più caliente.

Non dirmi che è Bootstrap

Se mi chiedessero se c'è una cosa che non vorrei che questo progetto fosse, risponderei "un'estensione di Bootstrap". E indovina un po' come hanno approcciato tutto? Taaaac, un'estensione di Bootstrap.
Bootstrap nasce come strumento di prototipazione veloce, non come soluzione universale ai problemi legati al web. Non è che sia da buttare o non serva. Semplicemente, non è nato per fare da guida di riferimento alla PA. Senza andare nel dettaglio con il dilemma Bootstrap sì o Bootstrap no (tema senza fine, ottimo per gli aperitivi nerd, nel caso contattami), tutto il codice diventa subito inutilmente grande e ha una abbondanza di classi che non aiuta la creazione delle pagine e tanto meno la manutenzione nel tempo. Vado più nel dettaglio in un attimo.

Paragone con gov.uk

Diciamo subito che gov.uk non è un’estensione di Bootstrap. Non utilizza le sue classi ed è stato pensato e realizzato focalizzandosi più sui significati che sulle caratteristiche.
Quello che hanno creato con gov.uk è un set ex-novo e semplificato di elementi/classi. Il minimo indispensabile. Il resto lo affidano al naturale markup che ogni pagina deve/dovrebbe avere. Con buona pace della semantica e della pulizia del codice.

Nomi delle classi e griglie

Guai qui a cadere nella tentazione del “chissenefrega” o del “tantoèuguale”: i nomi delle classi sono la chiave per creare un’architettura semantica e stabile nel tempo. Utilizzare le classi di Bootstrap vuol dire fare riferimento ad un guazzabuglio di classi; quindi, nel momento in cui si “sposa” la metodologia progettata e usata per/da Bootstrap, si rischia di affidarsi in toto a scelte fatte da altri, per problemi di altri, che verranno implementate e modificate nel tempo sempre da altri. No buono.

La questione delle classi è proprio evidente, e quando dico evidente lo dico con un tono da allarme, nelle griglie (inteso come griglie di layout).

Paragone con gov.uk

Facciamo un piccolo esperimento (se stai leggendo questo articolo dal tuo computer desktop o laptop): apri la pagina con l’esempio di griglie di gov.uk: http://govuk-elements.herokuapp.com/layout/example-grid-layout/.
Adesso scegli un titolo di quelli piccoli tipo “One quarter” o “One third”.
Ok, adesso ridimensiona e ristringi il tuo browser finché puoi e poi ritrovalo.
Trovato? Bravo. È quello che deve succedere. Vuol dire che una cosa che è visibile su uno schermo largo (come quello dei desktop) resta visibile anche su cellulare.

Ora prova a fare lo stesso con la stessa pagina di design.italia.it: http://design.italia.it/linee-guida/griglie/.
Scegli un’etichetta di quelle piccole tipo “3/12” o “4/12”.
Adesso ridimensiona la pagina e cerca l'etichetta.
Trovata? Scommetto di no. Questo è male. E succede perché hanno duplicato il contenuto e, in base alla larghezza dello schermo, mostrano o nascondono uno dei contenuti da mostrare. Tipo "se hai uno schermo largo 400px fai vedere questo, se hai uno schermo largo 800px fai vedere quest'altro".
Ecco, se c’è una cattiva pratica nel responsive web design è proprio quella di duplicare il contenuto.
E cosa ti va a consigliare design.italia.it? Male!
Ma andiamo avanti.

Tipografia

Non sono un esperto di tipografia. Ne capisco tanto quanto basta a farmi fare il mio lavoro serenamente.
La parte che tratta di tipografia è bella ricca di suggerimenti e spesso va parecchio nel dettaglio.

Non è solo il font da usare

Bello che abbiano usato il font progettato dall’ISIA di Urbino, il Titillium. Bello, bravi.

Se proprio devo fare il pignolo però, ci sono un paio di aspetti che non mi piacciono:

• Mi sembra il minimo consigliare un font o una famiglia di font di fallback. Stiamo progettando un sito, no? Ricordiamoci che stiamo progettando un sito e che il webfont rientra tra le migliorie delle quali si può fare a meno. Ad esempio "potrebbe capitare" che non venga caricato proprio il webfont. Cosa succede in quel caso? Guarda un po' cosa accade con il browser nativo di Android:

• non mi piace tanto che venga dato per scontato l’utilizzo di Google Font: Google è un’azienda privata e non è banale usare un suo servizio di default. Almeno quando si tratta di PA. Per giunta con un font rilasciato sotto licenza open!
  Io fornirei il file tra i file del sito e poi ottimizzerei salvandolo nella cache del browser. Se proprio volessi fare il figo (Matteo Renzi ascoltami), fornirei una bella URL con il font targato italia.it. Qualcosa tipo font.italia.it/titillium. Stiamo parliamo di servizi pubblici infondo, no? Sarebbe proprio fico.
• non ho capito poi perché hanno specificato le unità di misura in SP. Faccio questo lavoro tutto il giorno da svariati anni ormai e non ho mai, MAI sentito parlare dell’unità di misura SP. Se qualcuno sa cos'è, il mio twitter è sempre @decarola.

Paragone con gov.uk

Puntuale e cristallino come al solito l’approccio gov.uk: pagina typography-font precisa e con tutte le info necessarie. Non una di più, non una di meno. E niente Google font.

Sveliamo l’arcano

Come ho detto, leggendo gli aspetti tecnici mi è sembrato che per alcuni tratti la SG fosse troppo generica mentre per altri troppo dettagliata.
Andando a leggere chi c’era dietro il tutto, sono riuscito a connettere tutti i punti. Dietro al progetto ci sono AIAP e ADI.

L’AIAP è l’associazione italiana della comunicazione visiva. Taglio corto dicendo che un sito internet non è da considerare come comunicazione visiva in senso classico, come potrebbe essere un poster o un catalogo. AIAP può essere considerata una buona risorsa per le linee guida in termini di leggibilità e tipografia. Al massimo di griglie. Ma sarebbe da considerare ad un livello di consigliere e non più di questo; è chiaro infatti che tutti gli aspetti della comunicazione visiva sono stati stravolti (o meglio estesi) con il web. Mi riferisco alle griglie fluide che cambiano con i diversi viewport, ai font di fallback e a tutti gli aspetti nerdy. È impossibile prescindere dall'aspetto tecnologico e di interazione di queste componenti visive.
Per non parlare poi degli approcci al lavoro che sono radicalmente diversi tra i professionisti del web e i "grafici" tradizionali. Qui mi riferisco alla condivisione, al partire dal lavoro di un altro ed estenderlo a tutte le dinamiche "open" tipiche appunto del web.
Quelli di AIAP non sono adatti a gestire un progetto del genere, IMHO. Semplicemente è fuori dalla loro area di normale operatività.

ADI è l’associazione per il disegno industriale. Compasso d’oro e oggetti di design. Questo è facile: non hanno assolutamente niente a che fare con il web. Proprio niente. Punto.

Al posto di AIAP e ADI (sempre secondo il mio modesto parere), e quindi al posto di esperti di grafica e di design industriale, vedrei meglio un team dedicato di professionisti del web.
Come dici? Non esiste un'associazione che tratti di questi temi? Fantastico, creiamola! Ma non l’AGID! Intendo un'associazione che abbia una personalità di spicco del web alla guida, un po’ come accade agli amici di AIAP che avevano Beppe Chia, sicuramente personalità di spicco del settore. Una figura che si sappia interfacciare sia con i tecnici che con le figure politiche.

E poi caspita, includere le associazioni che ci sono già. Per quanto riguarda l'architettura dell’informazione, ad esempio, un’associazione di riferimento c'è ed è pure bella attiva: Architecta. Io li coinvolgerei da subito.

Infine includere esperti ed esponenti del mondo front end e back end non sarebbe male. Magari coinvolgendo professionalità con conoscenze non solo tecniche, in modo da assicurare una direzione chiara a tutto il progetto da subito.

Paragone con gov.uk

In UK fanno così. E infatti quelli che ci lavorano te li ritrovi a spesso e volentieri a conferenze ed eventi di settore. Dai un occhio a https://www.gov.uk/government/organisations/government-digital-service per i dettagli.

In conclusione

Concludo con un pensiero, un invito propositivo al futuro, e una proposta bomba:

Il pensiero

Spero che i miei dubbi non siano solo miei e che, nel caso, vengano smarcati prima che le PA inizino ad utilizzare la style guide (recuperare gli errori una volta fatti sarebbe faticoso dieci volte tanto).
Spero anche sia una piattaforma davvero aperta e non una visione di pochi (per giunta non esattamente adatti al ruolo).
In generale, tanto per sfatare il mito che chi fa front end si lamenta sempre, possiamo però dire che siamo contenti. È un gran bel progetto e sicuramente un passo verso la direzione giusta. E non vedo l'ora che inizi a dare i suoi frutti in modo da fare davvero la differenza con la vita di tutti i giorni di tutti i cittadini.
Quindi viva design.italia.it e viva l'Italia che pubblica la sua prima versione di style guide.

L'invito propositivo al futuro

Partendo dai “prossimi passi” elencati nella home page:

1. Individuazione dei community leader per raccogliere moderare gli interventi della comunità. -> Mi candido! Io io! Guardate qui! Hey!
2. Indicare una timeline di adeguamento dei siti web della PA alle nuove linee guida
. Qui mi candido da supporto per i comuni di Bologna e, se non è possibile, di Martinsicuro (le radici non si dimenticano :-)). Se devo farlo con la società farò in modo (ho detto modo, ah ah) di venire incontro alle PA.
3. Sensibilizzare e formare le PA sulla corretta redazione dei contenuti. 
Mi candido sempre per i comuni di Bologna e di Martinsicuro!
4. Trovare le modalità procedurali più snelle per formalizzare l'adesione al progetto. Ehm... qualcuno mi spieghi IN PRATICA cosa vuol dire questo punto. A naso direi che questa voce me l’hanno aggiunta quelli di AIAP 😅 Scherzo eh!

Infine la proposta bomba

Dato che si tratta del web, dell’open source, che è stupido re-inventare la ruota, perché non partiamo proprio dalle linee guida di gov.uk?
Perché non duplichiamo l'ottimo lavoro già svolto da qualcun altro e partiamo da lì per le future modifiche?
Sarebbe veramente un approccio moderno e in linea col tema, oltre che efficace e saggio.
Ciao. Già mi vedo tutti dentro AGID, AIAP, e ADI che sobbalzano dalla sedia.
Questa volta però non scherzo.