Chrome OS e l’iPad annunciano l’inizio di un nuovo modo di usare il computer, meno libero del concetto del PC tradizionale ma molto più robusto e adatto ad una platea di utenti ancora più grande. Tuttavia è interes­sante notare che tutto ciò era già chiaro più di dieci anni fa. Basta andarsi a rileggere i vecchi numeri di Byte.

Byte Luglio 1997: The new user inter-face

L’analisi delle NUI¹ metteva in evidenza i limiti della metafora del desktop. L’esplosione di internet e del web in particolare hanno reso neces­sario un nuovo livello di integrazione fra le risorse locali e quelle di rete.

Secondo me, però, una vera integrazione non è mai stata raggiunta, fino ad ora: ci siamo semplicemente abituati a internet. Il file system locale è sempre rimasto ben pre­sente, con uno scarto ben visibile rispetto a quello che stava in rete.

Chrome OS ha risolto il problema in un modo che ricorda quello di Netscape Constellation, ovvero, pre­sentando all’utente solo il browser. Il file system scompare lasciando solo la navigazione fra le pagine.

L’iPad e l’iPhone usano un approccio incentrato sulle applicazioni. Non pos­siamo manipolare direttamente un file, tanto meno una cartella; per qualsiasi azione dobbiamo usare un’applicazione specifica; l’integrazione fra le diverse applicazioni nella stragrande maggioranza parte dei casi è ridotta al copia & incolla.

In questo modo l’uso è radicalmente semplificato. Pensiamo alla questione delle finestre sovrapponibili: in primo o in secondo piano; visibili, parzialmente visibili, invisibili. Ricordo che le prime volte che usavo un Mac, completamente digiuno di computer, mi era piuttosto facile confondermi, anzi, mi perdevo completamente.

Byte Aprile 1998: Crash-proof computing

C’è poi un altro tema: quello della difficoltà di manutenzione di un computer tradizionale. Se forse pos­siamo concepire che un utente acquisisca con il tempo le competenze neces­sarie ai suoi obiettivi, non si vede perché debba anche farsi carico di tutte quelle operazioni di ordinaria manutenzione e configurazione, oggi neces­sarie, ma incomprensibili e completamente scollegate da quello che deve fare.

Consideriamo un’operazione come l’installazione delle applicazioni: ho perso il conto delle volte che ho visto montato un DMG solo per lanciare l’applicazione. L’utente spesso non avverte nemmeno il problema, in fondo funziona tutto, ma è ovvio che nelle intenzioni originarie i dischi immagine dovevano servire come sistema di distribuzione di applicazione che non neces­sitavano di alcuna installazione.

La questione non si limita all’operazione in sé, tutt’altro! Pensiamo a quanto incida su aspetti come la sicurezza o, in misura forse minore, la stabilità. In ambienti controllati molti di questi problemi si risolvono centralizzando la manutenzione ma, a pensarci bene, è la negazione del concetto di Personal Computer.

Per risolvere questo problema Chrome OS non ha bisogno nemmeno di installarle, le applicazioni, visto che tutto gira all’interno del browser. Per l’iPad c’è l’App Store.

Trovo ironico constatare che dopo tanti prototipi di interfacce 3D, futuribili o fantascientifiche siamo qui ad analizzare novità che potrebbe sembrare dei passi indietro. La vera novità, forse, non sta tanto in quello che è cambiato ma a chi si rivolge: dopo la pre­sentazione dell’iPad ho pensato che quello potrebbe essere il primo computer che anche mio nonno può usare.

Volevo segnalare Pagehand, nuovo word proces­sor per Mac OS X, perché ha alcune features degne di nota.

Ma non basta Word?

Il primo punto a favore è l’uso del PDF come formato di file, non legandoci quindi mani e piedi all’ennesimo formato proprietario.

Il secondo è l’occhio di riguardo con cui sono trattate le opzioni tipografiche e l’implementazione degli stili.

Certo, il confronto con altri word proces­sor può essere impietoso, eppure, mi sembra un’applicazione ben fatta, con un buon potenziale.

Siamo ancora all’inizio

È ovvio che potremmo pensare a innumerevoli features da aggiungere, ma una mi sembra veramente mancante, vista la filosofia di base: non è pos­sibile modificare pdf creati da altre applicazioni.

Non so molto del formato pdf per poter dire se sia una limitazione in qualche modo giustificabile, ma non credo. Speriamo che questa svista venga corretta presto.

