Migrazione!

Come forse precedentemente annunciato, da qualche tempo ho un Virtual Private Server su cui intendo migrare (nonche' riavviare...) lo sviluppo del Progetto Lobotomy.
Per lungo tempo l'opera e' rimasta sospesa a causa dei numerosi impegni professionali e non, ma nell'ultimo periodo un po' di urgenze sono state smaltite e mi trovo con non molto ma sufficiente tempo libero per riprendere le fila dell'antico ma mai dimenticato progetto, che ridendo e scherzando occupa la mia affollata testolina da numerosi anni. Da notare comunque che tale pausa mi ha permesso quantomeno di ponderare in linea teorica sul piu' recente modello che sta alla base della piattaforma che intendo costruire, e dal primo abbozzo presentato alla piu' aggiornata revisione l'idea e' stata arricchita di numerosi perfezionamenti ed apparentemente impercettibili dettagli.
Su http://lobotomy-project.org e' raggiungibile una istanza di Trac, il cui wiki e' attualmente in fase di popolamento al pari del tracker su cui sto raccogliendo (seguendo lo spunto offerto) idee sparpagliate da poi riassemblare e validare globalmente, e da cui partire per una prima implementazione. Nel frattempo sto provvedendo alle questioni amministrative, annunciando sul vecchio sito e sulle varie pagine in cui i diversi componenti del sistema sono state sparpagliate sinora la migrazione in atto.
Ovviamente non sono in grado di fornire una roadmap precisa in merito ai prossimi sviluppi, trattandosi questo di un progetto amatoriale e a piu' bassa priorita' rispetto agli altri impegni, ma faro' in modo di presentarmi all'inizio dell'estate, periodo dell'anno tra i piu' prolifici essendo il meno professionalmente impegnato, con un piano preciso di cose su cui passare le mie giornate svaccato sul futon.

Piastrelle Semantiche

Su questo blog e altrove ho piu' volte criticato le tecnologie semantiche. Ma forse sarebbe bene fare distinzione tra "semantico" e "semantico".

Non tutte le tecnologie etichettate con tale altisonante classificazione, cosi' di moda oggi e dunque cosi' abusata e di cui in fin dei conti in pochi (non me) hanno ben chiaro il significato, offrono infatti gli stessi vantaggi a fronte dello stesso impegno. Si va dall'estremo del "desktop semantico" - l'attuale KDE4, che implementa lo stack Nepomuk e che incentra buona parte delle sue funzionalita' intorno alla capacita' dell'utente di assegnare tags ai suoi propri files - all'opposto del "web semantico", ovvero la "Rete di dati" cui gia' qualcuno arditamente (o stupidamente) appunta la nomea di "Web 3.0". Mentre la prima categoria di applicazione e' lungi dal ricevere un mio consenso, soprattutto a questo stadio di sviluppo ed alla luce del fatto che esse sono completamente inutili se non manipolate a dovere dall'utilizzatore finale (che, per definizione, non usa mai le cose come dovrebbe), la seconda classe e' motivo di discreto interesse, almeno dal punto di vista del potenziale in campo. In generale non vedo troppo di buon occhio la frammentazione (seppur controllata e documentata) dell'informazione in dialetti e sottodialetti, come appunto si vuole fare con l'iniezione di una quantita' infinita di "ontologie" da applicare ad informazioni diverse a seconda del loro contesto, ma certamente se sufficientemente diffusi e propagati tali mezzi risulterebbero di infinita utilita'.

Purtroppo il grande difetto del "semantic web" e', paradossalmente, la sua stessa community di sostenitori, costituita in larga parte da accademici esaltati che amano riempirsi la bocca con nozioni di filosofia spiccia e produrre i piu' stravaganti ed incomprensibili formati e protocolli per il solo gusto di constatare poi quanto siano stati bravi nel far delle cose cosi' complesse, pertanto ho sempre osservato da lontano l'ambiente senza approfondire piu' del tanto necessario a comprendere il senso delle occasionali news che capitano sotto gli occhi. Ma qualcosa potrebbe forse cambiare nel prossimo futuro.
Tra le news di Techmeme trovo un riferimento all'intenzione del team di Twine (scarsamente conosciuto servizio di social bookmarking a la del.icio.us) di piazzare online un "editor di ontologie", ovvero una applicazione che faciliti la produzione, la pubblicazione e la condivisione di "descrizioni" di oggetti da impiegare poi per marcare i dati sull'Internet ed implementare poi all'interno dei programmi che potranno cosi' interpretare il dato e miscelarlo e/o presentarlo in modi nuovi. Sinora la tecnologia (o quantomeno: la discussione di essa, e qualche basilare applicazione) e' stata confinata nelle aule accademiche o sui blog tecnofili da geek, dunque impiegata al piu' in nicchie ben lontane dal mondo dei comuni mortali, ma se davvero si riuscisse a coinvolgere individui non-tecnici nella definizione di nuove astrazioni semantiche pronte per essere adottate in campi di pubblico interesse e fruizione sarebbe forse la volta buona per radicare lo strumento ed iniziare davvero a sfruttarlo.
Io stesso qualche tempo addietro stavo meditando sull'utilita' che avrebbe un web service esposto da GTT (l'azienda di trasporto pubblico torinese; ovviamente il discorso si applica anche a tutte le altre citta') per reperire in un formato programmaticamente trattabile le informazioni relative al traffico urbano, che al momento sono completamente raccolte e gestite dall'ente ma divulgate per mezzo di canali scarsamente riconducibili a qualsiasi forma riutilizzabile, ma dopo rapida ricerca ho notato la mancanza di una specifica adeguata a tale esigenza e che potesse realmente essere definita standard. Di casi simili ne esistono a volonta' e Swoogle non e' di particolare aiuto, ma cosi' come Wikipedia e' la piu' grande enciclopedia del mondo grazie anche e soprattutto al contributo di persone specializzate in settori non necessariamente legati alla tecnologia che hanno imparato quelle poche operazioni richieste per editare il wiki e riportare la loro conoscenza, allo stesso modo puo' esistere la possibilita' di far convergere nozioni ed esperienze diverse per costruire il substrato di interoperabilita' necessario ed indispensabile ad ogni altro futuro sviluppo del web semantico.

Un Task per Domarli Tutti

Non nego che, sebbene continui a seguire la mailing list di sviluppo del progetto OpenMoko, da tempo abbia perso buona parte dell'interesse in merito a tale opera e solo di sfuggita legga le mail che transitano: troppo forte e' stata la delusione di avere tra le mani un FreeRunner completamente inusabile, e di vedere come OpenMoko Inc invece di darsi da fare per completare uno straccio di framework di sistema per il suo proprio dispositivo giocasse a mischiare tutto quanto ogni sei mesi ottenendo solo di spazientire la community.
Per un caso fortuito, seguendo il classico filone di links che rimandano da una news all'altra (sempre sia lodato l'ipertesto...), sono approdato alla pagina di uno dei componenti di cui piu' spesso ho visto menzionare il nome nella mailing list senza peraltro capire troppo bene di cosa si trattasse: Paroli. Assunto che non ho troppo ben capito come esso dovrebbe porsi nei confronti delle prossime versione della distribuzione OpenMoko (non doveva migrare tutto su Android???), di per se' il proposito mi sembra interessante; non fosse altro che e' lo stesso criterio con cui voglio costruire il prossimo SubConsciousDaemon!

