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

mercoledì 23 giugno 2010

Maintainr

0 commenti
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...

lunedì 21 giugno 2010

Autocompletamento poco "Auto"

0 commenti
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.

domenica 6 giugno 2010

Notifiche Relazionali

0 commenti
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.