Se pensate che la beta di Safari 4, con la tanto discussa implementazione dei tab, fosse qualcosa di negativo, guardate questo screenshot della pros­sima versione di Office e poi correte a prendere qualcosa contro il mal di mare.

Siamo nel 2009, Barack Obama è il primo pre­sidente nero degli Stati Uniti d’America e la Microsoft usa ancora l’icona del floppy? Non parliamo del “ribbon”: una discarica di icone.

Com’è pos­sibile arrivare a cose del genere?

Altri commenti.

Una delle applicazione tipiche per oggetti come l’iPhone sono i vari programmini per le note ecc. Io mi trovo bene con Evernote, che, anche su mac mi ha dato una mano per semplificare ulteriormente la gestione dei documenti. Consigliato.

Tuttavia, non è di questo che voglio parlare. O meglio, voglio parlare della nuova interfaccia di Evernote che è stata messa nell’ultima versione e che trovo demenziale.

Questa è la vecchia versione:

Screenshot della vecchia versione

Semplice, no? La clas­sica interfaccia da applicazione iPhone. Bene, questa invece è la nuova:

Screenshot della nuova versione

Ora, io non sono un esperto di GUI, tutt’altro, ma il tab dei suggerimenti mi sembra piantato lì così, al primo posto che capitava; sembra un prototipo. Mah.

Piuttosto avrei tolto l’icona dei “Pending” che serve solo a dirti le note che sta sincronizzando — funzione che può essere svolta benis­simo dall’icona dell’applicazione, tanto più in un ambiente che non consente processi in background — e, se proprio era ritenuto così importante, avrei messo il clas­sico punto di domanda dell’aiuto in linea.

In questo articolo viene pre­sentato un sistema per semplificare, o forse sarebbe meglio dire compattare, un form complesso.

L’idea di fondo è quella di ridurre le diverse sezioni del form in widget espandibili e contraibili a piacere per ridurre al minimo lo spazio occupato.

A mio parere si sorvola troppo sui difetti di una soluzione del genere che sono due: le opzioni disponibili non sono tutte immediatamente visibili e il numero di click neces­sari per selezionare un’opzione. So benis­simo che è proprio lo scopo dell’articolo quello di mostrare un modo per ridurre l’affollamento dello schermo ma non dobbiamo dimenticare che ogni soluzione ha i suoi pro e contro.

Nel complesso rimane comunque un approccio piuttosto efficace, calcolando il fatto che le etichette rias­suntive pre­sentate quando l’elemento è contratto pos­sono fornire informazioni sulla selezione attiva in quel momento.

Che ne pensate? Avete usato soluzioni del genere? In particolare per applicazioni web che pre­vedono inserimenti dati massicci?

Ecco un sito da vedere e studiare e (perché no?) farsi anche una risata. Credo che il pros­simo lo visiterò più di una volta, per gioco e per lavoro ;-)

Volevo segnalare questo bell’articolo sulla legge di Fitt, che descrive il tempo di acquisizione di un bersaglio, ad es. il tempo per cliccare su un link o un pulsante.

Dall’alto della mia grande esperienza in fatto di design delle GUI pensavo fosse una semplice regola empirica, invece è una formula matematica vera e propria. Imbarazzante…

L’aver aggiornato la mia pagina sui form mi ha fatto venire in mente che avevo alcuni articoli arretrati sull’argomento; ad es. questo di Khoi Vinh dove si dimostra che è pos­sibile dire qualcosa di nuovo e/o di gradevole anche nel design dei form.

Questo articolo elenca una serie di consigli basati sui risultati degli study di eye–tracking alcuni dei quali mi suonano piuttosto inaspettati.

1. il testo attira l’attenzione più velocemente della grafica;
2. la formattazione fantasiosa tende ad essere ignorata;
3. le dimensioni del testo influenzano il modo di leggere;
4. le parti inferiori della pagina vengono guardate;
5. gli utenti pas­sano molto tempo a guardare gli elementi dell’interfaccia grafica, come pulsanti e menu (questa me la devono proprio spiegare…).

Bell’articolo di 456 Berea Street sull’uso di label nei form.

In generale mi era già tutto noto, tranne alcuni dettagli:

• è pos­sibile associare più di una label ad ogni elemento di un form;
• IE6 rende cliccabili solo le label associate esplicitamente ad un elemento.