La Prova

In questo periodo sto dando una mano presso un corso di alfabetizzazione informatica organizzato dall'Officina Informatica Libera di Torino, frequentato per lo piu' da anziani ed extracomunitari. Talvolta mi trovo ad affiancare gli utenti mentre svolgono gli esercizi mirati a fargli prendere dimestichezza con mouse e tastiera, e sin troppo spesso finisco nei paraggi di un baffuto signore in particolare.

Questo personaggio, nella sua immensa ignoranza (in senso non offensivo, ovviamente) ed ingenuita', e' la dimostrazione vivente di quando sia complicato utilizzare un computer al giorno d'oggi. Facilmente va nel panico, percui si dimentica quello che gli e' stato spiegato cinque minuti prima e tenta di intuire qual'e' l'operazione giusta da fare in un dato momento, puntualmente non riuscendoci e ripetendo l'errore che aveva gia' compiuto prima della spiegazione.

Il mio preferito e' la confusione esistente tra il cursore del mouse ed il cursore lampeggiante del testo. Spesso egli punta il mouse laddove vuole apportare una modifica in una frase (cancellare un carattere, o aggiungerne un'altro), non clicca, ma comunque pigia il tasto della tastiera corrispettivo. Applicando ovviamente tale modifica da tutt'altra parte.

Fa uscire di testa guardarlo mentre tenta di selezionare del testo usando il mouse, in quanto tale tecnica per quanto famigliare per molti e' costituita da infinite "regole" non esplicite e di non immediato apprendimento: la selezione e' monodirezionale (inizia nel punto in cui si e' iniziato a cliccare e finisce nel punto ove il cursore viene spostato, dunque non e' possibile agire contemporaneamente sopra e sotto l'inizio della selezione), deve essere eseguita in un colpo solo (tutte le righe senza mai lasciare il tasto sinistro del mouse), e' suscettibile di speciali comportamenti e un testo selezionato puo' essere spostata in blocco (dunque e' buona norma deselezionare tutto prima di tentare una nuova selezione)... Tutto questo contribuisce a far perdere l'orientamento al buon utente volenteroso (e la pazienza al volenteroso assistente che gli sta accanto), al decimo tentativo di prendere cinque righe egli ha gia' sparpagliato tutto in giro per il documento cliccando e trascinando a casaccio.

I tasti sulla tastiera sono decisamente troppi. Le lettere dell'alfabeto sono sparpagliate, ma le si puo' cercare facilmente. Gia' i tasti con due o peggio tre simboli sono complicati, perche' ogni carattere e' attivabile pigiando il relativo "modifier" (che non viene mai scelto correttamente). Il dramma e' che i simboli selezionabili con Shift non sono attivati quando e' attivo il CapsLock, dunque tutto il vantaggio di spezzare la procedura in piu' parti (pigia CapsLock, pigia tasto, ripigia CapsLock) viene perso ed anzi e' richiesto di coordinare il movimento di ben due dita (un dito fisso su Shift, l'altro sul tasto desiderato). Stendiamo un velo pietoso sui pulsanti Return e Enter, i quali sono vicini e pur facendo cose totalmente diverse riportano entrambi il disegnino della freccia diretta a sinistra...

Tutte e altre considerazioni sono emerse dopo due incontri, facendo solo input di testo vagamente formattato. Sara' dura instradare correttamente il suddetto personaggio, comunque indipendentemente dai risultati che si raggiungeranno (o piu' probabilmente non si raggiungeranno) cerchero' di osservare e registrare i comportamenti della mia cavia per trarne qualche spunto.

Attivita' Collaterale

In un recente post sul suo blog, Aaron Seigo (project leader di KDE) ci spiega il concetto di "attivita'" e la differenza che tale termine assume nelle piu' recenti incarnazioni dei desktop environment Gnome e KDE (non mancando ovviamente di sottolineare quanto il tutto sia molto migliore nel progetto da lui rappresentato).

