Una Mela in Testa

Da quando ho iniziato a leggere e documentarmi sul tema dell'usabilita' delle interfacce utente ho piu' volte sentito parlare nell'Apple Newton, PDA uscito agli inizi degli anni '90 e di breve vita sul mercato, indicato da molti come un ottimo esempio di efficienza e rappresentativo di alcuni concetti particolarmente interessanti. Ma ammetto di non aver mai indagato approfonditamente su tale oggetto, prendendo sempre per buone le entusiastiche dichiarazioni ma inconsciamente pensando che le funzionalita' di tale apparecchio fossero, a causa dell'evidente anzianita' del prodotto, cosi' limitate da non meritare neppure di essere prese in considerazione.

Finche' l'altro giorno mi sono trovato a leggere un articolo (peraltro generatore di infinita ispirazione, dovro' tornarci sopra in futuro), in cui viene indirettamente linkato un video su YouTube che dimostra l'utilizzo del leggendario Newton. E ne sono rimasto sbalordito.

L'utilizzo del device e' molto semplice: c'e' uno schermo completamente touchscreen, ci si scrive sopra quel che si vuole (con la tastiera virtuale o a mano: stando al video l'handwriting recognization del '90 non era cosi' tanto male, e' un peccato che nel ventennio seguente non sia piu' stata migliorata), e... il contenuto viene trasformato in un altro tipo di contenuto a seconda di quello che viene riconosciuto, o dietro suggerimento dell'utente. Insomma: se si scrive "pranzo con Mario" si puo' andare a piazzare il nuovo appuntamento nel calendar, se si scrive "chiama Pippo" viene lanciata la chiamata, se si immette un numero telefonico si apre il form per la creazione di un nuovo contatto.

Chiaramente, il primo richiamo che ho avuto e' stato il progetto Lobotomy e l'originale idea di rendere trasversali i dati indipendentemente dal formato con cui venivano trasmessi o manipolati. Anche se il concetto introdotto nel Newton e' un poco diverso: non quello di trasformare i vari contenuti in qualcos'altro, ma trasformare caso per caso un unico tipo di contenuto (la nota, atomo primario del modello di interazione) in qualcosa di piu' strutturato e specifico.

Resta il fatto che gia' allora gli ingegneri Apple avevano avuto l'illuminazione e l'avevano trasposta in un prodotto commerciale e alla portata degli utenti (si, d'accordo: solo degli utenti facoltosi, considerando il prezzo, ma ci siamo capiti...): ignorare totalmente nozioni tecniche e nerdeggianti come il "file" o il "formato", ma occuparsi in modo semi-automatizzato di tali dettagli e lasciare che l'utilizzatore si concentrasse sull'informazione nuda e cruda.

Il PDA in oggetto spari' rapidamente dal mercato, vuoi perche' le tecnologie hardware dell'epoca erano ancora troppo limitate per uno sfruttamento del concept (una agenza cartacea delle stesse dimensioni poteva tranquillamente contenere una mole di informazioni molto superiore rispetto ai suoi modesti circuiti di rame e pietra), vuoi perche' il popolo di consumatori non era ancora pronto per esso (nell'era pre-Web2.0 quanti sarebbero stati disposti a spendere quella cifra per un blocco note molto sofisticato?) e vuoi anche perche' essendo tutto il sistema integrato non c'era spazio per l'ingresso di altri vendors che fornissero applicazioni e servizi (come e' invece adesso per apparati tipo l'iPad) dunque nessuno poteva essere realmente interessato alla sua diffusione priva da sbocchi commerciali e profittevoli per chiunque altro non fosse Apple. Ma a distanza di vent'anni varrebbe la pena rivalutare e riesaminare i concetti che all'epoca sono stati compressi nello scatolotto nero, poco apprezzabili negli anni '90 ma perfettamente attuali ed anzi impellenti nel mondo di oggi.

Perche' reinventare la ruota, quando buona parte del lavoro e' gia' stata svolta?

Aggiornamento nell'Ombra

Manco il tempo di finire di scrivere il precedente post sui potenziali vantaggi di un meccanismo di aggiornamento interno alle applicazioni, in grado di pescare autonomamente informazioni sulla disponibilita' di nuove versioni da scaricare ed installare in modo trasparente e senza disturbare l'utente, che subito salgono agli onori della cronaca notizie sulle prossime evoluzioni di Chrome, il web browser targato Google.

Stando alle ultime presentazioni per il prossimo futuro di tale prodotto si prevede di soppiantare la tendenza prettamente tecnofila di rilasciare le varie versioni identificandole da un numero sequenziale, ed invece impacchettare piccoli cambiamenti ad intervalli regolari e tra loro ristretti (sei mesi) e diffonderli sui desktop del pianeta con un automatismo silenzioso. A ben guardare Chrome da sempre gestisce in questo modo gli aggiornamenti di se' stesso, addirittura compiendo un controllo sul repository centralizzato ogni cinque ore, ma evidentemente il concetto e' stato migliorato e raffinato ulteriormente. Si mormora inoltre che pure la prossima major release di Firefox, la 4 includera' tale funzionalita'.

Come intuibile, appunto, dal post pubblicato l'altro giorno su questo stesso blog questo genere di soluzioni mi garba assai. Tantopiu' per applicativi come i web browser, diventati strumenti essenziali nella vita digitale di ciascuno e cosi' frequentemente bersagliati da attacchi mirati alla loro sicurezza da patchare il piu' presto possibile a prescindere dalla noncuranza dell'utente. Certo chi sviluppa un browser non ha tutta questa urgenza di diffondere nuove features, in quanto in fin dei conti tale classe di software operativo non espone particolari funzionalita' necessariamente sempre nuove (renderizzano le pagine, salvano i bookmarks, aprono e chiudono le tabs, poco altro), ma le migliorie per quanto piccole e discrete son sempre gradite, soprattutto quando non ci si deve attivare in prima persona per ottenerle.

D'altro canto, immagino che nel momento in cui i singoli programmi provvedano per conto proprio all'aggiornamento si possano creare non pochi grattacapi per i packagers delle distribuzioni. Cosa mettere nei repository? Cosa succede se all'atto dell'invocazione di un "apt-get upgrade" la versione proposta e pacchettizzata e' piu' vecchia di quella scaricata autonomamente? Come fronteggiare eventuali aggiornamenti che richiedono librerie e pacchetti particolari, e dunque da installare o a loro volta aggiornare per il supporto di una nuova funzionalita'?

Per non parlare dei futuri (ma comunque non immediati) problemi tecnici che potrebbero sorgere qualora tale pratica dovesse diffondersi: come arginare la potenziale esplosione di comunicazioni verso l'Internet, dovute al fatto che ogni singolo programma pretenderebbe di contatterebbe ad intervalli periodici il proprio server di riferimento in cerca di qualcosa di nuovo da scaricare? E come reagirebbe quella nicchia di utenti cultori della privacy e del pieno controllo dinnanzi alla necessita' di dover disabilitare (o nella peggiore delle ipotesi filtrare con metodi piu' radicali) siffatte transazioni non richieste per ognuno dei software utilizzati?

La soluzione ad entrambi i suddetti tipi di ostacoli potrebbe stare in una evoluzione degli attuali package managers, affinche' forniscano nativamente la funzionalita' di auto-upgrade per i programmi che lo richiedono, coordinando ed ottimizzando le connessioni verso l'esterno e provvedendo un unico centro di configurazione per chi ha il tempo da perdere verificando chi sta facendo cosa. Dirottando tutto al manager centralizzato esso sarebbe sempre consapevole di quale precisa versione e' in uso in un dato momento, quali sono i pacchetti che si auto-aggiornano per fatti propri e quali devono essere allineati con i repository della distribuzione secondo lo schema classico, e come comportarsi con le dipendenze.

Forse adesso e' troppo presto per porsi questo genere di domande, in quanto appunto solo Chrome e Firefox si stanno muovendo verso la direzione dell'autogestione. Ma nel momento in cui dovesse essere osservato un trend piu' cospicuo sarebbe opportuno correre ai ripari il prima possibile, mettendosi d'accordo tutti insieme su come amministrare in modo pacifico la legittima richiesta di aggiornamenti frequenti con la necessita' di far convivere numerosi pacchetti ognuno con una propria sequenza di versioning, ed evitare che codesta emergente moda dilaghi fino a minare uno dei pilastri su cui si poggia il successo del desktop Linux, appunto il package management.

Prevenire e' meglio che curare.

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

Faldoni VS Database

L'altro giorno mi sono recato con un amico presso un piccolo produttore agricolo con lo scopo (che non intendo qui approfondire nel dettaglio) di appurare come utilizzasse lui il computer nello svolgimento delle sue pratiche burocratiche e produttive. Ne e' emerso uno scenario perfettamente prevedibile e scontato, ma non per questo meno disarmante: il PC viene usato pressoche' esclusivamente come macchina da scrivere, per compilare bolle e fatture da stampare e maneggiare poi analogicamente (= su carta).
L'apoteosi dello sconforto l'ho raggiunta quando il suddetto agricoltore (lui, come lo potrebbe fare la stragrande maggioranza dell'utenza informatica di basso livello odierna) ha apertamente ammesso che il computer, massima espressione della scienza tecnologica nella sua esistenza rurale, e' un problema inevitabile piu' che una soluzione desiderabile: difficile da usare, incomprensibile, caotico, con l'unico pregio che con un paio di copia&incolla si velocizza qualche sporadica operazione nella compilazione dei moduli che se altrimenti fatta a mano richiederebbe piu' tempo. Mentre diceva cio', io guardavo il vicino armadio carico di faldoni e carte accumulate dopo essere uscite dalla stampante del vituperato marchingegno digitale, certamente perche' il personaggio riesce meglio a scartabellare e cercare cio' che gli serve su supporto fisico anziche' tra le cartelle virtuali del filesystem.
Del resto, neppure mi sento di dargli tutti i torti: il computer ha un costo, cosiccome la licenza di Excel installata sopra (suppongo sia stato originale, acquistato in bundle con la macchina numerosi anni addietro, e se anche fosse stato pirata glielo ha installato qualche pseudo tecnico in qualche negozietto di informatica facendosi comunque pagare per il disturbo), e tale applicativo viene usato per compiti ben piu' complessi ed avanzati che non quelli per cui e' stato ideato. L'acquisto di un software specifico per la sua attivita' costerebbe 3000 euri (e non e' una stima: il programma esiste davvero e gli e' stato offerto esattamente a quella cifra), e per esperienza gia' so che si tratterebbe comunque di un accrocchio Visual Basic + Access messo in piedi alla meno peggio con lo scopo esplicito dell'azienda produttrice di trarre profitto ulteriore con i corsi per sommariamente imparare ad usarlo e l'assistenza. Pertanto ci si arrangia con quel che si ha, ovvero qualche programma realizzato da vendors diversi tra loro nient'affatto integrati, con interfacce diverse e carichi di features introdotte per giustificare le nuove release, e appena possibile si ricorre al tasto "Stampa" per portare le informazioni importanti fuori dal ronzante scatolone di plastica e alluminio.
Non oso neppure immaginare cosa la piu' scarsa e umile tecnologia digitale oggi esistente potrebbe realmente fare per quest'uomo: i dati, se immessi in un database, potrebbero essere spulciati e tra loro intersecati con dettaglio estremo in pochi secondi; le anagrafiche di fornitori e clienti, se formattate in hCard e gestite direttamente dagli interessati, potrebbero essere pescate dall'Internet ed aggiornate automaticamente, e istantaneamente accessibili digitando tre caratteri del nome; i documenti potrebbero calcolarsi per conto proprio quantita' totali, prezzi totali, IVA e altri parametri burocratici partendo da pochi valori relativi alla merce ricevuta o da consegnare; gli stessi totali potrebbero essere trasmessi al commercialista in formato digitale, e questo potrebbe a sua volta importarli nel suo proprio programma per farci quel che deve farci; i pagamenti, se trasferiti per via telematica, sarebbero usati seduta stante per computare bilanci ed introiti (o al contrario innescare sollecitazioni automatiche se non arrivati in tempo). Senza parlare del risparmio di carta, inchiostro e spazio.
Se nell'Anno Domini 2010 tutte le attivita' produttive e commerciali ancora non hanno trovato nella tecnologia un valido ed appropriato supporto la causa non e' solo delle ovvie resistenze riscontrate presso il grande pubblico nei confronti delle novita' ma anche e soprattutto da imputare a coloro che dovrebbero provvedere alla messa in opera di questi semplici e talvolta persino banali (per un tecnico, intendo) strumenti, e che speculano sulla scarsa consapevolezza e dimestichezza dei propri clienti per spremere ogni singolo centesimo dalla loro ingenuita'.
Le cose possono cambiare. Devono cambiare. Poche righe di codice, se stese con criterio, possono allo stesso tempo ridurre il tempo (e dunque il costo) necessario a svolgere una operazione, aiutare a massimizzare i profitti incentivando particolari scambi monetari, e salvare un albero destinato a diventare carta da stampa. E' venuta l'ora di iniziare a scriverle.

Stay Focus

"Stay focus" e' una espressione spesso usata dal mio attuale project manager in Itsme. Mi piace, nella sua infinita semplicita' (e nella mia personale interpretazione) esprime bene la necessita' di mantenere l'attenzione entro un dato contesto e su determinati obiettivi. Proprio a me, che quasi continuamente zompo tra un blocco di codice e l'altro senza soluzione di continuita'...

La citazione mi e' tornata alla mente leggendo questo articolo, ennesima colonna da opinionista sul gossip nerd del momento, l'oramai imminente iSlate. Al di la' delle speculazioni dell'autore, che tendenzialmente posso anche approvare ma che in mancanza di un prodotto concreto da commentare risultano sterili chiacchere da bar, i primi paragrafi sono assai interessanti. Un po' per i contenuti, un po' per gli stimoli: in essi viene menzionata la figura di Jef Raskin, mia inesauribile fonte di ispirazione diretta ed indiretta, e la sua posizione radicale nei confronti dell'usabilita' degli apparati tecnologici.

Consiglio la lettura del pezzo ma non commento qui nel dettaglio ne' la prima ne' la seconda parte: basti sapere che rileggere tali spunti e tali prospettive e' stato sufficiente per riportarmi alla mente i sopiti ma mai defunti propositi di applicarmi in prima persona, nel mio piccolo, per rendere piu' accessibili e a misura d'uomo gli strumenti offerti dal progresso.

Proprio ieri sera ho partecipato ad una riunioncina con gli altri personaggi coinvolti nel progetto GASdotto, per fare il punto dopo la pausa imposta dalle vacanze natalizie. Pare che gli attuali utilizzatori, in tutto circa un centinaio, siano entusiasti della facilita' d'uso di questa applicazione, e sebbene ci sia ancora parecchio da fare sia in termini operativi che estetici ci siamo spinti a delineare le funzionalita' da includere nella prossima versione 2.0 . Alla luce degli istinti suscitati e risuscitati dalla summenzionata lettura, mi vengono i brividi alla schiena ripensando alla quantita' di pulsantini e opzioncine che tra una birra ed un po' di vino sono stati idealmente introdotti per azioni tutto sommato minime ed oziose, che potrebbero forse risultare comode per chi oramai avvezzo all'impianto ma risulterebbero totalmente incomprensibili a chi si avvicina per la prima volta o anche ad un utente gia' preparato che (ovviamente) non si trova dinnanzi a queste schermate tutti i giorni e legittimamente puo' scordarsi il significato di un determinato quadratino colorato sul monitor. Nei prossimi mesi dovro' studiare qualche soluzione per automatizzare l'automatizzabile, celare il celabile, e svelare alla vista qualcosa solo quanto realmente necessario ed indispensabile. Onde evitare il classico "effetto acccumulo" per cui quasi inevitabilmente ogni nuova versione di qualsiasi software stratifica qualche orpello, qualche ammenicolo, qualche cineseria in piu' rendendo il tutto a lungo andare una accozzaglia indefinita e pesante, sia da vedere che da usare.

Lo stesso vale per ogni altro progetto attualmente in corso, che come al solito sono tanti - e anche troppi -: ad esempio negli ultimi giorni ho giocato un pochino con jQuery con la mira di metter su una sorta di servizio web, e non nego di essermi fatto prendere la mano dalla semplicita' con cui e' possibile aggiungere effetti ed animazioni estremamente cool ma dalla assai scarsa utilita'. Tale genere di garbugli possono sedurre l'occhio la prima volta, la seconda, alla terza diventano una perdita di tempo ed un carico in piu' per il processore.

Insomma: mi rendo conto di aver ultimamente un po' lasciato da parte lo scopo globale, il "focus" appunto, e di essermi fatto coinvolgere un po' dalla immediatezza e dalla spettacolarita' degli strumenti programmatori oggi a disposizione ed un po' dalla necessita' di far le cose magari non proprio sempre in modo ponderato - e di conseguenza male. Dovro' fare un esame di coscienza e stare piu' accorto, rinunciare a qualche evoluzione ed immolarmi maggiormente alla linearita', tenendo sempre ben presente cosa c'e' da fare nel suo insieme.

Stay focus. Always.

Il Nome della Cosa

Qualche tempo fa' in Itsme sono passati alcuni ospiti: come sempre abbiamo fatto la nostra presentazione del progetto, come sempre ci sono state domande tecniche e meno tecniche, e tra tutte le osservazioni emerse una in particolare mi ha ispirato il qui presente post. In realta' si tratta di un commento piu' e piu' volte sollevato in merito all'opera in corso, carpito in circostanze piu' o meno ufficiali e che suona come "Itsme e' basato su Linux, ma Linux e' difficile da usare".
Sorvolando sulle obiezioni di natura culturale e pedagogica, per cui un meccanismo complesso come un intero sistema operativo non puo' essere a priori "facile" o "difficile" ma necessariamente richieste un periodo di addestramento ed un disadattamento all'attivita' su altre piattaforme analoghe rendendo di fatto "difficile" tutto quello che non si e' usato fino al giorno prima, cio' che mi perplime e' il pregiudizio di fondo nei confronti di Linux.
Per quanto nel corso delle dimostrazioni Itsme si parli dell'interfaccia che stiamo completamente ri-disegnando e re-implementando per adattarsi alla metafora di riferimento, cosiccome stiamo ri-disegnando e re-implementando gli automatismi di fondo che permettono la configurazione, "Linux e' difficile". Tale assioma e' assunto indipendentemente dalla modalita' grafica con cui il sistema si presenta, degli strumenti di tuning messi a disposizione, dei wizards automatici gia' previsti per sopperire ad eventuali mancanze ed integrare componenti gia' noti nel piano: "Linux e' difficile".
Eppure a me non pare che nessuno si sia mai grattato il capo in modo imbarazzato usando un cellulare Motorola, spedendo richieste a Google, o anche facendo un biglietto della metropolitana qui a Torino. Questo perche' i tre fruitori di cui sopra, e buona parte di tutti gli altri fornitori di hardware e servizi Linux-based, dell'amato sistema operativo utilizzano la tecnologia di base ed hanno personalizzato per conto proprio la parte con cui l'utente interagisce, rendendo piu' o meno "facile" l'uso dell'apparato a seconda del fine predestinato. Ne' piu' ne' meno di quanto fatto da Apple con MacOS X, partendo da una base BSD (che di per se' puo' essere considerato ancor piu' ostico che Linux stesso) e costruendoci sopra il proprio stack applicativo, rinomato come il piu' user-friendly sul mercato: sarebbe sensato affermare che MacOS e' "difficile" da usare perche' ha nel kernel lo stesso scheduler di BSD, laddove l'utilizzatore non sospetta neppure l'esistenza di un'arnese chiamato "scheduler"?
E se anche fosse vero che, diciamo, una Ubuntu e' meno usabile di un Windows (argomento discutibile ed opinabile), e' altrettanto vero che godendo di una netta separazione tra i layer operativi Linux si presta molto di piu' ad una drastica personalizzazione dell'insieme e da esso e' molto piu' facile cavare qualcosa di realmente nuovo e pratico mantendendo intonse le porzioni di basso livello (gestione dei devices, librerie software, toolkits grafici, alcuni applicativi) e stravolgendo il resto, a propria discrezione e secondo la propria necessita'. Stando alla mia esperienza sinora ho lavorato su un apparato embedded per telecomunicazioni ed una workstation desktop, e su entrambi il software di basso livello era lo stesso, ovvero un kernel e qualche libreria.
Stat Linux pristina nomine, nomina nuda tenemus.

Mail, XML e Thumbs

Questo post non e' per un commento o una divagazione specifica e mirata, ma semplicemente per aggiornare i miei lettori sulle attivita' correnti. Del resto, se non ho tempo di bloggare e' perche' ho altro da fare.
Per conto di Itsme negli ultimi giorni ho dovuto "smontare" Evolution, il client mail di Gnome, e trarne una sorta di mail client batch, che non interagisca con l'utente per mezzo di una interfaccia grafica ma popoli il database del backend con le mail in ingresso ed intercetti le nuove mail create (sempre sul database) per spedirle. Al di la' del gusto intrinseco di codesta attivita' (andare a mettere il naso in qualche progetto open ha sempre il suo fascino...) la cosa interessante e' che, con qualche opportuno ritocco qua e la', codesto componente potrebbe divenire il primo pezzo concreto del SubConsciousDaemon di Lobotomy: il funzionamento e' esattamente quello che contavo di realizzare appunto per il mio ambiente, dunque tanto vale riutilizzare questo codice che sara' comunque prossimamente rilasciato in licenza free.
Sempre in merito a Lobotomy: sembra quasi incredibile, ma son tornato a lavorarci. Negli scorsi giorni ho ripreso in mano il dialetto XML per i Thoughts, per accertarmi del fatto che vengano coperti tutti i casi piu' comuni e che comunque non esistano limiti intrinsechi alla definizione di pressoche' tutte le "applicazioni" utili. A breve, terminati gli altri task gia' in corso (e descritti sotto) conto finalmente di iniziare Synapse, ovvero l'interprete del suddetto XML e piu' in generale il gestore dei templates.
Altrove sto ultimando l'opera sul generatore di thumbs dai contenuti di Gnome-Look.org: nonostante abbia avuto un po' da magheggiare per ottenere il risultato desiderato, in quanto i links dei temi da cui trarre la preview non sono fatti per essere trattati programmaticamente e negli archivi compressi i files sono organizzati spesso in modi totalmente arbitrari, e nonostante le limitazioni tecniche sul VPS su cui andra' poi a girare il sito (non son riuscito ad eseguire X.org non essendoci giustamente una scheda grafica, e senza X.org non si puo' lanciare il codice di generazione batch delle thumbs), il demone preposto al download ed all'elaborazione dei temi GTK e Metacity e' pressoche' pronto ed ora debbo solo rifinire l'interfaccia web del sistema. Una volta completata anche quella sottoporro' pure questo progetto al Social Desktop Contest, che ad un mese dalla chiusura conta un solo partecipante (me!) e da cui posso dunque sperare in una proclamazione: sembra la sceneggiatura di uno spot del Gratta e Vinci, quelli della serie "Ti piace vincere facile?", ma se cio' comporta l'acquisizione da parte mia di un netbook non me ne lamento.
Insomma, c'e' sempre qualcosa su cui lavorare...

Tanto va il Bob al Largo...

Ci sono situazioni della vita in cui non si puo' non restare affascinati dinnanzi agli inaspettati risultati che una caotica serie di eventi puo' produrre: ho piu' volte conosciuto per puro caso persone che a distanza di tempo ed in intricate circostanze si sono rilevate indispensabili, ho vissuto esperienze incredibilmente belle o incredibilmente brutte che mi hanno permesso di accedere ad altri scenari ancora piu' estremi, e mi sono trovato in condizioni paradossali a seguito di non meglio descrivibili catene di cause ed effetti.
Questa e' una di quelle situazioni.

Io, eterno scettico nei confronti del desktop semantico, e acceso critico nei confronti di organizzazioni ufficiali e para-corporate nel contesto dello sviluppo free, sono da oggi co-maintainer di un componente di Nepomuk.
Non sto qui a spiegare il come ed il perche' di tale evoluzione, e se lo facessi comunque pubblicherei il resoconto sul mio blog piu' "politicamente attivo" a causa dei risvolti che la vicenda ha e continuera' ad avere, ma basti qui menzionare il fatto che nel prossimo periodo avro' modo di approfondire persino piu' del dovuto il tema delle tecnologie semantiche ed i loro risvolti.

L'incarico si prospetta tutt'altro che semplice, considerando che in fin dei conti la definizione di una ontologia non e' null'altro che un confronto dialettico tra due o piu' persone che vogliono imporre la propria visione soggettiva delle cose senza poter fondare la discussione su aspetti tecnici e misurabili, lunghissimi flames sono gia' stati prodotti nei confronti di innumerevoli dettagli che avrebbero dovuto essere inclusi, esclusi o modificati ed il mio compito sara' quello di moderarli. Se a cio' aggiungiamo l'hype che Nepomuk detiene, avendo galvanizzato una buona fetta della community a seguito dell'implementazione (comunque a tutt'ora in corso d'opera) in KDE, ed il fatto che dovro' confrontarmi con personaggi di un certo spessore e di una certa esperienza (nella pagina sopra linkata appaiono, oltre al mio, i nomi di almeno un paio di maintainer di Tracker ed il co-maintainer di Xesam), la sfida si fa ancora piu' ardita.
Ridendo e scherzando gia' so che passero' il weekend a documentarmi sui tickets gia' in passato aperti sul componente a me assegnato e sulle modifiche che qualcuno ha arbitrariamente apportato senza pero' passare per la validazione da parte della community, preparandomi mentalmente e fisicamente al ciclo di sviluppo che iniziera' nel prossimo periodo a causa della chiusura dell'originario progetto Nepomuk sponsorizzato dall'Unione Europea ed alla migrazione della baracca sotto l'egida della fantomatica OSCAF, ambigua organizzazione il cui compito non e' ancora chiaro e per la quale indirettamente mi son trovato in codesta situazione.
Vabbe', guardiamo il lato positivo: con tutte le mail di insulti internazionali che dovro' mandare, magari il mio inglese scritto migliorera'...

Social Software

Nella 2020 FLOSS Roadmap, il documento (assolutamente non ufficiale, ma comunque fonte di ispirazione) che descrive i punti chiave in cui sviluppare e promuovere il software libero nei prossimi anni affinche' possa viralmente innestarsi sul panorama IT precedendo le controparti proprietarie (ed alla fine conquistare il mondo!!! Mhuahahaha!!!), uno spazietto e' dedicato al "Social Software".
Mettendo le mani avanti in merito al significato che tale buzzword dovrebbe avere, e che nella mia interpretazione differisce dalla definizione fornita da Wikipedia, il termine mi ispira un concetto che val la pena di esplorare ed implementare, o quantomeno di uniformare a partire dalle gia' esistenti sporadiche incarnazioni. Tale concetto e' quello di applicare una dimensione "social" (nell'accezione di "social networking") alla distribuzione del software, integrando servizi collaterali come il rating e l'aggiunta di commenti per ogni pacchetto installabile per mezzo del package manager, si' da arricchire quasi passivamente la documentazione relativa alle applicazioni accessibili dagli utenti.
L'idea e' tutt'altro che nuova, viene gia' marginalmente applicata in Ubuntu (che rappresenta la popolarita' delle applicazioni con delle stelline di merito) ed in Entropy (il package manager di Sabayon, progetto che ho modo di seguire abbastanza da vicino e che non nascondo abbia in buona parte influenzato la mia posizione sui temi qui trattati), ma trattandosi di applicazioni indipendenti, non compatibili e limitate risultano solo parzialmente utili ai fini dello sfruttamento intensivo dell'idea. Per questo motivo ho gia' provveduto a gettare il sasso nello stagno di PackageKit, progetto FreeDesktop che punta all'astrazione del package management sulle piu' disparate distribuzioni ed esporre questa funzionalita' in modo che sia programmaticamente raggiungibile anche da applicativi che non siano il package manager in senso stretto, ed attendo qualche commento in merito.
In un futuro il proposito potrebbe essere esteso anche a forme di contenuti "user generated" piu' significativi che non gli sterili commenti, come ad esempio una maggiore interazione in caso di errore dell'applicazione (e conseguente bug report) e l'avanzamento di idee e proposte per nuove features e migliorie: anche in questo caso esistono gia' parziali implementazioni dai singoli vendor (ad esempio Firefox provvede a presentare il dialog di bug reporting in caso di errore, mentre il team Ubuntu gestisce un suo proprio collettore di suggerimenti online), e provvedere una soluzione unica, riusabile e facilmente gestibile (per evitare gli ovvi doppioni che scaturirebbero da una adozione di massa del sistema, da individuare nel modo piu' automatico possibile) permetterebbe di incrementare notevolmente le possibilita' di produrre software di gran qualita'.
Il sofware libero siamo noi, dunque tanto vale fornire strumenti efficaci per lo svolgimento del proprio compito.

"Lobotam"?

Negli ultimi tempi, per motivi legati in qualche modo al lavoro, mi sono documentato in modo abbastanza approfondito su Xesam, ovvero il protocollo FreeDesktop che intende unificare l'accesso ai dati piu' o meno semantici raccolti dai vari indexers quali Tracker, Beagle e compagnia cantante. E sebbene un anno fa', in occasione del primo approccio col progetto stesso, espressi una critica alla modalita' di utilizzo del formato, dopo aver rovistato il wiki in lungo ed in largo ed aver constatato l'incredibile frammentazione esistente nel mondo open in merito al tema del desktop semantico mi sono cosi' convinto della necessita' di questa opera che non solo mi sono iscritto alla mailing list ed ho preso (modestissima) parte all'atto finale che prelude al rilascio della versione 1.0 della specifica (oramai imminente) ma mi sto anche persuadendo che, almeno per ora, potrei utilizzare tale strumento all'interno di Lobotomy, sostituendo il mio personale storage relazionale Hyppocampus con un indexer canonico acceduto appunto grazie al protocollo standard.
Questo porterebbe all'impossibilita' di implementare alcune delle features avanzate che avevo elaborato, come il versioning dei singoli metadati e l'utilizzo ortogonale di informazioni cronologiche, ma certamente il fatto di non dovermi occupare personalmente di una componente grossa ed impegnativa come l'estrattore, indicizzatore e fornitore dei metadati mi permetterebbe finalmente di ottenere qualcosa di concreto nell'ambito del mio oramai anzianissimo ma poco produttivo progetto. E si puo' anche immaginare che in questo modo Lobotomy, inteso come ambiente operativo, potra' anche piu' facilmente essere adoperato, valutato e testato all'interno di un desktop environment canonico, ed essere utile a qualcuno per gestire i propri dati senza necessariamente dipendere dall'approccio distruttivo e radicale che presupporrebbe l'utilizzo esclusivo della mia esotica interfaccia.
Conto di concentrarmi prossimamente sui task prettamente presentativi del sistema, nella fattispecie su Synapse, e faro' in modo di wrappare l'interfaccia Xesam in modo che sia facilmente sostituibile il giorno in cui disporro' di uno storage relazionale fatto a modo mio.
Lobotomy + Xesam = Lobotam!

xPUD

E' successo di nuovo: non faccio in tempo ad avere una idea, che subito trovo qualcuno che l'ha gia' applicata.

Da poco tempo sono allo studio delle gia' esistenti soluzioni che permettono di costruire interfacce grafiche partendo da una descrizione formalizzata in XML, al fine di cercare di recuperare qualcosa per la prossima implementazione dell'interprete di "Thoughts" da integrare in Synapse, e sono giunto alla conclusione che probabilmente l'eccellenza in questo campo sia stata raggiunta da XUL, tecnologia a mio tempo gia' esplorata che sta alla base di prodotti del calibro di Mozilla Firefox. Ho dato uno sguardo all'immensamente complesso ed arzigogolato codice sorgente dell'interprete al fine di estrapolarne la tecnica adottata per il parsing e la ricostruzione della grafica, e sono anche arrivato al punto da lasciar perdere il vago pensiero dell'integrazione dell'intero XUL all'interno di Lobotomy a causa della sintassi troppo permissiva e della pesante quanto inutile dipendenza da Javascript, ed immediatamente mi trovo davanti agli occhi una intera distribuzione Linux con una interfaccia completamente costruita su tale piattaforma.
Di xPUD ho letto la prima volta tra le news di Distrowatch, qualche giorno fa', ho scaricato la .iso e me ne son dimenticato; oggi me lo ritrovo su OSNews, dunque inevitabile e' stato riportare l'attenzione sul progetto.
Purtroppo non ho potuto ancora provare il prodotto, a causa della scarsita' dei miei mezzi di virtualizzazione per verificare il CD live almeno su macchina virtuale, ma almeno sulla carta questa sottospecie di interfaccia ultraminimale (come riportato da OSNews stesso) estremamente ben si adatta ai netbooks o ad un ipotetico "sistema operativo di emergenza" da avviare all'occorrenza per la fruizione dei contenuti del PC (senza far partire tutto l'ambiente canonico). Non sara' forse l'erede futuro del desktop, ma certamente il concetto di tirar via tutto il superfluo e mettere sotto il cursore quello che realmente serve, implementandolo oltretutto con una tecnologia cosi' propensa alla customizzazione e di rapidita' di stesura e perfezionamento, merita un elogio.
I miei piu' vivi auguri al cinese che sta portando avanti questa impresa, con la speranza di vedere qualcosa del genere sui prossimi netbooks in commercio anziche' gli orribili Linpus e compagnia cantante.

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.

Strappando la Rete

La notizia l'ho letta oggi pomeriggio, e mi ha talmente entusiasmato che la riporto qui: qualcuno ha sviluppato un binding DBus per Javascript. O meglio: una versione taroccata degli engine di Gecko e WebKit in grado di interpretare istruzioni Javascript destinate appunto all'interfaccia verso quello che si sta affermando come lo strumento di IPC standard sul desktop Linux (e non solo).
Il Browser DBus Bridge rappresenta non solo una grande innovazione, ma uno sforzo che oserei definire pionieristico nei confronti della piu' e piu' volte paventata integrazione del Web con il desktop casalingo: con poche righe di codice un sito potrebbe interagire con l'intero sistema operativo locale, non solo per mezzo della pagina visualizzata nel browser ma con tutto il set di altri applicativi utilizzati comunemente dall'utente. Importare ed esportare (o anche combinare) dati da e verso l'Internet non sarebbe piu' questione di usare programmi dedicati e limitati per una specifica area, ma diverrebbe piu' immediato che scaricare un file e salvarlo sul disco.
Con ogni probabilita' questa opera non godra' mai di capillare diffusione (troppo vincolanti le implicazioni sulla sicurezza e sulla privacy, per cui non e' tollerabile che un qualunque sito possa andare a ravanare informazioni che non gli competono, e troppo limitata la diffusione di Linux sul desktop per giustificare una massiccia adozione), ma a parer mio merita comunque una menzione d'onore per la sua semplicita' e la valenza di tecnologia potenzialmente "distruttiva".
Ad ogni modo mi son marcato la pagina al fine di meglio approfondire il tema e tentare (quando avro' tempo...) di lavorarci un pochino sopra, anche e soprattutto all'interno del Progetto Lobotomy.

L'Architettura di EyeOS

Per motivi contorti l'altro giorno mi e' capitato di andare a dare uno sguardo alla documentazione del web desktop EyeOS, scoprendo cio' che non mi sarei aspettato.
Dei web desktops ho gia' fatto menzione diverso tempo addietro su questo blog, e nel frattempo la mia posizione nei confronti di tale tecnologia (per cui e' oramai passato il momentum e di cui nessuno piu' discute) non e' variata, ma sorvolando su "cio' che e'" vorrei soffermarmi su "come e' fatto": la pagina introduttiva all'architettura del cosiddetto sistema operativo web illustra come EyeOS sia strutturato su piu' livelli operativi, che vanno dallo strato di presentazione all'utente (quello che disegna gli elementi nel browser) al core di servizi dedicati alle singole funzionalita', passando per un "kernel" che funge da tramite. Dove ho gia' visto una cosa del genere? Nei miei stessi documenti che tracciano la struttura che vorrei dare a Lobotomy!
A ben guardare codesta soluzione e' pressoche' obbligata nel momento in cui si implementa un web desktop: il codice eseguito nel browser puo' essere solo Javascript o al piu' Flash, dunque con potenzialita' assai ridotte, e in ogni caso lo storage risiede sempre in una locazione ben diversa dal PC locale dell'utente (il server che hosta il servizio) e l'unica possibilita' e' quella di suddividere ogni applicazione nelle diverse componenti di presentazione grafica e di computazione.
EyeOS potrebbe essere un discreto punto di riferimento per i prossimi sviluppi del mio progetto: purtroppo oltre appunto alla disposizione dei suoi internals esso non porta assolutamente nulla di nuovo in termini di usabilita' ed interazione (emula in tutto e per tutto un desktop tradizionale, coi suoi pro e contro), ma chissa' che non se ne possa cavare qualche spunto...

Aurora

Avevo scorto un link a questa cosa tempo addietro, ma poi fattori ambientali mi avevano impedito di approfondire, come al solito me ne ero dimenticato, e ieri contemplando lo stream di del.icio.us ho trovato questo articolo con un nuovo riferimento al video cascato nell'oblio.
L'oggetto della discussione e' Aurora, concepito da Adaptive Path e presentato nel contesto della Concepts Series promossa da Mozilla Labs.
Cos'e'? In parole semplici un browser, all'atto pratico una proposta di modello di interazione ispirata dalla sempre piu' forte spinta del destktop verso il web. Poiche' in un ipotetico futuro la Grande Rete sara' contenitore unico ed universale di informazioni ed applicativi software, l'unico programma con cui l'utente interagira' sara' appunto il browser, modificato e potenziato rispetto a quanto siamo abituati oggi ma pur sempre un browser.
Nella visione di Adaptive Path il programma non solo permette di renderizzare le pagine web (ed e' il minimo...) ma organizza anche la cronologia secondo un ordinamento basato sulle correlazioni semantiche dei contenuti visualizzando poi i dati in gruppi separati navigabili secondo una modalita' spaziale. Non troppo dissimile da quanto vuole fare ItsMe, con la differenza che in Aurora la creazione e la gestione dei gruppi, al pari di pressoche' ogni altro compito di processamento, sembra essere molto piu' automatizzata e a discrezione dell'algoritmo interno.
Nella pagina del concept si trovano almeno quattro video di cui uno solo, il primo, ha una qualche parvenza di realismo, gli altri tre mi sembrano assai pacchiani sebbene in fin dei conti neppure cosi' infondati: i formati universali che descrivano i dati secondo sintassi comprensibili (e dunque elaborabili) dalla macchina si stanno propagando, devices delle dimensioni di una carta di credito non sono ancora possibili ma il progresso delle tecniche di miniaturizzazione lascia pensare che un giorno ci si possa arrivare, ed in merito alla scenetta del terzo filmato non e' poi cosi' impossibile reperire informazioni su un prodotto commerciale facendogli semplicemente una foto considerando che gia' adesso esistono strumenti che associano immagini uguali o simili tra loro (giusto oggi e' entrato in private beta TinEye).
Morale della favola: stiamo tornando al thin client? Stiamo tornando ad usare semplici terminali che vanno a pescare software ed informazioni su macchine remote, cosi' come in voga agli albori della scienza informatica quando un singolo mainframe serviva le richieste di un numero di utenti sparpagliati nel laboratorio con davanti un monitor, una tastiera e null'altro? Forse si (con l'ovvia sostituzione del mainframe con il Cloud Computer), forse no. Ed e' un bene? Forse si, forse no. Di buono in questa prospettiva c'e' la garanzia di accesso ad informazioni sempre aggiornate ed arricchite programmaticamente mischiando i dati dell'utente con il flusso proveniente dal resto della Rete, di cattivo (oltre alle ovvie considerazioni sulla privacy, ma oramai ho smesso di credere che in un mondo interconnesso possa esserci molto spazio per l'intimita'...) c'e' l'eccessiva esposizione e contaminazione di quegli stessi dati, cosi' mutevoli e soggetti a cambiamenti non necessariamente richiesti e graditi. Per non considerare il rischio portato dal fatto di centralizzare il point of failure di qualsiasi attivita' sociale, economica e ricreativa su un'unica struttura (l'Internet) e su un numero limitato di providers per i servizi essenziali.
Piu' passa il tempo e piu' sono convinto della soluzione del "Personal Cloud" (che bel nome, l'ho inventato adesso! Dovrei registrarlo sperando che mi vada meglio che a Dell ;-) ) la cui struttura e' stata menzionata in un precedente post: una rete di macchine personali, alcune da portare con se' ed altre con cui arredare la casa, che interagiscano pienamente tra loro ed in modo contenuto con l'Internet, in modo da usufruire delle potenzialita' della moderna tecnologia senza poggiare necessariamente tutto su pochi nodi cruciali e senza sacrificare troppo alla privacy o al pieno possesso dei propri contenuti.
Sara' sara' l'aurora...

Un Castello tra le Nuvole

Da qualche tempo mi son reso conto di essere talvolta un po' troppo influenzabile dalle tendenze (anzi, chiamiamole pure "mode") tecnologiche, ed ora, dopo aver immaginato una interfaccia web based per Lobotomy quando la parola "ajax" veniva menzionata in ogni articolo di blogs ed aggregatori, il mio inconscio geek sta valutando le potenzialita' di quello che e' chiamato "cloud computing".
Non e' nuova l'idea di integrare all'interno del futuro (futurissimo...) Lobotomy strumenti per la distribuzione del calcolo necessario per l'estrazione automatica dei metadati ed altri task con forti richieste computazionali, ma nuove porte si aprono se si gettano nel calderone anche le possibilita' della distribuzione dello storage.
Espandendo il filesystem e e copiando (e ridondando) i files su piu' macchine, all'interno della propria LAN domestica o appunto nella Cloud, in un colpo solo si ottiene il duplice risultato di condividere i contenuti affinche' siano fruibili su piu' devices (il desktop di casa, il portatile, il MID...) e di mantenerne copie di sicurezza da sfoggiare in caso di catastrofe - evento neppure cosi' sporadico data la sempre maggiormente scarsa qualita' dei componenti hardware - mentre applicando lo stesso concetto direttamente al database responsabile di indicizzare i metadati che descrivono ogni elemento si riuscirebbe ad esportare le proprieta' tipiche di Lobotomy anche laddove non sarebbe altrimenti possibile: sugli apparati mobili, che non sarebbero in grado di contenere fisicamente (e dunque usare) tale immensa mole di informazioni, e sul web, al fine di condividere i dati tra piu' utenti (i propri amici e conoscenti, ma anche tutto il resto del mondo).
Proprio con questo secondo obiettivo ho iniziato a documentarmi un pochino su HBase, Hypertable e prodotti analoghi: certamente e' molto presto per mettersi a progettare un sistema cosi' complesso, ma e' bene comunque valutare a priori questa direzione per poterla successivamente integrare nel modo piu' pulito e rapido possibile a tempo debito.

Touch Me

Periodo assai magro per lo sviluppo di Lobotomy, essendo io estremamente impegnato su un numero infinito di fronti ed impiegando ogni momento libero per portare avanti una applicazione web commerciale che mi e' stata commissionata (sviluppata per mia volonta' con GWT, al fine di acquisire maggiore dimestichezza con tale strumento e riusare l'esperienza accumulata al servizio del freesoftware).
Ma riuscendo finalmente ad intravedere una luce in fondo al tunnel, e pregustando il giorno in cui potro' tornare a dedicarmi integralmente al mio amato progetto, nel substrato cognitivo di background sono tornato a meditare a funzionalita' e perfezionamenti da apportare. Primo tra tutti (oltre chiaramente all'implementazione del nuovo Synapse in forma di interprete per i templates delle applicazioni interne al desktop environment) lo sfruttamento dei dispotivi di puntamento touchscreen.
Sembra proprio che il mondo abbia finalmente scoperto l'esistenza dei touchscreen (devo considerarmi un precursore, avendo investito gia' tre anni addietro nell'acquisto di un tablet?), e le tecnologie desktop molto puntano su tali apparati: si puo' facilmente prevedere l'uscita di una nuova schiera di tablet PC a partire dal prossimo anno, con l'avvento di Windows7 (di cui l'unica cosa che e' stata mostrata sinora e' appunto il supporto al multitouch), e gia' oggi i piu' moderni laptop targati Apple supportano gestures sul touchpad.
Proprio a proposito dell'uso del comune touchpad presente su ogni portatile in commercio (non solo quelli Mac), ho scoperto che gia' molti di essi sono in grado di identificare il tocco di piu' dita contemporaneamente: stando a questo illuminante articolo le proprieta' di tali device non sono particolarmente precise ed avanzate, ma con un poco di fantasia qualcosa si potrebbe comunque cavare: allo stadio attuale tali funzionalita' sono totalmente inutilizzate (ed ai piu' sconosciute), ed il mio personale obiettivo e' quello di provare ad implementare una sorta di piccola libreria standalone per Linux che faciliti la definizione di gestures elementari da riusare poi nel contesto di Lobotomy.
Chissa' che non riesca a rilasciare qualcosa profittando del tradizionalmente prolifico periodo estivo...

Quattro chiacchere su ItsMe

Da taaanto tempo non aggiorno codesto mio blog, ma tra il lavoro regolare e le altre attivita' non solo non trovo tempo di commentare qui le ultime news a tema ma neppure riesco a meditare piu' approfonditamente sul Progetto Lobotomy.
Sta di fatto che qualche giorno addietro son riuscito a fare un salto a Milano presso l'Universita' Bicocca per scambiare quattro chiacchere con il prof. De Michelis, fautore del progetto ItsMe di cui ho gia' fatto cenno in passato; ebbene, devo dire di aver solo adesso compreso in cosa consiste l'attuale sviluppo del progetto, e tra qualche perplessita' ma anche molta curiosita' lo reputo quantomeno interessante.
Sostanzialmente, diversamente da quanto immaginavo, al momento i ragazzi della neonata azienda meneghina stanno implementando una sorta di layer di astrazione del filesystem che si occupa di filtrare i contenuti scritti e letti operando qualche piccola opera di organizzazione degli stessi in funzione dell'attivita' dell'utente, che di volta in volta si trova a lavorare in un workspace dedicato ad un suo particolare task. Operando al livello del filesystem il sistema puo' essere usato con i normali applicativi software cui tutti siamo abituati, anche se "inconsapevoli" della struttura ponderata che ci sta sotto, e, almeno in questa fase dell'implementazione, non sono previste bizzarre interfacce grafiche o modelli di disposizione degli elementi sullo schermo, se non forse una sorta di "desktop esteso" che permetta di navigare i dati appunto secondo la nuova organizzazione non gerarchica.
Mi ha (piacevolmente) stupito il forte peso che si vuole dare alle interazioni "sociali" dell'utente, al pesante utilizzo delle mail come criterio di discriminazione tra i contenuti per la manipolazione: dall'analisi off-line delle comunicazioni fatte tra persone diverse si vuole fare in modo di "intuire" i nuovi task che ci si trova ad affrontare o le interazioni con essi, in modo da suggerire a chi si trova dinnanzi al monitor correzioni e perfezionamenti al modello.
Forse a questo punto sarebbe d'uopo un confronto tra questa opera ed il Progetto Lobotomy, ma credo che un diretto accostamento sia impossibile: i due lavori partono da presupposti molto diversi tra loro e fungono in maniera quasi opposta (ma non totalmente), mentre ItsMe punta ad un "caos ordinato" tagliato a misura dell'utente che lo usa (e che dunque fallisce se l'utente non segue certe regole) il mio progetto verte sull'immediata richiesta e necessita' (e dunque fallisce sul lungo termine non avendo una visione di insieme); ad ogni modo, loro arriveranno certamente prima di me ad avere qualcosa di usabile, dunque il problema non si pone...
Non ho ben capito a quale grado di sviluppo siano gia' giunti gli sviluppatori di ItsMe, ma mi e' stato riferito che entro non troppo tempo (subito dopo l'estate?) potrebbe essere disponibile online un simulatore atto a far toccare con mano la tecnologia e le implicazioni di un manager automatico per le informazioni: per intanto mi frego le mani in vista di metterci le mani sopra, si' da diventar membro della community e collaborare quantomeno in veste di tester, e vedro' di tenermi aggiornato in merito alle prossime news a riguardo.

PlexyDesk

Ieri ho scoperto un nuovo (almeno per me...) progetto, segnalato dal ben noto blog di pollycoke (di cui mi ostino a seguire il feed nonostante la scarsa affinita' che provo con il personaggio che lo mantiene...).
PlexyDesk e' un desktop manager che si presenta con la promessa di permettere all'utente di gestire piu' facilmente le informazioni ad esso accessibili. Sebbene mi sia astenuto dal gridare al miracolo guardando i video pubblicati (che si incentrano in larghissima parte alle proprieta' decorative dell'ambiente... Fuffa, insomma...), molto simpatica ho trovato l'idea di organizzare i task in forma di icone sul desktop: ogni iconcina rappresenta un programma aperto, e cliccandoci sopra si apre e si chiude la finestra relativa. Nonostante i forti limiti di questo approccio (per cui gli elementi sulla scrivania virtuale vanno inevitabilmente a confondersi tra riferimenti a processi in esecuzione, files e launchers), vedo che non sono l'unico a reputare la tradizionale taskbar non piu' sufficiente ad un moderno ambiente operativo, e questa soluzione (se opportunamente implementata) potrebbe essere un discreto compromesso verso un futuro in cui saranno le attivita', e non i singoli files, ad essere oggetto dell'attenzione dell'utente.
Nota a margine: la navigazione del sito del progetto mi ha fatto tornare in mente il proposito di usare anche io video e supporti multimediali assortiti per le dimostrazioni dei componenti di Lobotomy; quasi quasi faccio un filmino dell'output dello unit test concernente gli observers del VFS di Hyppocampus 0.3rc2 e lo metto su YouTube :-P

LoboBuilder?

Breve post per annunciare il fatto che nel weekend ho a lungo ponderato sul traduttore di "viewers" da includere in Synapse, ed anzi per meglio analizzare il problema sto abbozzando un DTD.
Prossimamente vedro' di studiare il funzionamento ed il codice del GtkBuilder, widget recentemente introdotto nello stack GTK+ proprio per costruire interfacce a partire da una descrizione XML: quel che vorrei fare e' molto simile, con la differenza che nel mio caso devo rendere piu' esplicita la distinzione tra gli elementi rappresentativi del result set estratto da Hyppocampus su cui il template viene applicato e gli elementi dediti al layout e alle funzionalita' dell'applicazione descritta, si' da innestare automaticamente nell'interfaccia grafica finale presentata concetti come l'environmental mapping e l'aggiornamento per mezzo degli observers.
Tra ieri ed oggi ho abbandonato il proposito di usare XSLT in quanto produrrebbe risultati troppo statici, e sono orientato all'implementazione di un vero e proprio interprete che tag per tag costruisca l'interfaccia con widgets Kiazma (misto JSON?) e provveda a distribuire coerentemente i signals per l'integrazione con gli altri meccanismi impliciti del sistema.
Altre novita' fresche fresche sul modello che voglio costruire: possibilita' di creare templates di rappresentazione per result sets o per singoli items, forte contenimento dei templates (che non potranno descrivere piu' di una schermata, ma potranno comunque riferirsi ad altri templates. Insomma: l'interfaccia per il "client di posta" non sara' descritta in un unico file, ma ci sara' quello per leggere i messaggi, quello per rispondere ad una mail, quello per scriverne una nuova...), e magari anche possibilita' di includere un template dentro un altro in modo da usarli come "super-widget" riusabili.
Ma prima di andare oltre, farei quasi bene a studiarmi decentemente tutti sti' formati XML...