È ovvio che tutto questo parlare di Android, la piattaforma mobile sviluppata da Google, abbia destato il mio interesse, soprattutto in relazione con iPhone. Sin da quando HTC ha presentato G1, il primo smartphone con il sistema Android, per il Web sono iniziati a comparire i classici articoli di confronto, e c’è chi ha parlato di Android come il vero ‘iPhone killer’. Allora mi sono messo a osservare anch’io e a prendere appunti. Oggi voglio condividerne alcuni. È d’obbligo premettere una cosa: le mie considerazioni si basano su informazioni mediate (l’emulatore disponibile sul sito di T‑Mobile, articoli altrui e video messi a disposizione dal gruppo di sviluppatori Android) e da quel che si può evincerne. In altre parole, non ho provato il G1 di HTC di persona, e alcuni dettagli potrebbero avere tutto un altro effetto dal vivo.

Partiamo dall’emulatore. Si può interagire con il G1 partendo da questa pagina. Il link carica inizialmente una presentazione del dispositivo che ruota a 360 gradi. Con il puntatore del mouse si può controllare la rotazione e manipolare il telefono. La parte più interessante è visibile facendo clic su Emulator in alto a destra. Viene caricata un’immagine del telefono disposto orizzontalmente e con la tastiera scoperta e si può interagire con G1 per vedere come funziona e che tipo di risposta si ottiene premendo i vari pulsanti.

Il primo dettaglio degno di nota è l’esistenza di tre pulsanti fisici per la navigazione:

• il tasto Home (con l’icona della casetta), per tornare all’inizio;
• il tasto Ritorno (con l’icona della freccia), per tornare alla schermata precedente;
• il tasto MENU, che richiama un menu contestuale all’interno di un’applicazione.

Qui, a mio avviso, partiamo già male. Questo tipo di approccio alla navigazione è macchinoso e superato. Il tasto MENU presuppone che qualsiasi applicazione necessiti di un menu contestuale, perché se un’applicazione non lo avesse, si rivelerebbe un’inconsistenza nell’interfaccia utente (si preme MENU e non succede nulla). Il fatto che debbano esserci per forza delle opzioni richiamabili dal tasto MENU porta a scelte di design discutibili. Richiamando l’applicazione Music veniamo accolti da una schermata che presenta quattro grossi pulsanti: Artists, Albums, Songs, Playlists. Premendo MENU, appaiono due opzioni aggiuntive: Play shuffle e Search. Perché non aggiungerle semplicemente alla schermata insieme agli altri quattro pulsanti? Sarebbe più elegante e tutto sarebbe visibile a colpo d’occhio. Già, ma poi premendo MENU non accadrebbe nulla.

Questo è un piccolo esempio di come i vincoli a dei tasti fisici possano influire negativamente sulla fluidità di un’interfaccia. In iPhone è possibile indicare chiaramente se un’applicazione offre delle opzioni aggiuntive non immediatamente visibili, perché basta aggiungere un pulsante virtuale nei luoghi deputati (nella parte inferiore dello schermo, oppure negli angoli superiori sinistro o destro). Su Android le applicazioni devono presentare delle opzioni aggiuntive (non importa se cinque, tre, due o una), perché esiste un tasto che le deve richiamare.

L’interfaccia di Android sembra privilegiare un utilizzo orizzontale del dispositivo, che a sua volta implica l’uso della tastiera fisica. Non sempre è comodo. Pare infatti che se vogliamo comporre un numero di telefono non si possa usare il touch-screen in orizzontale: andando in Dialer appare la scritta “Use keyboard to dial” (Utilizzare la tastiera per comporre il numero). I tasti numerici sono in fila orizzontale e non hanno la familiare configurazione a file di tre, 123 — 456 — 789 — *0#, più comoda per immettere numeri telefonici (tendiamo a memorizzare la posizione dei tasti, quindi, come anche avviene sulle tastiere dei computer, chi è abituato a inserire numeri col tastierino numerico fa più fatica a inserirli quando si ritrova il layout 1234567890, con i numeri tutti disposti su un’unica fila).

Non vi è alcuna indicazione visiva che suggerisca la possibilità di fare tap sulla barra di stato e trascinarla verso il basso per rivelare informazioni aggiuntive. iPhone non presenta questo tipo di ambiguità a video.