In breve: una "attivita'" e' un agglomerato eterogeneo di files (e di relative applicazioni per aprirli) che rientrano all'interno di uno specifico task dell'utente, definito manualmente (ed eventualmente anche in modo automatico), invocabile on-demand a seconda di quel che si sta facendo. Per fare un esempio: se lo sviluppo di un dato pezzo di codice comprende i sorgenti, la documentazione dell'API usata e qualche altro contenuto, posso pigiare il tasto "aprimi questa attivita'" ed il desktop environment mi presenta il tutto senza dover aprire ogni singola cosa a mano.

Mi spiace per Seigo, ma io tutto questo lo avevo gia' valutato ed analizzato nel 2004 (come conferma archive.org) nel contesto del fu' progetto BrainTop. E l'ho gia' scartato.

Il concetto e' molto semplice: quel che gli utenti fanno col PC non sempre e' classificabile all'interno di un singolo task, anzi cio' accade piu' raramente di quanto non si creda. L'esempio piu' banale e' quello del player multimediale che in background riproduce musica di sottofondo: esso e' totalmente scorrelato da qualsiasi attivita', e ben difficilmente una data colonna sonora e' univoca e definita per un task. Esempio meno banale sono le comunicazioni sincrone ed asincrone che ognuno di noi si trova a gestire in qualunque momento della giornata: la gente mi contatta in chat indipendentemente da quel che sto facendo, cosiccome mi arrivano continuamente mail da ogni mittente e su ogni tema; tale mole di attivita' de-contestualizzate dovrebbero essere identificate in quanto tali, ed il sistema dovrebbe riconoscere (non si sa come...) l'incongruenza logica evitando di contemplate all'interno della mia sessione di lavoro il programma risvegliato da un input esterno.

Piu' complesso e' il ragionamento sulla quantita' di compiti che in ogni momento si svolgono. La scienza dice, giustamente, che le persone non possono fare piu' di una cosa alla volta. O meglio: che tale pratica e' deleteria. Eppure tutti lo fanno. Una mezza occhiata a Facebook o alle news o alla posta la si da anche lavorando, o magari ci sono momenti in cui si stanno effettivamente mettendo le mani su due cose completamente diverse (in questo preciso momento io sto bloggando a smozzichi tra una compilazione e l'altra di GASdotto). Come dovrebbero comportarsi le "attivita'" in questo caso? Dovrebbero forse mergiare i task tra loro? O includere gli applicativi consultati occasionalmente?

Insomma: dopo averci gia' a lungo ragionato, io sono giunto alla conclusione che codesta suddivisione del lavoro e' perfetta in un mondo ideale e perfetto ma non calza affatto i casi d'uso reali. Attendo di vedere quanto tempo sara' necessario ai team KDE e Gnome per accorgersene a loro volta.

Mappa Geo/Mentale

Qualche tempo addietro il buon Seif Lofty, maintainer dello stravagante progetto Zeitgeist, ha pubblicato un esempio di cio' che e' possibile fare appunto con il suo collettore di informazione.

In una applicazioncina, approntata a mo' di hack, viene presentata una mappa geografica, e cliccando su di essa vengono visualizzati i files editati o consultati mentre ci si trovava in tale posto. O anche, come dimostrato nello screencast, le persone con cui si ha chattato stando in tale locazione.

Il concetto mi garba assai, perche' aggiunge un ottimo criterio di ricerca per facilitare l'individuazione dei files cui si e' interessati: lo spazio fisico. Accade infatti piu' spesso di quanto non si creda (almeno a me) di ricordare di aver fatto o visto qualcosa di interessante mentre ci si trovava in un dato luogo, magari a casa di un amico o nel bel mezzo di un raduno di smanettoni, e nel suo piccolo codesto simpatico software si presenta come ottimo connubio tra facilita' d'uso ed efficienza del risultato.

Dal canto mio avevo gia' iniziato a valutare tempo addietro questo genere di correlazioni "ambientali" per facilitare la navigazione dei contenuti, tant'e' che nella lista di possibili Thoughts per Lobotomy avevo immesso anche una fantomatica "Timeline" che mettesse in parallelo l'accesso ai documenti con altri parametri apparentemente totalmente scorrelati tipo gli eventi del calendario (per sapere cosa e' stato consultato mentre ci si trovava ad un dato appuntamento, concetto gia' superficialmente implementato dal file manager Nemo) o addirittura le condizioni meteo ("L'altro giorno pioveva e ne ho approfittato per scrivere quel file, dove l'ho messo...?").