Paroli (lemma che in esperanto significa "discussione": ottima scelta) non e' altro che un daemon di sistema il cui servizio e'... offrire servizi. In sostanza, wrappa l'uso di librerie e sottocomponenti rendendoli accessibili con una interfaccia (DBus) unificata, che descrive le operazioni piu' comuni e di interesse generale nel sistema (nel caso di OpenMoko: il networking, il GPS, il GSM...), permettendo di implementare una sola volta funzionalita' avanzate e renderle disponibili per tutti gli altri. Accentrando cosi' il codice prettamente funzionale si riduce la ridondanza di codice (da sviluppare, correggere e mantenere) e si induce al suo riuso ed alla creazione di inediti miscugli sinora non esplorati soprattutto per la complessita' della loro gestione.

Un poco alla volta, dunque, constato che la tendenza di accentrare le componenti funzionali di sistemi complessi isolandole e circoscrivendole dalle componenti grafiche si diffonde a si radica in sempre diversi frangenti: di anni dalla mia prima descrizione di tale architettura ne son passati assai, sono lieto che il tempo stia dando ragione (o quantomeno fiducia) a tale struttura. E non attendo altro che l'occasione di offrire la mia propria implementazione dell'idea, estremizzata all'interno del Progetto Lobotomy.
Non fosse per il fatto che tutto cio' e' in Python (linguaggio da me assai poco amato, e che a tutt'oggi mi domando e chiedo come si possa pretendere di utilizzare su un'apparato mobile con una potenza computazionale ridotta) potrei quasi pensare di riutilizzare tale componente all'interno della prossima incarnazione del mio personale progetto, correntemente in fase di progettazione e specificazione, ma e' probabile che esso sara' quantomeno fonte di ispirazione almeno per quanto riguarda la definizione dell'interfaccia programmatica con cui agganciare e rimuovere servizi e plugins.

