Porting applicazioni Android / iOS: il fattore user experience

Android puzzle

Qualche anno fa Steve Jobs aveva promesso che iPhone avrebbe cambiato il modo di vivere il telefono cellulare e così è stato: la semplicità di utilizzo e il design hanno fatto da traino. Con lo slogan “c’è un App per tutto” si sdoganava definitivamente la percezione del telefono come solo strumento per telefonare, ma diventava un potenziale canale di comunicazione e intrattenimento. Il fatto poi che chiunque potesse sviluppare una applicazione per il suo telefono (e farci soldi vendendola) ha cambiato le regole del gioco: con un po’ di tempo e una buona idea sono nati freelancer sparsi in tutto il mondo.

Google & Co. non sono stati certo a guardare e hanno cominciato una inesorabile rincorsa che al giorno d’oggi sta dando i suoi frutti. Produttori come Motorola, Samsung, Acer, HTC, Asus hanno visto una nuova primavera (soprattutto Motorola) ed hanno trovato in Android una piattaforma estremamente potente per dare vita ai propri modelli di cellulare (se ancora così li possiamo chiamare), creando un vasto mercato che può ricoprire tutte le categorie di utenti (e di portafogli) cavalcando l’onda della diversificazione. Agli utenti Android infatti piace diversificarsi, piace poter personalizzare fino al midollo il proprio smartphone senza preoccuparsi di tutti quei vincoli e quelle restrizioni che Apple ha invece inserito in iPhone (perché ci vuole bene?).

Questa inesorabile crescita ha avviato un inarrestabile processo di porting delle applicazioni: se fino a poco tempo fa avere la propria applicazione sull’AppStore era motivo di vanto, adesso non basta più e bisogna avere la versione per Android pubblicata almeno sul Market principale (se siamo vispi conviene pubblicarla anche su altri market “non ufficiali”, come quello di Amazon).

Le attese dell’utente

Portare una applicazione su un’altra piattaforma richiede più sforzo di quello che si crede. Uno sviluppatore sicuramente riterrà come preoccupazione principale il problema della traduzione dell’applicazione in un altro linguaggio, ma questo non è l’unico. Un problema più insidioso è quello della user experience: siamo davvero certi che un utente iOS si aspetti le stesse “risposte” del sistema rispetto ad utente Android? Siamo sicuri cioè che le due piattaforme si usino nello stesso modo? Basta pensare al numero di tasti presenti su iPhone rispetto ai modelli che usano Android per avere già qualche dubbio sulla risposta.

Le interfacce utente di iPhone e Android sono molto simili, ma esistono delle differenze peculiari che non dobbiamo trascurare se vogliamo fare il porting di una applicazione. Ci sono infatti delle gesture, dei comportamenti a cui un utente è abituato che in un sistema fanno una cosa, mentre nell’altro un’altra (o spesso niente!!). Quando stiamo progettando di migrare la nostra applicazione ad una nuova piattaforma, dobbiamo tenere estremamente conto di come questa viene solitamente usata per non introdurre interazioni inattese dall’utente.

Android e iOS: così vicini, così lontani

A prima vista Android e iOS sembrano sistemi molto simili nell’interazione utente. Dopo un po’ di utilizzo ci accorgiamo invece che non è così. Riassumiamo schematicamente le differenze più lampanti. Secondo le linee guida delle piattaforme prese in considerazione, a certi eventi corrispondono certe azioni:

Android iOS
shake nop undo/redo
swipe su liste nop appare il bottone “delete”
long press su liste appare il menù “quick action” nop
pressione su campo di input appare un menù con le funzioni copia/incolla lente di ingrandimento sul testo
scrollare un’area oltre i suoi confini vengono evidenziati i bordi effetto “bounce”

Evitiamo quindi il porting uno a uno: se per esempio stiamo riscrivendo la nostra applicazione iPhone per Android che usava l’evento shake per annullare una certa azione, l’utente Android difficilmente se ne accorgerà perché non è abituato a pensare a quel particolare evento.