Cercando informazioni, critiche e commenti su Android, mi sono imbattuto in questo post di Paul Kafasis. Le cose più interessanti sono i link ai video che gli sviluppatori di Android hanno pubblicato su YouTube. Uno dei punti forti di Android rispetto a iPhone, secondo loro, è la possibilità di far girare molteplici applicazioni in background, di passare rapidamente da una all’altra, di ricevere notifiche da un’applicazione in background mentre ne stiamo utilizzando un’altra, e infine il copia-incolla. E lo dimostrano in questo video. Alla fine del video, che non mi ha entusiasmato molto, avevo una serie di perplessità che ha ben espresso un commentatore (che si firma Palmer Deville) al post di Kafasis:

Basandomi su quel che presenta il video, non riesco a vedere quali siano i benefici nel poter far girare più applicazioni su Android.
Anzitutto si vede il tizio che sta sfogliando le foto e riceve notifica di un messaggio istantaneo. Questo è ciò che Apple ha già proposto [su iPhone] con il server per le notifiche (che visualizza un badge — cioè il pallino rosso che indica il numero degli avvisi –, un allarme sonoro e/o degli avvisi in sovraimpressione sullo schermo), così che sia possibile passare direttamente all’applicazione che ha inviato l’avviso oppure ignorarla. L’unica differenza con le attuali demo di Apple è che l’utente dovrà selezionare Ignora o Chiudi se non vuole rispondere subito. Avere l’applicazione di messaggeria istantanea in background in questo caso è inutile.
Poi vediamo il tizio scegliere a quale applicazione passare: tiene premuto il tasto Home finché non appare la lista delle applicazioni attive. Certo, e io su iPhone premo semplicemente il tasto Home e posso scegliere qualunque applicazione voglia per poi tornare quasi istantaneamente al punto in cui mi trovavo prima. Non vi è un gran numero di applicazioni che traggano vantaggi notevoli dall’utilizzo di risorse del processore. La differenza, in termini temporali, fra il passare da un’applicazione state-saved all’altra [si riferisce al modello di iPhone: le applicazioni sono chiuse, non rimangono in background, ma il loro status rimane registrato ogni volta che l’utente le chiude, così da ritrovarle com’erano quando le riapre.] e il passare da un’applicazione in background all’altra, è trascurabile. Se un’applicazione non sta attivamente elaborando delle informazioni, perché tenerla in background?
Poi il tizio afferma di star utilizzando più applicazioni in background: davvero? Vediamo quali:
IM — il fatto che giri in background non è di alcuna utilità, dato che è sempre necessario un qualche avviso e che i servizi di notifica proposti da Apple mirano a estendere questa funzionalità a tutte le applicazioni che ne possano aver bisogno, così da avere aperto sempre un solo processo alla volta, di contro a più applicazioni — ognuna col proprio processo — aperte simultaneamente.
Browser — immagino che in caso vi sia un download in corso o se si stia ascoltando audio in streaming, questo possa essere un beneficio. Ma su iPhone non ho mai sentito l’esigenza di avere un browser sempre attivo in background.
Settings (Impostazioni) — seriamente? Viene davvero considerata un’applicazione attiva in background?
Music — ovviamente. Ma questo avviene anche su iPhone, è una delle funzioni primarie.
Contacts (Contatti) — anche qui, siamo seri. Che ci fanno i contatti in background, a che serve?
Tornare al browser dall’applicazione IM sarebbe stato altrettanto facile su iPhone.
E ora veniamo finalmente alla parte davvero interessante del video, il copia-e-incolla. Considerando il funzionamento di una clipboard (dove vengono registrati gli appunti), che questa stia in background non è un requisito. Il modo in cui viene presentata la procedura lascia a intendere che l’applicazione deve prima essere attivata ed essere già in esecuzione. Ciò non dovrebbe accadere e forse non funziona così. Volessi incollare quell’URL in Mail, dovrei poterlo fare altrettanto facilmente aprendo l’applicazione. 

Sul copia-incolla, quel che ho potuto notare io è che nella demo (anche in quest’altra) il testo da copiare si trova racchiuso in un campo e che non pare esservi un sistema per scegliere con precisione quale porzione di testo copiare. Nel primo video si vede il copia-incolla di un URL, nel secondo video lo sviluppatore effettua una pressione prolungata sopra l’intera frase e la frase viene selezionata interamente. Il sistema della pressione prolungata (tenere il dito premuto alcuni secondi sull’elemento da selezionare) era già comparso sul Newton a metà degli anni Novanta. Sul Newton l’input avviene mediante stilo, e questo permette una maggiore precisione e versatilità nella selezione.