Un Futuro che Non C'e'

L'altro giorno mi e' passato sotto gli occhi un bellissimo filmato che, strano a dirsi, viene da Microsoft: esso rappresenta la "vision" dell'azienda per l'adozione massiccia di tecnologie oggi esistenti solo in forma prototipale e sperimentale, e piu' precisamente in previsione di cio' che gli utenti potrebbero avere a disposizione nel 2019. Superfici tattili di ogni tipo, interfacce completamente touch che mutano a seconda del dato presentato o del device su cui vengono impiegate, carta elettronica su cui viene proiettata l'informazione...
Certamente affascinante. Un ottimo cortometraggio di fantascienza.
Con cio' non voglio assolutamente dire che quanto espresso sia irrealistico ed infondato, anzi ho precisato fin dall'inizio che in fin dei conti questa non e' che una artistica raffigurazione di strumenti hardware e software gia' oggi esistenti ed in fase di piu' o meno avanzato sviluppo, ma tra il dire (non senza un pizzico di ingenuita', perdonata per le evidenti esigenze di copione) ed il fare vi e' il baratro dell'interpretazione dell'informazione.
Splendido sarebbe copiare una porzione di un grafico da un device all'altro semplicemente puntando e guardando attraverso l'apposito vetrino, ma per far cio' i tre componenti (mittente, destinazione, e chi trasporta il dato) devono comunicare nello stesso linguaggio, secondo lo stesso protocollo, scambiando bytes di cui conoscono il significato; impagabile sarebbe variare l'informazione numerica in un documento tabellare girando la manopolina virtuale proiettata sulla scrivania, ma per fare cio' chi proietta suddetta manopola e chi traduce il numero prodotto in barretta colorata devono condividere la nozione su come trattare l'input; meraviglioso sarebbe "esplodere" il disegno tecnico pigiando il ditino sulla scrivania su cui e' appoggiato il mazzo di chiavi, ma per far cio' la scrivania deve sapere cosa c'e' scritto nel suddetto schema ed in che modo i componenti rappresentati sono interagibili o meno.
Insomma: il semplice "pezzo di ferro", per quanto sofisticato, semi-trasparente, mobile e reattivo al tocco, non serve a nulla se chi lo gestisce non sa cosa fargli visualizzare, e come. Questo popo' di apparecchiature e' perfettamente inutile se non esiste una capillare ed universale adozione di standard aperti, che possano essere trattati in modo univoco all'interno dell'intera infrastruttura integrata. Che lo si voglia o no, finche' l'informazione e' tenuta prigioniera all'interno di files Office, o Photoshop, o AutoCAD, solo Office, Photoshop ed AutoCAD potranno accedervi. Non il vetrino da puntare, non la manopolina proiettata, non la scrivania.
E il problema non e' certo rimandabile al 2019, ma va affrontato subito, per il semplicissimo fatto che prima di arrivare allo scenario dipinto nel filmato in oggetto sara' necessaria una graduale migrazione dalle tecnologie odierne a quelle prossime venture: e' chiaro che coloro che inizieranno a commercializzare i singoli prodotti che compongono il puzzle dovranno avere la possibilita' in prima istanza di interagire in qualche modo con l'informazione esistente e farsi strada poco alla volta nella vita di tutti i giorni, sia essa quella casalinga o produttiva, ma fintantoche' tale informazione non e' accessibile e manipolabile all'interno di tali nuove interfacce le possibilita' di concretizzazione entro tempi umanamente accettabili sono estremamente scarse.
Dunque: se il video vi e' piaciuto, e non vedete l'ora di utilizzare quotidianamente strumenti di tal fatta, assicuratevi di lasciare campo aperto all'innovazione ed alla penetrazione di tali tecnologie. Pensateci due volte prima di bloccare la vostra informazione (o peggio ancora, l'informazione da condividere con altri) all'interno di files chiusi e non interoperabili.
Partecipate alla costruzione di un futuro che non c'e', ma con il buon senso di tutti potra' essere.

