Idee

Un comunicato stampa dai toni talvolta imbarazzanti annuncia la discussione del Codice dell’amministrazione digitale.

Parte la vera e propria grande riforma della Pubblica amministrazione digitale.

Mi sembra di averla gi� sentita… un paio di volte l’anno negli ultimi 4-5 anni.

Il “Codice dell’amministrazione digitale”, che dovrebbe essere operativo nei primi mesi del 2005

Il condizionale è d’obbligo, soprattutto visto il triste destino dei decreti necessari all’applicazione dell’altra “grande opera” del ministro Stanca: la legge 4/2004 sull’accessibilit� ai dei servizi informatici e telematici della PA.

Tanto per cominciare, prima di far squillare le trombe, sarebbe opportuno aspettare l’approvazione del codice. Di solito, gli annunci entusiasmanti è meglio farli di fronte a un “prodotto finito”, altrimenti (un ministero che si richiama esplicitamente - e con un pizzico di sprezzo del ridicolo - al MIT dovrebbe saperlo) si finisce a ingrossare le fila gi� popolose dei produttori di “vaporware”.

Inoltre, leggendo la selezione di novit� proposta nel comunicato, mi sembra di riconoscere parecchie azioni gi� avviate da precedenti leggi e iniziative, salvo che qui, si spera, verranno spinte con maggior forza verso la definitiva applicazione ed adozione. Ma, scusate se mi ripeto, quali garanzie in questo senso può darci lo stesso legislatore che ci ha regalato l’inapplicata legge 4/2004 e un anno (ma non abbiamo ancora finito di aspettare) di attesa per i risultati dell’oracolo (i consiglieri e consulenti che hanno contribuito alla preparazione dei regolamenti)?

Non sono scettico sulle potenzialit� innovative dell’informatica rispetto alla PA, ci mancherebbe! Ma prima di convocare gli angeli con le trombe e gli arcangeli coi tromboni, forse sarebbe meglio ricordarci che la comunicazione pubblica (anche quella dei ministeri più ambiziosi) non può essere assimilata agli strilli nei mercati o ai toni parossistici da telepromozione.

Pubblicata un’altra bozza delle WCAG 2.0 del W3C. Dopo aver letto per mesi dibattiti sulla lista, oltre che appelli per salvare l’accessibilit� da se stessa, questa volta mi dedicherò a leggere per intero la bozza, eventualmente commentandola. Il gruppo di lavoro richiede commenti in particolare su:

1. Comprensibilit� della bozza
2. Chiarezza della relazione tra le linee guida e i 4 documenti con le “tecniche” (relazione spiegata nell’introduzione)
3. Scrivere le WCAG assumendo che gli utenti abbiano dei browser conformi agli standard?
4. Conviene mantenere le linee guida presenti in WCAG 1.0 che richiedono alternative a tecniche di scripting non accessibili?

Senza la pretesa di essere precisissimo, posso stimare per difetto che almeno 1 articolo su 3 sul blog di Seth Godin sia imperdibile, per cui, invece di imbastire una segnalazione dietro l’altra, lascio nel menù di navigazione a sinistra il collegamento al blog e qui, per comodit� , il collegamento al documento Atom.

Da 2-3 anni, rinuncio alla trasferta allo SMAU, dopo essere stato stroncato dall’overdose di nani e ballerine (soprattutto le seconde) subita nel momento di massimo boom della telefonia mobile, che aveva trasformato la fiera in un circo/discoteca. Comunque, anche prima del definitivo crollo, lo SMAU presentava soprattutto un problema: l’accumulazione di carta, che poi passava a macerare qualche settimana su una scrivania, prima di una veloce scorsa e di un rapido viaggio verso gli appositi raccoglitori differenziati.

Quest’anno ho visitato il salone ComPA, anche come ricognizione legata al prossimo master Publi.Com; il problema della carta si è riproposto, forse anche con maggior gravit� , a giudicare dal peso totale dei materiali trascinati fuori dalla fiera (notare che avevo con me anche il notebook con cavetteria, oltre a biancheria varia). Ma ho deciso di affrontarlo di petto, compilando un repertorio con brevi schede per ogni opuscolo raccolto. Il repertorio non è esaustivo e forse non può neanche essere considerato un campione rappresentativo. Le annotazioni, sono principalmente appunti veloci che possono risultare anche incomprensibili per la loro sintesi. Usare con cautela. Altra avvertenza: le annotazioni riguardano il materiale cartaceo distribuito al ComPA, non siti web o altri tipi di materiale. Ho portato a casa anche una manciata di CD ROM, ma sinceramente non credo di farcela a sfogliarli, anche perché il fatto che siano pensati principalmente (solo) per Windows e mi costringano a fare piccoli salti mortali per vederne i contenuti non mi stimola troppo. Accetto, comunque, richieste di svolgere un’analisi a pagamento dei materiali multimediali…