Piu' in generale credo che tale genere di espedienti multisensoriali siano una ottima strada da esplorare nella corsa al data management moderno, in questi tempi cosi' ricchi di materiale da gestire e cosi' scarsi strumenti per farlo. Il fatto di estendere le capacita' di ricerca entro una dimensione, appunto lo spazio e le condizioni fisiche, cui il nostro cervello e' assai ben abituato da qualche centinaio di migliaia di anni di evoluzione e' un inestimabile valore aggiunto, esattamente perche' rende l'operazione di ricerca estremamente piu' naturale.

Si avvicina il momento in cui l'odierna gerarchia a cartelle sara' sostituita da qualcos'altro, magari una cartina geografica...

Pensieri Androidi

Poco tempo fa' ho finalmente acquistato un HTC Desire, simpatico smartphone che monta di serie il ben noto sistema operativo Android di Google. Manco a dirlo tre giorni dopo l'acquisto ho scaricato l'SDK ed ho iniziato a dare una occhiata alle guide per i developers, anche se solo adesso (dopo una settimana di vacanza a zonzo per il nord Italia e l'urgente lavoro per la release 2.0 di GASdotto) comincio a comprendere le nozioni di base della piattaforma.

Non nego di essermi un poco stupito nello scoprire l'estrema somiglianza tra quelli che in Android vengono chiamati "Layout" e i "Thoughts", alla base di un po' tutta l'architettura grafica di Lobotomy.

In entrambi, l'intera interfaccia di ogni schermata viene definita all'interno di un file XML, che verra' poi interpretato per piazzare i widgets al posto dei tags definiti. Contrariamente a XUL codesti files non contengono alcuna componente funzionale, solo ed esclusivamente la disposizione degli elementi grafici.

In entrambi, ogni file rappresenta una singola schermata. In Android, se una applicazione prevede piu' sezioni ciascuna di esse deve essere definita all'interno di un suo specifico XML, che vive una vita propria e prende il nome di "Activity".

In entrambi, i componenti sono riutilizzabili, miscelabili e richiamati da una parte all'altra in modo trasparente, anche tra applicazioni diverse. Sulla piattaforma di Google il meccanismo prende il nome di "Intents" (da "Open Intents", progetto nato come piattaforma all'interno della piattaforma e alla fine incastonato nel core vero e proprio di Android), e benche' a prima vista sia poco sfruttato dal software attualmente nel Market ha ricche potenzialita'.

Ovviamente esistono anche differenze tra i "Thoughts" di Lobotomy ed i "Layouts" di Android: i primi prevedono una assai piu' netta separazione tra interfaccia grafica e codice funzionale, e la possibilita' di creare i propri widgets da usare e riusare all'interno della definizione XML. E' comunque molto interessante constatare come tali concetti, fino ad ora esistiti solo nei miei appunti, vengano adottati all'interno di un ambiente di questo spessore, ed ancora piu' interessante e' misurarsi con essi sul piano pratico tentando di costruire qualcosa partendo da siffatti strumenti.

Per ora, continuo ad indagare sulla visione degli ingegneri Google provando a capirci qualcosa.

Informazione Colorata

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.

Automazione per Induzione

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.

ZUI, Ma Anche No

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.

Maintainr