Metodo

Da quando ho preso a lavorare per ItsMe un nuovo e stravagante mondo mi si e' aperto dinnanzi. Non parlo qui del contenuto del progetto stesso (su cui probabilmente in futuro avro' modo di soffermarmi), ma proprio della metodologia di lavoro con cui i diversi componenti del team di sviluppo interagiscono e si coordinano.
Specifiche, prototipi, diagrammi... Tutti concetti di cui ho forse sentito parlare molto lontanamente ai tempi dell'universita' ma su cui non mi sono mai soffermato, anteponendo ad essi la necessita' immediata: avendo negli ultimi tre anni scritto software ancor prima di sapere cosa dovesse fare, per riuscire a stare dentro a tempistiche e consegne gia' fissate ancora prima di mettere piede per la prima volta nell'ufficio torinese, ho sempre contemplato con distacco e diffidenza i dogmi dettati da questa strana dottrina chiamata Ingegneria del Software, e per abitudine e dimestichezza ho finito col gestire nello stesso modo un po' tutti i progetti con cui ho avuto a che fare sia professionalmente che amatorialmente.
Eppure ora scopro che il tempo passato a progettare e pianificare la propria applicazione, soprattutto se complessa e strutturata e ricca di interazioni, non e' proprio tutto tutto tempo perso.
Certo, non sono tutte rose e fiori: nessuno al mondo mi convincera' mai che uno schema UML abbia una qualsivoglia utilita', sia pratica che teorica, e neppure credo che l'"astrazione a tutti i costi" porti ad un approccio sano a quello che, volenti o nolenti, un giorno o l'altro dovra' essere tradotto in codice usando strumenti e librerie fatte in tutt'altro modo rispetto alla rappresentazione concettuale che ci si era fatti. Pero' molto altro si salva dalla mia osservazione critica: in primis il fatto di partire con la propria analisi non gia' dalla struttura del sistema ma da quello che dovra' fare e da cosa ci si aspetta che faccia in determinate condizioni, criterio apparentemente scontato ma non cosi' banale, ed in secundis la volonta' di implementare un prototipo per valutare sul campo l'API disegnata; a tutt'oggi storco un pochino il naso all'idea di scrivere del codice (in Python, oltretutto...) che ha lo scopo di essere buttato dopo una rapida occhiata, ma non nego che tale concetto possa risultare vincente nell'ottica di poter profilare l'architettura basandosi su dati reali anziche' su un disegnino tracciato su un foglio.
Ieri sera, per questioni personali, ho noleggiato un Virtual Private Server (cosa che suggerisco a tutti: oramai si pigliano ottime macchine a bassissimo costo, ed avere a disposizione una macchina sempre esposta sull'Internet e' una immensa comodita'), e tra i desideri del prossimo periodo vi e' quello di spostare su di esso lo sviluppo del Progetto Lobotomy: il sito, il repository (quando ci sara' del codice da condividere...), il futuro prototipo web di cui da tempo parlo, ma da principio credo che, al pari dei miei colleghi milanesi, installero' una istanza di Trac da usare come collettore di impressioni ed idee, da ordinare poi disciplinatamente e da cui estrarre poi una raccolta di "requirements" da usare come guida e riferimento in fase di definizione del sistema vero e proprio.
E che sia la volta buona che riesco a concretizzare almeno una parte delle infinite idee che ho in merito a tali ciclopica impresa.

La Sottile Linea

Abbastanza inevitabilmente, dato il mio interesse sia per i progressi nel campo dell'interfaccia uomo-macchina sia per le novita' nel mondo freesoftware, mi trovo a leggere talvolta in merito a KDE4.
Sorvolando sui commenti piu' o meno soggettivi in merito alla stabilita' del prodotto o alla presunta somiglianza con il non propriamente amato Windows Vista e' interessante vedere come il team del progetto sia proiettato verso la sperimentazione di nuove forme di interazione e presentazione, e l'ultimo bollettino proveniente dall'ennesimo meeting degli sviluppatori menziona una serie di interventi che si vogliono apportare per perfezionare l'integrazione fra le componenti.
Ma il punto e' proprio questo: al di la' dell'introduzione del supporto alle animazioni, la sommaria integrazione con OpenDesktop, e la serie di nuovi plasmoidi che man mano vanno ad infoltire il set di quelli con cui l'utente puo' personalizzare, nell'attuale versione 4.2 ed in tutte le possibili evoluzioni annunciate e non, cosa c'e' di realmente nuovo? Quello che dall'intero mondo free viene osannato ed indicato come rivoluzionario e radicale progetto, cos'altro e' se non il solito desktop arricchito da qualche animazione? Persino il team di Gnome, environment che da sempre si caratterizza per la coerenza anche fra applicazioni diverse e la pulizia dell'API, sta cedendo alle lusinghe della popolatita' e per non essere da meno a KDE sta includendo deplorevoli funzionalita' di dubbio gusto.
So di aver ripetuto questa manfrina piu' di una volta, anche su questo blog, ma ogni qualvolta torno a leggere gli stessi entusiastici commenti rivolti a qualcosa che di entusiasmante ha poco se non gli screenshots torno a riflettere sulla questione: si cerca di elevare un pochino il grado di integrazione reciproca tra le diverse applicazioni, si aggiungono strabilianti features grafiche (che non fanno altro che aggiungere possibilita' di infrangere ogni genere di coerenza tra le applicazioni), eppure la sottile linea che separa l'innovazione dal rimaneggiamento non viene mai oltrepassata.
Mi capacito del fatto che tale linea, in fin dei conti, tanto "sottile" non e', in quanto implicherebbe una riscrittura drastica dell'intero concetto di "computer general purpose con una interfaccia grafica", ma chiaramente ci si trova sempre a scontrarsi con l'abitudine della becera utenza e l'impossibilita' di diffondere agevolmente presso la massa elementi di novita'.
Ah, ho una gran voglia di tornare a lavorare su Lobotomy...

Ma il Multitouch...

Da lungo tempo, e soprattutto da quando l'iPhone rappresenta uno dei maggiori centri di gravita' dell'informazione spiccia tecnologica, si fa un gran parlare di multitouch. Ogniqualvolta esce un nuovo dispositivo, in particolare mobile, uno dei primi criteri di valutazione e' il suo supporto a tale meccanismo di input: se e' possibile usare piu' dita per manipolare l'interfaccia e' figo, altrimenti no.
Poco tempo addietro ho marginalmente toccato l'argomento facendo notare che ancora non avevo espresso un mio parere completo nei confronti di tale strumento, ed e' venuto il momento di approfondire.
Quando vidi il primo (o comunque il piu' noto) video in cui veniva mostrata una interfaccia di tal fatta ne rimasi come tutti entusiasta, anche se chiaramente la maggior parte della mia ammirazione derivava dalla novita' e dalla teatralita' dell'effetto in se'. Da allora altri filmati sono spuntati in Rete a decine, a centinaia, in ogni dove, in cui si vedevano persone che navigavano mappe, ridimensionavano e spostavano foto, e... Beh, nulla di piu'.
Alla fine e' evidente che allo stato odierno la tecnologia c'e', ma non ne esiste alcun utilizzo pratico: certamente questa e' solo una impressione dettata dal fatto che la stragrande maggioranza dei demo puntano a stupire l'utente medio, ed il software per trattare il ridimensionamento delle immagini allontanando ed avvicinando le dita e' sufficientemente banale (di librerie, anche open, che permettono di farlo e' pieno) da garantire un bel risultato scenografico con un minimo sforzo, ma finche' non esistera' una innovazione che renda codesto meccanismo realmente appetibile temo che cio' restera' semplicemente un decorativo orpello da nerd ed una strategia di marketing.
Gia' ce n'e' voluto del buono per ottenere qualche progresso nella fase di studio per un paradigma di user interface adatto al touchscreen, e comunque siamo ancora lontani da un risultato ottimale; figuriamoci quanto si dovra' attendere prima che il multitouch diventi parte integrante di tale paradigma. Ed io stesso non riesco a figurarmi particolari funzionalita' speciali che potrebbero essere implementate solo in virtu' del tocco multiplo.
Dunque: al momento non mi faccio particolarmente impressionare quando nel corso di una presentazione l'imbonitore di turno orgogliosamente fa vedere le sue agili ditina andare parallelamente su e giu' sullo schermo, e neppure mi curo del fatto che un tale apparato abbia o meno tale supporto hardware. Di strada da fare prima di arrivare a quello ce n'e' ancora tanta.

Divide et Impera

Oramai ho cosi' tanti e variegati impegni che finiscono col sovrapporsi l'un l'altro secondo i piu' arzigogolati percorsi, ma cio' ha il lato positivo che con un singolo task ottengo piu' risultati utili per contesti completamente diversi. E' questo il caso del modestissimo progettino (sarebbe meglio chiamarlo "giocattolo") che ho aperto l'altro giorno su BarberaWare: Mignon, un client per le webradio.
In un colpo solo ho ottenuto: un playground ove iniziare a pacioccare e a prender mano con Python, orribile ed ingestibile linguaggio che mi tocca apprendere per assolvere ad alcune richieste del mio nuovo prossimo lavoro; un programmino da eseguire prossimamente nel PC recentemente installato in cucina, e con cui ascoltare il giornale radio cenando pur senza dover portare a spasso il laptop come attualmente faccio; una prima implementazione sperimentale di un concetto che gia' riportai su questo blog, in merito alla netta divisione di funzionalita' ed interfaccia del software. Sorvolo qui sulle invettive all'indecente linguaggio sopra menzionato ed alle mie abitudini domestiche, mentre mi soffermo su qualche considerazione in merito all'ultimo punto (l'unico dei tre in-topic su questo blog), forse banale e non particolarmente ricca a causa della modestia della mia attuale esperienza ma che quantomeno riporto per conoscenza.
Sviluppare una applicazione ove funzionalita' e interfaccia sono distinte non e' complesso, quantomeno non piu' che non progettare e realizzare un qualsiasi altro software con un po' di criterio: l'unico elemento cui probabilmente occorre prestare particolare attenzione e' la quantita' e la frequenza degli scambi di informazione tra i due strati: avendo a che fare con un protocollo IPC (che sia DBus o una coda di messaggi poco importa, sempre un qualche tipo di syscall esplicito o implicito e' necessario) meno memoria si sposta e meglio e', e le risposte non possono essere ne' istantanee ne' in realtime come all'interno di un unico processo. Di contro, come ci si puo' bene immaginare la flessibilita' della piattaforma e' completa: al momento il mio modesto programmino dispone solo di una umile interfaccia a linea di comando, ma gia' sto progettando di realizzare quella grafica in QT (altra tecnologia che mi tocca apprendere per intraprendere il mio nuovo mestiere) e quella web senza intaccare minimamente il core dedito all'interrogazione dei vari servizi di directory dei canali radio e alla riproduzione audio.
In sostanza: il paradigma mi garba e mi sembra utilizzabile senza particolare sforzo.
Un colpo al cerchio ed uno alla botte, alla fine qualcosa riesco sempre a combinare...

Canale Libero

Gia' da qualche tempo avevo scoperto identi.ca, servizio di microblogging in tutto e per tutto simile a Twitter ma la cui piattaforma e' interamente opensource e costruita intorno a standard aperti. Ma all'epoca mancavano ancora tanti servizi e tante features, quelle che rendono davvero utile (se davvero il microblogging puo' essere definito "utile"...) una applicazione del genere, cosi' lasciai perdere e rimasi sul piu' noto e supportato Twitter.
Questa sera per qualche strano motivo sono tornato a dare uno sguardo al sito, ed ho visto che grandissimi passi avanti sono stati fatti: molte piu' funzionalita', una serie di correzioni piu' o meno evidenti, ed un numero di applicazioni che sfruttano i contenuti pubblicati per mezzo del servizio per trasformarli in mille modi. E cosi', dopo una mezz'oretta passata a ritoccare qua e la', sono riuscito a ricostruire la catena di strumenti da me usata: con Ubiquity aggiungo nuovi "post" nella mia pagina, una applicazione dedicata li piglia e li usa per aggiornare il mio status su Facebook, ed un'altro servizio preleva il feed RSS e ne ricava il bagde visualizzato nel mio blog.
Per quanto identi.ca non raggiungera' forse mai la popolarita' di Twitter (ma non e' detto: spesso quest'ultimo e' fuori servizio, e la prossima messa a punto del suo businness model potrebbero renderlo meno aperto verso gli innumerevoli servizi esterni forniti) e' bello vedere che una community abbia realizzato tutto questo, soprattutto alla luce degli avvenimenti recenti: sempre piu' pressioni si fanno per adoperare e far adoperare standard aperti sull'Internet in modo da garantire interoperabilita' tra le piattaforme, e non pochi sono coloro che sostengono l'utilizzo di software a codice aperto anche sul web in modo da stimolare la nascita di sempre nuovi e ricchi strumenti non solo da parte dei colossi (che in questo periodo di crisi certo non hanno troppi soldi da creare e mantenere iniziative eccessivamente stravaganti) ma anche e soprattutto per mezzo di volontari col pallino per la programmazione; persino Google sta ponderando il rilascio del codice di Jaiku, altro sito di microblogging spesso identificato come l'anti-Twitter, a fronte dell'eccessivo carico di risorse necessarie per mandare avanti la baracca.
E da oggi anche le mie microfacezie sono free as in speech...

Tooltip o non Tooltip

Da qualche tempo sto sperimentando all'interno di GASdotto una soluzione che, nell'idea, dovrebbe essere un compromesso per l'esposizione di un help contestuale da fornire all'utente per permettergli di muoversi tra le opzioni offerte dall'interfaccia.
Partiamo da qualche assunzione: per quanto le icone possano rappresentare un bell'aiuto in termini di individuazione dei tasti e delle funzionalita' desiderate in ogni momento, purtroppo non sempre possono essere universalmente autoesplicative e comunque l'utente, almeno la prima volta che vede l'interfaccia, non ha idea di dove trovare cosa e non si puo' dunque giocare sulla sua consuetudine. Soprattutto in un programma (come appunto GASdotto) destinato ad essere usato saltuariamente, senza una frequenza costante, e per cui dunque ogni nozione appresa dall'utente puo' essersi persa nell'intervallo tra una sessione e l'altra.
Una qualche sorta di aiuto contestuale che guidi e sostenga l'utente nell'utilizzo e' pressoche' d'obbligo, sebbene sia indispensabile raggiungere un compromesso affinche' tale help in linea sia efficace ma non risulti invasivo.
Quel che e' quasi uno standard de facto in tale contesto, almeno sul desktop, sono i tooltips, ovvero quelle frasette che appaiono passando e soffermando il cursore del mouse sull'elemento di cui si vuol conoscere la funzione. Tale metodo, pero', mi pare estremamente poco efficiente e prono ad ogni genere di abuso: ci sono tooltips lunghi venti righe che includono tutto lo scibile in merito al dato tasto, altri che non riportarno null'altro se non il testo del pulsante stesso (risultando percio' poco informativi...), ma la situazione peggiore in assoluto (nonche' la piu' comune) si verifica quando solo alcuni elementi sono forniti di un tooltip ed altri no: quante volte e' capitato a me stesso di constatare la presenza della finestrella gialla in sovraimpressione passando in un dato punto, spostare il mouse laddove mi serviva, attendere un istante la comparsa della descrizione, muovere ancora un poco il cursore per essere ben certo di aver centrato il tasto di cui avrei gradito un commento, ed alla fine capacitarmi del fatto che nessun tip era disponibile per quello!
La soluzione da me adottata trae ispirazione dalla piu' recente versione di Wordpress: editando uno dei numerosi blogs che mantengo su tale piattaforma ho visto come passando il mouse sui titoli dei posts che appaiono nella lista di articoli modificabili spuntino i links che ne permettono la correzione, la cancellazione ed altre attivita', tutte opzioni che se visualizzate tutte insieme avrebbero appesantito la pagina ma in questo modo risultano comodamente raggiungibili e molto facilmente "scopribili". Per il prossimo futuro vorrei meglio analizzare questo approccio, ma per adesso mi sono limitato a scopiazzarlo impunemente per trattare, come detto sinora, l'help.

Per accertarmi che ogni utente sapesse come comportarsi nei confronti delle tre icone associate ad ogni elemento editabile (salva, elimina, o annulla operazione) ho pensato di piazzarvi sotto una descrizione che apparisse solo al passaggio del cursore del mouse, affinche' il testo non andasse ad incidere sulla linearita' della pagina ma al contempo fosse visibile nel momento opportuno.
Sono abbastanza soddisfatto di questa soluzione anche se ammetto necessiti forse di migliore implementazione (il codice e' talmente elementare che non sto manco a pubblicarlo), cerchero' di riutilizzarla anche in altri contesti per valutare la sua bonta'.