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.

I Piccoli Aggiornamenti

Tra le attivita' che maggiormente reputo degne di essere completamente delegate alla macchina in modo da non tediare l'utente c'e' sicuramente l'aggiornamento del software installato. Ad oggi qualsiasi distribuzione Linux monta di default un package manager, che si occupa automaticamente di verificare la disponibilita' di nuovi pacchetti e risolve le dipendenze in fase di installazione ed aggiornamento, ma comunque la sua esecuzione dipende dalla volonta' e dall'attenzione dell'utente che o se ne dimentica o viene periodicamente disturbato da notifiche sul suo desktop.

Ad oggi, comunque, l'esecuzione schedulata e silenziosa di un "apt-get update; apt-get upgrade", magari per mezzo di cron, e' assai poco consigliata: troppo spesso accade che tale operazione venga lanciata nel bel mezzo di un update massivo sul repository di pacchetti di riferimento, e se non ci si prende la briga di leggere cosa viene richiesto di fare basta veramente troppo poco per trovarsi, in virtu' di qualche estroso conflitto nelle dipendenze, il desktop environment o qualche driver importante disinstallato.

Ma d'altro canto c'e' un intero universo di componenti software che non sono affatto gestiti (o comunque sono solo marginalmente trattati) dai package manager, e che produrrebbero un danno limitato anche qualora per disgrazia fossero gestiti male: i plugins.

Ogni applicazione evoluta oggi esistente mette a disposizione una ricca API con cui qualsiasi developer puo' aggiungere funzionalita', a volte modeste e a volte molto pesanti, e la tendenza a distribuire in questo modo lo sviluppo tra il maintainer del core principale e gli occasionali partecipanti e' in evidente crescita (forse anche dopo aver constatato l'enorme successo avuto dal concetto di "estensione" applicato al popolarissimo Firefox).

L'unico problema e' che raramente si trovano repository unici di estensioni e plugins destinati ad una specifica applicazione, ed occorre andarsele a cercare appositamente (assumendo ovviamente che se ne conosca l'esistenza). Il mio esempio preferito e' Inkscape: sul sito esiste una raffazzonata pagina dedicata ad indicizzare alcune estensioni esistenti, ma al fondo di essa si trovano tracce di un eventuale progetto strutturato e mirato a tale scopo che risalgono a maggio 2010.

D'improvviso, leggo oggi sul blog di Aaron Seigo il proposito di fornire una sorta di protocollo di auto-discovery per i DataEngines di Plasma (che, detto terra terra, sono delle estensioni di KDE). In sostanza il personaggio descrive uno scenario che io stesso medito da tempo: utilizzare qualcosa come il formato Open Collaboration Services (da me stesso implementato per Gnome) per comunicare ai clients degli utenti variazioni sullo stato dei componenti installati, ed ai fatti provvedere ad una sorta di package management isolato e dedicato ad una nicchia precisa. In un colpo solo si bypasserebbe il management ufficiale delle distribuzioni (che tendono ad essere in ritardo rispetto alle releases dei pacchetti veri e propri), si avrebbe un sistema di aggiornamento unico per tutte le piattaforme, e si estenderebbero le potenzialita' dell'amministrazione di sistema semi-programmatica anche ai frammenti di software sinora bistrattati ed esclusi dalle cure dei packagers.

Per quanto le mire di Seigo siano di molto basso profilo (appunto, limita la sua stessa idea all'aggiornamento dei DataEngines quando potrebbe essere applicato ad ogni genere di estensione), auspico che qualcuno lo stia a sentire e provveda a studiare una soluzione al problema, da poi riutilizzare in altri contesti.

Uno dei piu' grandi vantaggi di Linux rispetto alle altre piattaforme operative e' proprio l'elevato grado di maneggiabilita' dei pacchetti software installabili; tanto vale spremere il massimo da tale concetto, usarlo per dare risalto a sempre piu' opere e farne uno dei canali di penetrazione piu' aggressivi per il software libero.