Croce e delizia di ogni developer fancazzista, quale sono ad esempio io, sono gli occasionali progettucci in cui sin troppo spesso ci si va ad infognare, in gergo detti "pet projects". Questi ci permettono di passare qualche pomeriggio smanettando su qualcosa di inedito, talvolta fungono da pretesto per metter mano ad una nuova libreria o ad un nuovo concetto appena appreso, e comunemente inducono quella piacevole attivita' cerebrale creativa spontanea che tanto piace alle gioconde menti dei programmatori. Quando si inizia una nuova impresa, parallelamente si iniziano ad innalzare architetture software estrose ed arzigogolate per il puro gusto di contemplare l'infinito, ed intanto si immagina il giorno in cui il nostro programmuccio girera' su tutti i PC del pianeta con schiere di utenti felici e riconoscenti del nostro operato.
Ma la realta' dei fatti e' ben diversa: nella stragrande maggioranza dei casi il progetto parte a razzo e si scrivono cento, duecento, mille righe di codice in pochi giorni, si ottiene una funzionalita' che vagamente somiglia a quello che avevamo in mente in principio, dopodiche' l'attenzione viene sottratta da qualche nuova idea o da una urgenza personale o professionale, oppure l'entusiasmo scema per un decadimento nella fiducia nella vision originaria o tentando di far fronte alle noiose sessioni di debugging che inevitabilmente accompagnano ogni cviclo di sviluppo. A quel punto, il progettuccio resta nella migliore delle ipotesi un repository abbandonato sul web (tanto quanto, qualcuno potra' prima o poi trovarlo e far qualcosa con quel codice, fosse anche solo prenderlo come spunto), nella peggiore viene totalmente perso.
Di mio, ho portato all'esasperazione questa malsana (ma neanche poi tanto...) pratica: avendo una discreta quantita' di tempo libero ho avviato un numero impossibile di piccoli e grandi lavori, dei genere piu' disparati, con ogni grado di pretenziosita', e che si trovano ad oggi ad eterogenei livelli di sviluppo. E per arrestare l'inarrestabile fenomeno dell'abbandono a strascico, ho ben pensato di... avviare un nuovo progetto.
Maintainr si tratta di una applicazioncina molto stupida, il cui scopo e' quello di gestire in un posto solo tutti gli appunti e gli aspetti di promozione del proprio sforzo operativo. Ogni idea ha una sua propria todolist, un proprio pannellino con cui inviare notifiche su identi.ca, e nel prossimo futuro qualche opzione per interfacciarsi con gtk-apps.org ed esporre il proprio software ed i relativi aggiornamenti presso una community decentemente vasta.
Tra tutte, la funzione che preferisco e che ho preteso sin dall'inizio e' lo scheduling semi-automatico: pigiando un tastino posto in alto nella finestra l'ordine dei progetti della lista cambia, spostando in cima il piu' consigliato secondo una banalissima euristica basata sulle priorita' assegnabili ad ognuno di essi, al fine di ciclare periodicamente e dedicare a tutti un poco del proprio tempo per non lasciarne nessuno indietro. Per quanto apparentemente sciocca, quest'ultima funzione e' piu' utile di quanto si possa immaginare: come da me gia' sperimentato (usando Zim, programma il cui impiego mi ha ispirato Maintainr) il fatto di far decantare periodicamente il proprio codice, magari quando pare di essere giunti ad un punto morto o si sbatte la testa per piu' tempo di quanto tollerabile su un bug enigmatico, permette di tornarci poi con maggiore ardore in un momento successivo, in quanto nel mezzo c'e' stato un periodo di "riposo" (ad esempio l'impegno su qualche altro componente piu' soddisfacente) e nel frattempo abbiamo inconsciamente gia' analizzato e risolto la situazione. Questo aiuta a non perdere il coinvolgimento nei confronti di un particolare opera, e dunque di perseguire l'obiettivo per un periodo piu' lungo (sebbene intervallato da altro).
La disponibilita' di strumenti "social" all'interno dell'applicazione mette in luce l'aspetto propagandistico della stessa: per far vivere e prosperare un progetto e' necessario avere un pubblico, anche solo per auspicare di ricevere quel feedback sintomo di interesse degli altri che e' vitale per mantenere viva la passione del developer, e tanto vale sfruttare a proprio vantaggio gli infiniti canali di condivisione messi a disposizione oggigiorno dal "Web 2.0". Dato un modesto sforzo iniziale (registrare appunto il progetto su gtk-apps.org, un account dedicato su identi.ca, un alert Google, e nel futuro magari una pagina Facebook e quant'altro), scopo di Maintainr e' riuscire a tenere aggiornato il resto del mondo sugli sviluppi interni dedicando il minimo tempo possibile a tale occupazione.
Una estremamente limitata release 0.1 e' stata rilasciata l'altro giorno, e si tratta piu' che altro di un primo abbozzo ampiamente migliorabile. Ad ogni modo io stesso ho iniziato ad usare l'applicazione (che di fatto ho costruito basandomi sulle mie proprie necessita'), e sebbene il periodo di prova sia ad ora troppo bene confermo di trovarmici meglio che non con un tool general purpose per gli appunti. Ma ovviamente io sono di parte.
Vediamo se con uno strumento tagliato su misura mi aiuta ad essere un miglior maintainer...

Autocompletamento poco "Auto"

In GTK, cosiccome suppongo in ogni altro toolkit grafico sia desktop che web, si trova GtkEntryCompletion, comoda utility per gestire l'autocompletamento delle caselle di testo. Si popola una struttura dati con gli elementi validi (pescandoli da una history, da un database o quel che e'), e quando l'utente inizia a scrivere qualcosa che combacia almeno parzialmente con uno o piu' di suddetti elementi appare la casellina a tendina da cui si puo' selezionare il testo gia' completato. Il comportamento classico della barra degli indirizzi di un browser, insomma.
Finche' ci si accontenta di far semplicemente selezionare una voce e basta va (quasi) tutto bene, un po' piu' complicato e' far triggerare dall'atto della selezione una qualche azione (nel caso specifico che mi sono trovato ad affrontare: popolare un form con i dettagli relativi al nome scelto). In quanto il widget non copre molti casi d'uso che classicamente si osservano con utenti reali.
Stando a quanto ho visto nella mia esperienza, non sono cosi' tante le persone che sfruttano davvero l'autocompletamento; la situazione classica e' appunto la barra del browser, che sicuramente e' il caso piu' facilmente osservabile in natura. Non conto piu' le volte in cui ho visto utenti scrivere per intero i loro URL, ignorando completamente la casella di selezione del completamento oppure, peggio ancora, vedendola ed usandola come riferimento per copiare a mano la stringa intera. Vuoi per ignoranza sul meccanismo inteso per la corretta fruizione di questo componente grafico, vuoi perche' molti scrivono guardando la tastiera e dunque magari non notano cosa viene proposto sul monitor, vuoi per una qualche abitudine vestigiale a non farsi aiutare dal PC, vuoi per anacronistiche velleita' amanuensi, sperare di triggerare una selezione solo ed esclusivamente con la procedura prevista (inserimento del testo, individuazione della voce completata, attivazione per mezzo di click o di selezione con le freccette direzionali e del tasto Return) e' sintomo di eccessivo ottimismo.
In questo contesto, almeno due situazioni possono capitare:

• l'utente fa quello che ci si aspetta che faccia
• l'utente scrive a mano la voce gia' completata, ignorando il completamento automatico, e pigia Return (universalmente inteso come "terminatore di input"), oppure Tab, oppure cliccando da qualche altra parte alla fine
  

Per provvedere a gestire in modo decoroso il secondo caso, occorre veramente fare i salti mortali: registrare delle callback sugli eventi di focus-out e key-press (quest'ultimo per intercettare il Return), in cui compiere a mano la ricerca del testo immesso nella casella di testo nella struttura dati che contiene i valori buoni, e se opportuno comportarsi come se l'autocompletamento fosse stato attivato come voluto. Spiegarlo a parole e' molto piu' semplice che non implementarlo davvero.
Se cosi' non si facesse, il rischio sarebbe quello di avere un nome perfettamente valido nella casella di testo ma non tutti gli altri buoni altrove. Con le conseguenze piu' nefaste: l'utente riprova piu' volte a riscrivere la stringa, non comprendendo cosa ha fatto di diverso rispetto alle spiegazioni ricevute che mostravano la comodissima e sfavillante attivazione di tutto il resto, oppure l'utente compila a mano i campi che avrebbero dovuto essere riempiti autonomamente, distruggendo la sequenza logica prevista. Nel mio caso: se il form viene popolato quando nessuna voce valida e' selezionata, viene creata una nuova entry nel database; fare un controllo postumo sull'univocita' del nome introdotto sarebbe abbastanza controproducente e frustrante per il povero tapino che nel frattempo si e' riscritto tutto quanto a manina, andando a reperirlo chissa' dove.
Abitudini e limitazioni dell'utenza sono un grande, grandissimo grattacapo, cui purtroppo ci si deve confrontare nel momento in cui si voglia realizzare una interfaccia usabile senza eccessivo sforzo dalla maggior parte delle persone. Una perdita di tempo di due ore da parte mia, che ho dovuto individuare e risolvere il problema dell'attivazione dell'autocompletamento con metodi del resto opinabili, consegue ad un piccolo risparmio di patemi moltiplicato per il numero di tutti i futuri utilizzatori del programma.

Notifiche Relazionali

Gia' diverso tempo addietro ebbi una mezza idea per una funzionalita' da implementare (mai, come al solito) all'interno di Lobotomy: una gestione relazionale delle notifiche che occasionalmente si presentano sui nostri monitor. Ne ho scritto in questi giorni una pagina sul wiki del progetto, ma l'originale l'ho steso in italiano e dunque tanto vale pubblicare anche questo sul blog ad uso e consumo di chi non comprende l'inglese maccaronico o vuole ridere della mia pessima traslazione comparando le due versioni.

Le notifiche sono croce e delizia dell'esperienza sul desktop: spesso disturbano ed interrompono il lavoro, ma al contempo ci permettono di intervenire laddove necessario in un dato momento. Un caso di "notifica inevitabile" e' quella che ci avverte in merito ad una nuova sessione di chat aperta da qualcuno dei nostri contatti: essendo questo un mezzo di comunicazione real-time l'attenzione dell'utente e' immediatamente richiesta per mezzo di icone lampeggianti, finestre che appaiono in popup, suoni e quant'altro. Un esempio di "notifica non inevitabile ma consigliata" e' quella che ci avverte dell'arrivo di nuove e-mail: se ne potrebbe fare a meno, non fosse che senza un meccanismo che ci informa in tal senso saremmo portati a consultare compulsivamente la nostra casella di posta per fare a mano quello che il computer farebbe automaticamente.
Assunto dunque che non ci si puo' esimere dalla gestione di notifiche attive nei confronti di particolari eventi che accadono nel nostro ambiente operativo virtuale, si possono sfruttare le potenzialita' di un desktop relazionale per meglio raffinare le attivita' per cui vogliamo essere eventualmente disturbati, ponendo un argine al numero di notifiche inutili e non desiderate.
Lobotomy e' pensato dall'inizio per visualizzare insiemi arbitrari di dati, selezionati con query piu' o meno complesse. Non sarebbe difficile predisporre un sistema di notifiche che si attivino nel momento in cui il result set descritto dalla query cambi, o per la creazione di un nuovo elemento che ricada all'interno della definizione o per la modifica di un elemento esistente.
Le implicazioni sono ben delineate con un semplice esempio: se in un dato momento sto aspettando una mail da parte di un data persona posso selezionare tutte le mail finora ricevute dal contatto ed abilitare la notifica, con un meccanismo standard e sempre uguale per tutti (ad esempio: premendo un pulsante funzione). In tal modo il relativo segnale visivo/sonoro/animato verra' presentato non quando una qualsiasi nuova mail viene ricevuta, facendomi accorrere al client un numero eccessivo di volte solo per scoprire che qualcuno vuol vendermi del Viagra, ma se e solo se arriva una mail che abbia tutti i requisiti che le mail precedentemente visualizzate avevano in comune (in linea di massima, il contatto).
Altri esempi validi possono essere l'arrivo di una richiesta di chat da parte di un determinato insieme di contatti, o la creazione di un nuovo documento all'interno di uno specifico device condiviso, o l'aggiornamento di un preciso feed RSS.
In questo scenario la notifica resterebbe attiva fintantoche' non sia disabilitata esplicitamente, e l'accesso ad un preciso insieme di icone permetterebbe di accedere ai result set monitorati sul momento.