Ma, prima del repertorio, alcune annotazioni… (more…)

Quella appena finita è stata la giornata del lancio di Mozilla Firefox 1.0. Il browser che esplicitamente lancia il guanto di sfida a Internet Explorer ha raggiunto il suo primo rilascio maturo. Una pietra miliare importante per il mondo del software open-source. Ma più che l’evento, che in sé ha anche un po’ di isteria mediatica, mi interessa parlare del brulicare della vita nelle comunit� che ruotano intorno a Mozilla.

Il primo esempio viene proprio dalla giornata del lancio, in cui, se ne sono accorti tutti, ci sono stati grossi problemi di disponibilit� dei server di distribuzione, sia quelli locali (con un lungo black-out di http://mozillaitalia.org), sia quelli centrali della Fondazione Mozilla.
Non essendomi affrettato al mattino a scaricare le versioni che mi servono (per Windows e Mac OS X; a Linux ci penser� il gestore di pacchetti di Debian), ho trovato nel pomeriggio e nelle ore seguenti i server sempre indisponibili. In serata ho così deciso di affacciarmmi sia sul forum di Mozilla Italia, sia sul canale IRC collegato allo stesso sito. Dopo una rapida verifica del fatto che la situazione era ancora piuttosto compromessa, insieme ad un altro moderatore di MozIt, abbiamo deciso di tentare di alleggerire i server tramite l’istituzione di “torrenti” contenenti le versioni tradotte del software. Dopo un’ora di approcci e tentativi, soprattutto per quanto riguarda i tracker, siamo quindi riusciti a mettere in piedi i torrenti necessari per la distribuzione, sperando che nei prossimi giorni anche altri utenti italiani intervengano usando lo stesso canale e migliorandone così le prestazioni generali.

Un altro piccolo frammento di case history è rintracciabile nella breve vita di un bug da me riscontrato in Camino, circa una settimana fa.

• Verificata la presenza di una nuova finestra di dialogo (a dire il vero è uno sheet, un elemento tipico dell’interfaccia Aqua di Mac OS X) che non è al momento traducibile mantenendo integro il pacchetto dell’applicazione e che inoltre si presenta discretamente fastidioso, dato che chiede conferma per operazioni ovvie, come il collegamento a un indirizzo di posta elettronica
• Inviata notifica alla mailing-list dei team di traduzione
• Inviata notifica al principale sviluppatore di Camino
• Contattato in chat IRC co-leader dei team di traduzione e discusso brevemente il problema
• Contattato in chat IRC il leader del gruppo di programmatori, verificando in poche battute l’entit� del problema, l’origine della modifica e definendone quindi meglio i contorni rispetto alla prima segnalazione
• Biforcazione del problema: da un lato (più grave ed urgente) rimozione della finestra di dialogo per protocolli sicuri e non problematici; dall’altro, aggiunta della possibilit� di rendere traducibili le finestre di dialogo (questa parte del problema, si stabilisce che non sia un ostacolo al rilascio di un prossimo aggiornamento)
• In seguito alla lettura dei commenti al bug che ha dato origine alla patch incriminata, individuato un gruppo di preferenze che, se non implementate, potrebbero essere all’origine del problema
• Inserimento in bugzilla di 2 bug, uno per il problema delle preferenze mancanti, l’altro per la traducibilit� della finestra di dialogo
• Il primo bug viene aggiunto alla lista dei blocker che precludono il rilascio di Camino 0.8.2 e ricever� un trattamento urgente nei prossimi giorni

Questa breve e schematica elencazione vuole dimostrare come, attraverso un mix di diversi canali e modi di comunicazione e archiviazione/documentazione (e-mail, chat. applicazione web per la gestione dei bug, con funzioni di “forum” per la memorizzazione dei commenti che accompagnano decisioni e azioni) si sia giunti in pochissimo tempo all’identificazione di un problema, alla sua valutazione nell’ottica del rilascio a breve termine di un aggiornamento, alla sua scomposizione in 2 livelli di priorit� , all’identificazione di una probabile soluzione.