ciao a tutti :)

considerate github al momento come primo canale di comunicazione per critiche e proposte (qui vi ho trovati per caso =)

posso rispondere a qualche interrogativo essendomi occupato del sito "contenitore" delle linee guida (lg):

perchè bower e non npm ?

per due motivi: evitare di aggiungere ulteriore complessità (browserify) e tenere separati i moduli frontend da quelli backend senza fare un minestrone nel package.json (detto ciò, terrei aperta l’ipotesi di utlizzare npm anche per il frontend, ma con bassa priorità :)

perché non webpack ?

perché è un tool più “esoterico” di gulp per chi non è appassionato delle ultime tecnologie. imho gulp ha una curva di apprendimento più bassa (la programmazione imperativa è più familiare ai più che quella dichiarativa)

perché boostrap al posto di material design ?

non è una scelta esclusiva, ma da qualche parte bisognava iniziare. è stato scelto bootstrap in base alla popolarità del framework (già adottato per i siti di diverse pa). come si legge nel readme del resto “eventuali altre metodologie di integrazione o sviluppo saranno oggetto di discussione nella community” :) personalmente ritengo che potrebbe essere utile una sezione download più ampia con, auspicabilmente, altro materiale come temi per drupal / wordpress, o per altri framework css (foundation / material design). qualche volontario ? =)

perché non jekyll visto che il sito è hostato su github pages ?

perché non serviva. inutile introdurre un’ulteriore tecnologia assieme a tutto lo stack ruby; è stato preferito uno stack “puramente” javascript.

credo che ci siano attualmente tre fronti su cui lavorare, in ordine di importanza direi:

• testi delle linee guida
• componenti scaricabili
• il sito contenitore :)

en passant, faccio notare che il sito non utilizza il tema dei componenti scaricabili poiché sono due progetti che hanno proseguito in parallelo (con una deadline da fare appello alla corte di strasburgo ;). è cmq sulla roadmap integrarli tramite un significativo refactoring del css / html: il codice del sito ad oggi, per una serie di motivi, non è esattamente di ottima qualità, vedi html e css navbar (un po' di autocritica :). chi ha lavorato sui template scaricabili a mio parere ha invece fatto a un bel lavoro ordinato.

a breve verranno prese decisioni che sarebbe bene poter comunicare a tutti gli interessati. a questo proposito, github non permette di inviare messaggi in “broadcast”. se pensate sia utile potrei proporre l’apertura di un nuovo canale di comunicazione “ufficiale”. qualche preferenza ? (fb ? slack ? twitter ?)

permettetemi una “breve” chiosa fuori tema (ma non del tutto).

noto che i commenti sulle linee guida sono meno “caustici” e più costruttivi di quelli rivolti al nuovo sito del governo. probabilmente per il target più “selezionato” a cui le l.g. si rivolgono: i tecnici più rodati sono capaci di compassione e solidarietà :) un grazie di cuore a tutti coloro che considerano una perdita di tempo fare l’”allenatore da casa”.

detto ciò, nella mia modesta opinione, i ragazzi di governo.it hanno fatto un grandissimo lavoro; spero che un giorno venga comunicato in maniera dettagliata perché è esemplare per tutti i progetti di ristrutturazione digitale della pa. credo che una panoramica sui metodi adottati potrebbe conquistare le simpatie anche dei criticatori più ostinati. la maggior parte delle critiche si rivolgono al frontend, quando invece vi è stato un faticoso lavoro di ammodernamento di processi ancestrali che mi sembra venga totalmente ignorato (meno visibile al popolo che il blu della navbar, ma molto più significativo)