Pensieri e parole su HCI, home computing, tecnologie desktop e sul Progetto Lobotomy

sabato 31 luglio 2010

Informazione Colorata

0 commenti
Nella oramai imminente release 2.0 di GASdotto (stando alla roadmap attuale dovrebbe essere rilasciata entro la fine di agosto) e' stato introdotto un nuovo pannello dedicato ai grafici: per mezzo della Google Visualization API, integrata in GWT, ho aggiunto qualche disegnino che rappresenta graficamente in forma di barre e torte il numero di utenti che hanno ordinato qualcosa presso un fornitore, a quanto ammonta la cifra totale degli ordini effettuati in un dato intervallo di tempo, e quali sono i prodotti piu' richiesti. Credo che sia venuto abbastanza bene, i grafici sono graziosi ed abbastanza ben leggibili.
L'altra sera ero a casa dell'amico che mi da una mano con lo sviluppo, o meglio che mi guida suggerendo features e migliorie: essendo uno dei responsabili di uno dei Gruppi di Acquisto piu' grossi di Torino, il quale gruppo e' peraltro il maggior fruitore "ufficiale" dell'applicazione, ha accesso ad una mole di dati immensa ed estremamente utile per effettuare test piu' che significativi sul software.
Ero a casa sua, dicevo, ed insieme a noi c'era un altro amico, anche lui all'interno dello stesso GAS, e stavamo contemplando lo stato attuale della piattaforma (il cui codice, seppur non rilasciato, e' accessibile a tutti dal repository SVN) su uno snapshot della base dati realmente utilizzata dal gruppo. Quando e' stato aperto il pannello delle statistiche, il grafico a torta rappresentante la spartizione dei quattrini tra i diversi fornitori visualizzava uno spicchio grosso quasi quanto un quarto del totale. "A chi diamo tutti questi soldi?", e' stata la reazione del nostro ospite. Ne e' emerso che, per un motivo o per l'altro, un singolo produttore (su circa 17) assorbiva appunto quasi un quarto delle attenzioni della combriccola, in evidente contrasto con quello che dovrebbe essere lo spirito di equita' e solidarieta' che anima questo genere di iniziative.
Tutto questo fior fior di aneddoto per ribadire qualcosa di non nuovo: una rappresentazione grafica che riassuma in un colpo solo una discreta quantita' di dati fornisce nozioni che sarebbero afferrabili solo analizzando molto attentamente i dati stessi, o per meglio dire nozioni che altrimenti a nessuno verrebbe mai in testa di analizzare.
Coloro che seguono Information is Beautiful, noto blog interamente dedicato agli infographics (nome altisonante per indicare l'arte di far grafici che siano anche belli da vedere), sanno bene a cosa mi riferisco: non e' raro trovarsi dinnanzi a pochi pixel colorati che spiegano una quantita' infinita di cose, cui magari non si e' mai pensato. Nel mio piccolo anche io ho iniziato recentemente ad esplorare questo particolare settore con l'esperienza di Masciap, blog in cui ogni settimana i dataset pubblicati sull'apposito portale della Regione Piemonte vengono tradotti in numeri e grafici, e nonostante la giovane eta' del progetto qualche considerazione significativa e' gia' saltata fuori.
Vorrei nel prossimo futuro includere grafici e tabelle in ogni posto dove sia possibile farlo (gia' tale genere di funzionalita' e' prevista nella roadmap a lungo termine di Maintainr, per riassumere il tempo dedicato ad ogni progetto gestito dal programma), in quanto essi sono un valore aggiunto di inestimabile valore: poche semplici barre possono drasticamente aiutare ad individuare situazioni anomale, e permettere all'utente di agire per correggere il tiro nei confronti dei suoi propri obiettivi, richiedendo del resto uno sforzo minimo da parte di chi implementa l'applicazione.

sabato 17 luglio 2010

Automazione per Induzione

0 commenti
Qualche tempo addietro vidi che in KMail era stata introdotta una simpaticissima feature: dato un indirizzo mail e la relativa password, esso autoconfigurava l'account identificando il server SMTP, il server POP3, le porte di accesso, l'autenticazione SSL attivata o meno, insomma tutti quei dettagli che raramente un utente domestico comprende e che nella migliore delle ipotesi copia e incolla pedestramente dalla pagina di supporto del sito web del provider di fiducia.
Sul momento ho pensato che il suddetto programma dovesse appoggiarsi ad un qualche database online di configurazioni, e dopo qualche indagine sono giunto ad una succulenta scoperta: il meccanismo si chiama ISPDB ed e' stato ideato da Mozilla per Thunderbird (il loro client di posta), e sebbene l'API sia pressoche' inesistente (un URL cui accodare il dominio che interessa, che ritorna indietro un XML) e ben nascosta (ho ravanato un poco per trovare un riferimento al sopra menzionato URL) risulta comunque vagamente usabile. Tant'e' che persino Evolution supporta da poco tale sistema.
Chiaramente mi sono precipitato a mettere insieme del codice per usare tale base di dati, e piu' precisamente ho accrocchiato una funzione PHP che verra' nel prossimo futuro integrata in GASdotto per facilitare la configurazione delle mail in uscita generate dal programma.
Sorvolando sulla mia fregola programmatoria, mi compiaccio del fatto che qualcuno abbia avuto questa bella idea di voler automatizzare qualcosa di facilmente automatizzabile ed abbia messo in piedi un sistema tutto sommato semplice e scontato per ottenere qualcosa che, per l'utente casalingo, semplice e scontato non e'. ISPDB e' un Uovo di Colombo, implementato come detto molto alla buona, ma io credo che nella sua modestia sia un ottimo esempio di come si possa parecchio facilitare la vita all'utente finale: pescando parametri del resto sempre uguali tra loro da una base dati condivisa si evita di dover effettuare la procedura a mano, eliminando peraltro tutti i rischi e le frustrazioni dovute a copia&incolla malamente eseguiti a causa del fatto che chi opera non capisce realmente cosa sta facendo.
La dimostrazione di come un pugno di dati forniti di una semantica possano risolvere problemi, anche grossi, concreti e sotto gli occhi di tutti.
Probabilmente ci sono molti altri casi in cui si potrebbe procedere per metodo induttivo, individuando alcuni patterns ripetitivi ed incastonandoli in un unico flusso gestibile in larga parte per via automatica. Tutto sta nello scoprirli ed ingegnerizzarli.

sabato 10 luglio 2010

ZUI, Ma Anche No

0 commenti
Constato adesso il fatto di non aver mai menzionato le ZUI (Zooming User Interface) su questo blog, ma ora, dopo la lettura di The Humane Interface, mi e' inevitabile.
Nel suo pluri-osannato saggio, il fu' Raskin dedica ampio spazio alla descrizione di interfacce per sistemi general purpose incentrate sul fatto di poter navigare sostanzialmente in tre dimensioni le informazioni, distribuite non gia' all'interno di un albero bidimensionale (la ben famigliare gerarchia a cartelle) ma su una serie potenzialmente infinita di piani "trasparenti" cui accedere zoomando una data porzione dello schermo fintantoche' ci sia qualcosa da zoomare. A tale sistema viene attribuita la capacita' di mostrare moli importanti di dati in un unico colpo d'occhio, una migliore intuitivita' nell'interazione, e l'implicita' possibilita' di embeddare nella stessa interfaccia funzionalita' complesse che, ai fatti, possono sostituire le canoniche applicazioni cui siamo abituati con un agglomerato onnipotente ed onnipresente ben piu' omogeneo.
Personalmente, non sono particolarmente favorevole al paradigma suggerito dalla ZUI. Certamente sono propenso all'ultima nozione di eliminazione delle singole applicazioni (del resto, buona parte del Progetto Lobotomy si basa su tale concetto), ma non posso essere d'accordo in merito all'effettiva efficienza sul trattamento delle informazioni.
In primis: seppur tridimensionale anziche' bidimensionale, pur sempre di una gerarchia si tratta. Gli elementi a video sono sempre raggruppati tra loro secondo un unico criterio arbitrario e non riproducibile o prevedibile definito dall'utente: laddove nell'albero a cartelle i files si trovano nelle directory scelte (spesso malamente) dall'utilizzatore qui vanno posizionati all'interno dello spazio, ma comunque sempre in una qualche "zona" la cui reperibilita' e' sempre delegata alla (fragile) memoria del povero tapino che sta dall'altra parte del monitor. Anzi, in uno spazio tridimensionale si aggiunge una ennesima dimensione entro cui potersi perdere: nel momento in cui sto cercando un documento non devo ricordarmi solo in quale gruppo di documenti l'ho messo, ma potrei benissimo non rintracciarlo essendo esso visibile solo ad un livello di zoom minore o maggiore rispetto a quello attuale.
Per estensione, anche il vantaggio della quantita' di dati visualizzati in un colpo solo viene minato appunto dalla mancanza di conoscenza a priori del giusto livello di zoom entro cui un dato si trova: quel che sto cercando potrebbe benissimo essere stato piazzato in uno strato "superiore", e dunque essere identificabile solo "allargando" la visuale e perdendo la percezione di quel che si trova negli strati "inferiori".
Nel tomo del Raskin viene illustrato l'esempio di una ZUI usata per descrivere l'organizzazione di una serie di cliniche: certamente un impiego del genere sarebbe ben piu' appropriato di un sistema "general purpose", in quanto le informazioni da maneggiare sono gia' distribuite entro una gerarchia nota che si vuole riprodurre metaforicamente (le cliniche, ovvero gli edifici, composti da piani, composti da stanze, popolate da letti in cui stanno i pazienti), ma il problema della navigabilita' rimane: per accedere ai dettagli relativi ad una persona devo sapere a priori dove essa si trova (quale edificio, quale piano, quale stanza, quale letto), e per quanto una funzione di ricerca full-text possa essere facilmente innestata in modo che dato un nome l'interfaccia possa zoomare da sola dove richiesto non e' chiaro quale dovrebbe essere il comportamento in caso di risultati multipli (schermo splittato, ove ogni parte visualizza la porzione corretta dello schema completo???).
Numerosi altri punti sono altrettanto mai risolti, in particolar modo a riguardo del comportamento da adottare con contenuti non testuali: se ho una immagine, mi sposto a destra, ingrandisco finche' non vedo piu' nessuna parte di suddetta immagine, e mi sposto a sinistra, cosa succede? Ho girato dietro l'immagine, e dunque vedo uno spazio bianco? Vedo la stessa immagine zommata? Se creo li' un documento, esso dove andra' a finire? Sotto l'immagine? Dentro l'immagine? Tornando indietro e zommando l'immagine, essa diverra' prima o dopo "trasparente" e mi permettera' di accedere a quello che c'e' sotto o dovro' sempre aggirarla? A tutte queste domande puo' dare una risposta l'eventuale implementatore, e gia' ho visto diverse implementazioni piu' o meno abbozzate di tale meccanismo, ma personalmente credo che almeno per i quesiti qui sopra esposti non esista nessuna soluzione che al tempo stesso permetta una aderenza stretta al paradigma e una sufficiente facilita' di utilizzo: da una parte lo zoom infinito su di una fotografia e' fondamentalmente inutile ed implica di perdere totalmente l'accesso a tutta la parte di spazio che vi sta sotto ma viene richiesto dalla specifica, dall'altra la possibilita' di considerare i contenuti troppo allargati come "saltati" aggiunge una complessita' non da poco alle operazioni di esplorazione dello spazio (di cui alcune parti sono occasionalmente nascoste e pressoche' impossibili da trovare senza premeditazione).
Piu' in generale, ribadisco che per quanto certamente migliore della suddivisione a cartelle anche questa forma spaziale rappresenta pur sempre una gerarchia la cui organizzazione e' lasciata alla cura (o, meglio, alla noncuranza) dell'utente, ed e' dunque destinata a fallire trovando il suo punto critico proprio nell'elemento meno affidabile di tutto il percorso di interazione uomo-macchina. Per quanto mi concerne continuo a preferire di gran lunga la possibilita' di "trovare" piu' che di "cercare", e non sono l'unico.