La questione del copia-incolla su iPhone è interessante. Come è stato implementato su Android sembra abbastanza semplice, ma vorrei vedere una demo dove mi si spieghi come effettuare un copia-incolla raffinato (per esempio di una parte di un messaggio email o di un testo di una certa lunghezza o di parte di un URL). Come ebbi a commentare altrove, il problema del copia-incolla in iPhone/iPod touch è indubbiamente complesso, perché implica situazioni + gestualità più complicate rispetto alle normali operazioni che si effettuano abitualmente. Ogni idea che ho visto finora o complica l’interfaccia (rendendola “poco Apple”, per così dire), o prevede gestualità troppo strutturate e non intuitive, o non è applicabile a livello globale sul dispositivo, oppure non è applicabile con coerenza in situazioni diverse.

L’idea del sistema copia-incolla del Newton può fornire un buon punto d’inizio (il gesto di tenere premuto su un certo elemento per iniziare la procedura di manipolazione), ma su iPhone/iPod touch si usano le dita, non uno stilo, e la selezione di un certo segmento di testo non può essere altrettanto precisa. Certo, c’è la lente d’ingrandimento che appare sul testo per posizionare il cursore con precisione, ma è un sistema che va benissimo per fare solo quello. Una volta che si deve tenere premuto il dito sullo schermo per selezionare certe parti di testo senza che la lente scompaia, questa diventa un’operazione stancante per la mano e per la vista. Potrei sbagliarmi, ma forse non si vedrà mai un copia-incolla “a tutto campo” su iPhone. È più probabile una soluzione di compromesso, o comunque un arrivare alla soluzione per gradi, magari introducendo il copia-incolla solo per determinati elementi e usando menu a comparsa (es. si tiene premuto il dito su un link in MobileSafari, e il link può essere copiato e incollato altrove; si tiene premuto il dito su un’immagine in un sito e l’immagine può essere aggiunta alla cartella delle foto, e così via).

Tornando ad Android, esteticamente l’interfaccia mi lascia abbastanza perplesso. La sensazione è che vi sia dietro una mentalità molto Windows (o Linux, a seconda dei punti di vista). La presentazione delle icone, dei menu, degli elementi, è stratificata ed è secondo me un’altra scelta di design superata o da superare. L’idea che vi sia una “scrivania” su cui disporre l’orologio e le icone delle scorciatoie (le funzioni più usate dall’utente), con una ‘linguetta’ da premere per richiamare un menu principale, è un misto di logica da computer desktop e di sistemi operativi mobili di vecchia scuola. Oltretutto l’incongruenza più vistosa dell’HTC G1 è che premendo il tasto MENU non si richiama il menu principale, ma un menu secondario e contestuale all’applicazione in primo piano; l’utente che proviene da altri cellulari e smartphone è abituato a vedere un bel tasto MENU che, appunto, gli mostra il menu. Su Android l’effetto non può che essere straniante: “Per richiamare il primo menu pigio sullo schermo, ma per i sottomenu e le opzioni premo un tasto fisico che si chiama MENU? Boh”.

Mi riservo di tornare sull’argomento con approfondimenti, ma per ora mi sembra prematuro definire Android come lo ‘iPhone killer’. Non basta il multi-tasking e una specie di copia-incolla. E non basta essere open source. Anzi, il fatto che Android sia potenzialmente applicabile all’hardware più vario complica non poco la vita agli sviluppatori specie per mantenere omogeneità e consistenza a livello di interfaccia. Come fa notare John Gruber:

La mancanza del multi-touch è una lacuna hardware del G1 di HTC, non di Android. Ma evidenzia molto bene i problemi che dovranno affrontare gli sviluppatori se vogliono creare delle esperienze interattive di qualità pari a iPhone. Se una propria applicazione richiede il multi-touch, allora questa non funzionerà su certi telefoni Android. Se non si richiede il multi-touch, allora si è costretti a scrivere del codice extra e a progettare gestualità di interfaccia alternative.

Se gli sviluppatori di Android prenderanno la strada più semplice, e si limiteranno a puntare al minimo comun denominatore delle possibilità dei dispositivi, allora la piattaforma non potrà mai competere con quella di iPhone — e col passare del tempo non farà altro che perdere sempre più terreno.