Migrare da iOS ad Android

Viste le differenze sostanziali, proviamo a dare qualche suggerimento su quali accortezze tener di conto quando siamo alle prese con un porting.

Posizionamento della barra dei tab

Tutte le applicazioni iOS multipagina sono organizzate in tab: la barra dei tab è posta solitamente in basso allo schermo. Per quanto riguarda il mondo Android, l’organizzazione dei contenuti è sempre suddivisa in tab ma Google consiglia di posizionare la barra dei tab in alto (a differenza di iOS). Il motivo? Semplice! Guardate la figura in basso:


Dove posizionare la barra dei tab

Ogni telefono Android ha almeno 3 o 4 bottoni in basso allo schermo: posizionarvi vicino anche la barra di navigazione può creare problemi a chi è affetto dalla sindrome delle fat fingers (o dita a salsicciotti se preferite).

Il pulsante “indietro”

iOS ha praticamente un bottone unico per interagire con la navitazione (ovvero il tasto “Home” per tornare alla schermata principale). Tutti i telefono Android, oltre a questo, hanno almeno anche il tasto “Back”, per cui non è necessario replicare il bottone sulla barra delle informazioni come avviene nel mondo iPhone.

Le icone

La piattaforma iOS dispone di una serie di icone di default che rendono l’esperienza d’uso utente più familiare: se usate correttamente, l’utente saprà sempre che ad una certa icona corrispone una certa azione. Anche Android ha il suo set di icone predefinito: evitiamo quindi di usare le icone di iOS su Android sono perché le riteniamo più “fighe”! L’utente del Google-fonino potrebbe non capirne il significato.

Action Bar

Le action bar sono sempre più usate nelle applicazioni di Android. Se ha senso nella nostra applicazione, è consigliabile implementarla sia per motivi di usabilità che di brand: così a colpo d’occhio si riconosce subito se è una applicazione Android.


Uso della action bar

Conclusioni

Già in un altro post avevamo cercato di sensibilizzarvi al problema della user-experience, indipendentemente dalla piattaforma per cui si sviluppa. Vista la crescita di Android, la tendenza attuale è quella di effettuare il porting delle applicazioni verso questo ambiente. Ripensare le applicazioni con un “look & feel” nativo Android può garantirci più successo rispetto ad un “”copia/incolla selvaggio”! Ringraziamo Android UI Patterns per tutte le dritte!

By Andrea Como

Sono un software engineer focalizzato nella progettazione e sviluppo di applicazioni web in Java. Presso OmniaGroup ricopro il ruolo di Tech Leader sulle tecnologie legate alla piattaforma Java EE 5. In particolare: WebSphere 7.0, EJB3, JPA 1 (EclipseLink), JSF 1.2 (Mojarra) e RichFaces. In passato ho lavorato con la piattaforma alternativa alla enterprise per lo sviluppo web: Java SE 6, Tomcat 6, Hibernate 3 e Spring 2.5. Ultimamente mi sono appassionato al mondo mobile e in particolare ad Android per i motivi che potete immaginare seguendo questo blog! Nei ritagli di tempo invece sviluppo siti web in PHP e ASP e condivido le mie esperienze lavorative sul blog CoseNonJaviste. Per maggiori informazioni consulta il mio curriculum pubblico.

3 comments

  1. le stesse app sviluppate per ios si possono sviluppare per android e renderle disponibili sui relativi market o sono previste esclusive ?

    grazie

  2. Dipende cosa intendi per “esclusive”. Se non sei un freelancer, l’esclusiva credo te la possa imporre solo il committente dell’app. Ricorda comunque che, a differenza dell’Android Market, sull’AppStore la tua applicazione deve essere approvata da Apple. Se pianifichi un lancio contemporaneo sulle piattaforme, per iPhone pensaci un mese prima… 😉

Comments are closed.