Progettare applicazioni mobile di qualità – Parte 2

Di Adam Churchill

User Interface Engineering

articolo orginale:

Designing Tapworthy Mobile Apps

21 Aprile 2011

Parte 1 dell’intervista

Adam: Josh, che ne pensi dell’utilizzo di tecnologie web, come HTML e JavaScript, come esempi di applicazioni native multi-piattaforma?

Josh: E’ una domanda interessante. Bene, per quelli che non lo sanno, in effetti è possibile realizzare una web app e poi in qualche modo impacchettarla, come se fosse una applicazione nativa.

Ci sono piattaforme come PhoneGap, per esempio, che si comportano fondamentalmente come un browser personalizzato, in cui si prende il codice sorgente di questo browser ed in sostanza, vi si colloca il file della nostra web app al suo interno, si compila il tutto e si confeziona la web app. Poi, si può vendere sull’App Store per iPhone o per Android o per BlackBerry; credo che stiano lavorando anche su Windows Phone 7.

Quindi qui l’idea è che puoi scrivere il codice, JavaScript in questo caso, per far eseguire e animare la tua applicazione, ma come se fosse una web app, per cui le tecnologie che già conosci possono permetterti di realizzare un’applicazione nativa, che può essere distribuita attraverso gli app store. In definitiva, questo risolve alcuni dei problemi delle applicazioni web, in termini di capacità di entrare negli App Store, distribuirle tramite essi e sfruttare quel genere di pagamento facilitato degli Store.

Io le chiamo applicazioni ibride, e lo fa anche un sacco di altra gente. Se siete in qualche modo interessati ad esplorare questa possibilità, un tizio di nome Jonathan Stark, un mio amico, ha scritto un paio di libri chiamati “Building Android Apps with HTML, CSS and JavaScript” ed anche un altro libro analogo: “Building iPhone Apps with HTML, CSS and JavaScript”. Forniscono una panoramica su come farlo.

Ora però, in questa soluzione, ci sono degli svantaggi. Intendiamoci, da un lato, tutto ciò è eccezionale: per fare una app, si possono utilizzare le stesse tecnologie che già conosciamo, per tutte queste piattaforme. Ma ci sono ancora dei problemi, per cui, in alcuni casi, le tecnologie web risultano ancora, francamente, poco fluide su queste piattaforme, rispetto al codice nativo.

E proprio qui è l’essenza del problema. Ma se stai realizzando un tipo di interfaccia leggera, per cui non hai bisogno di una gran quantità di effetti grafici, per esempio, questa potrebbe essere una buona scelta. E’ un modo più rapido, più facile e ti permette di traguardare le varie piattaforme, con meno problemi. Direi che, hanno un po’ meno rapidità di risposta e meno fluida, di quello che sarebbe, se si stesse sviluppando l’interfaccia nel suo proprio codice nativo.

L’altro aspetto che vorrei mettere in luce, è che si stanno distribuendo queste applicazioni web, come se fossero applicazioni native, confezionate con PhoneGap. Ciò significa che è necessario farle apparire come applicazioni native, perché se sto lanciando una app su Android, la mia schermata iniziale dovrebbe assomigliare a quella di una app Android. Se invece sembra una app iPhone o ancora di un altro genere, allora mi ritrovo in una situazione di incertezza, in cui mi chiedo: “che succede? Questa non sembra una app”.

Quando usiamo un browser, abbiamo un certo grado di tolleranza per i diversi tipi di interfacce, perché ci siamo abituati, ma le applicazioni dovrebbero seguire le convenzioni del sistema operativo. Il che significa che su di te, come designer, ricade l’onere di adottare la tecnica di scrivere il codice HTML e CSS per scimmiottare il look di una applicazione nativa, e questo non è sempre facile come sembra.

Quindi le applicazioni ibride sono un modo eccellente, per essere subito operativi, sono di sicuro un ottimo modo per creare prototipi di applicazioni, ma ci sono alcuni svantaggi in termini di progettazione, tali che alla fine, comunque la si metta, una app nativa avrà sempre, almeno, una lunghezza sulle applicazioni web, in termini di user experience, sia su quelle confezionate con PhoneGap che su quelle online.

Adam: C’era una parte nella presentazione che chiaramente aveva fatto riflettere il nostro pubblico, e che aveva a che fare con l’ergonomia del design dei dispositivi hand-held (tenuti in mano). Puoi dirci qualcosa di più su questo?

Josh: Già. Certo. Come ho detto nell’introduzione che ho fatto qui, in realtà stiamo facendo una specie di esercizio di design industriale. Sai, questi dispositivi, tutti questi dispositivi touch-screen, in realtà hanno lo schermo vuoto prima di accenderli, prima di lanciare un’app.

Vuol dire che stanno realmente aspettando che gli si imponga sopra un’interfaccia. E siccome è un dispositivo fisico, qualcosa che è pensato per lavorarci con le mani e le dita, anche l’interfaccia diventa fisica. Quindi devi pensare: dove vanno a cadere naturalmente le dita ed i pollici?

Significa anche seguire i precetti del design industriale e quindi che vengono capovolti letteralmente molti dei nostri preconcetti, su ciò che dovrebbe essere il design per il web, o per il software in generale. Siamo abituati ad avere i comandi principali e la navigazione nella parte alta dello schermo e a destra, che sono le aree visivamente più importanti.

Nel design per il mobile, si scopre che il posto migliore per piazzarli in modo ergonomico, è in basso. Se stai tenendo il telefono nel palmo della mano, come facciamo di solito, significa che praticamente utilizzeremo solo il pollice, per toccare lo schermo e un’area comoda da raggiungere per il pollice, è il lato opposto dello schermo, in basso. Quindi, se lo tieni nella mano destra, allora l’area più comoda per il tocco, è il lato sinistro e l’angolo sinistro dello schermo; perciò questo è un luogo ideale per mettere controlli primari: in fondo allo schermo.

E come avevo detto, ne consegue, che un principio di base del design industriale, è che si devono sempre piazzare i controlli nella parte inferiore ed il display nella parte superiore, per la semplice ragione che non si vuole che le dita vadano a coprire il contenuto.

Tutto questo implica che l’area principale per i controlli e i pulsanti principali, è nella parte inferiore dello schermo, invece che in alto. E questa è a mio avviso, una nozione cruciale, uno dei grandi principi, che, anche se dettati dal buon senso, non necessariamente vengono in mente alle persone, mentre sviluppano i loro progetti e che solitamente lavorano in un ambiente desktop.

Adam: Data la popolarità dei dispositivi Android, Don vuole sapere: in che modo la varietà delle dimensioni dello schermo, offerta dal mercato, impatta sulla funzionalità ottimale dell’applicazione?

Josh: in fondo questi telefoni sono partiti con una dimensione di schermo di circa tre pollici e mezzo, giusto? E poi sono cresciuti a quattro pollici e qualcuno anche a cinque pollici; poi ora abbiamo questi telefoni jumbo, che sono certamente molto attraenti per via del loro grande display.

Uno dei problemi che generano questi telefoni (ed io questo problema ce l’ho, nonostante che abbia le mani grandi), è che per raggiungere ogni parte dello schermo con una rotazione completa del pollice, si deve spostare il telefono sul palmo della mano. Quindi, se lo sto tenendo con una mano, in realtà non posso spazzolare l’intero schermo con una rotazione del pollice. Questa scomodità dei telefoni di grandi dimensioni, rende la progettazione delle interfacce piuttosto impegnativa.

Anche qui la regola di base per dispositivi palmari è che si devono collocare i controlli sul basso. E infatti, parlando di Android (e questo è interessante), ci sono dei pulsanti hardware in basso, che è il luogo giusto per mettere i controlli, come dicevo prima, in un design industriale. Ma questi pulsanti fisici nella parte inferiore, complica un po’ le cose, quando si progetta per Android, perché non si devono impilare troppi controlli virtuali, cioè comandi visualizzati sullo schermo touchscreen, sopra questi pulsanti hardware.

Quindi su questo punto c’è una piccola sfida di progettazione da affrontare, a causa del design fisico di Android: provate a mantenere i comandi in fondo, facendo attenzione a non affollare troppo quell’area, in modo da evitare errori di tocco, come quando si cerca di eseguire un comando hardware, e invece si tocca un comando touchscreen. Quindi su questa caratteristica di Android direi il design presenta delle scelte delicate.

Per come la vedo io, e questo è solo un parere personale, ho il sospetto che questo tipo di telefono formato jumbo non sarà probabilmente l’ultimo. Penso che così com’è adesso, non assicuri la massima ergonomia; è una dimensione scomoda per un telefono ed ho il sospetto che la dimensione dei telefoni si restringerà verso un formato più piccolo della versione precedente, un po’ come la dimensione dell’iPhone. Mentre avremo una categoria di tablet di medie dimensioni, sui sette pollici, e poi un tablet di dimensioni jumbo, come le dimensioni dell’iPad o dello Zoom.

La ragione per cui dico questo, è che se si guarda alla nostra storia con la carta, con taccuini o con i libri, tutti questi oggetti, per valide ragioni, nel corso dei secoli, si sono consolidati in tre formati: uno tascabile, di dimensione molto piccola, uno di tipo libro in edizione economica, ed infine un formato più grande, con la copertina rigida. Mantenendo la metafora del libro, c’è un formato ancora più grande, delle dimensioni di un tavolino di un bar, per un tablet di grandi dimensioni. Penso che vedremo consolidarsi le dimensioni dei tablet e degli smartphone nello stesso modo.

Adam: Ecco Josh, su questo tema, quando si parlava dell’ergonomia del design su un palmare, nella sezione Q&A (domande e risposte) del nostro spazio Adobe, ci chiedevano: “E i mancini? Cosa devo fare per i mancini?” C’è qualcosa di prezioso che potete dire ai progettisti su cui porre l’attenzione? Oppure devono solo limitarsi a mantenere i controlli in basso?

Josh: Giusto. Ci sono un paio di cose da dire, la prima è che siamo abbastanza flessibili con questi dispositivi, riguardo a quale mano usiamo. In altre parole, i destrorsi, a volte usano la mano sinistra ed i mancini talvolta usano la mano destra, o addirittura la preferiscono.

Quindi, per il telefono, non ci sono regole rigide, come ci sono invece, diciamo, nello scrivere, dove i destrorsi usano sempre la mano destra. Infatti, quando scriviamo, se si è destri, si deve tenere il telefono cellulare nella mano sinistra per poterlo usare.

C’è solo da dire che tutti noi tendiamo ad utilizzare i telefoni con entrambe le mani, quindi non voglio enfatizzare troppo la necessità di ottimizzare l’interfaccia per la destra. Detto questo, il più delle volte, la maggior parte delle persone tende a utilizzare il telefono nella mano destra, per cui una leggera ottimizzazione per quelle persone, aiuta.

Ma cosa significa questo per i mancini? Se stai ottimizzando per i destrorsi, per definizione significa che lasci che i mancini cadano in disgrazia. Alcune applicazioni, poche, vengono utilizzate proprio per questo scopo; per esempio, Twitteriffic su iPhone, aveva una opzione per invertire i tasti per i mancini, in modo che la navigazione, le barre degli strumenti e tutto il resto, venisse voltato dall’altra parte.

E’ una cosa che si potrebbe prendere in considerazione nella applicazioni molto ‘tap-intensive’. C’è un applicazione chiamata “PCalc”, per esempio, che è una calcolatrice scientifica, con un sacco di pulsanti e nella sua configurazione orizzontale, ha una modalità per i destrorsi ed una per i mancini. Quindi, se stai usando entrambi i pollici puoi effettivamente mettere la tastiera sul lato che preferisci.

In conclusione, queste sono sfumature molto sottili. Credo che pensare a cose, come: “è più comodo per la mano destra, o per la mano sinistra?” e ottimizzare per l’uso con quella sola mano, o con l’altra, sono cose di cui gli utenti non necessariamente si accorgono, ma sono il genere di finezze che fanno la differenza tra una applicazione buona ed una davvero sublime.

Il modo migliore per procedere, comunque, è cercare di creare progetti che siano di tipo neutro rispetto alla mano, cioè, tasti collocati su tutta la larghezza dello schermo e questo lo potete osservare con tutti i pulsanti importanti, in tutte le piattaforme.

Così, giusto per prendere l’iPhone come esempio, gli action sheet scorrono in su, dal basso dello schermo, e forniscono una serie di opzioni. Per esempio: stai cancellando un post e ti chiederà di confermarlo, facendo scorrere verso l’alto questo piccolo sheet dalla parte inferiore dello schermo. E quei pulsanti occupano tutta la larghezza dello schermo, quindi non c’è il problema di destra o sinistra.

Pertanto, in generale, cerca di essere neutrale riguardo a quale mano userà la app. Ma se proprio dovete scegliere una parte o l’altra, sì sa, è generalmente meglio ottimizzare per l’uso con la mano destra.

Adam: In questa magnifica trattazione per rendere i dispositivi mobili ‘degni di un tap’, che stiamo offrendo, non stiamo parlando solo di telefoni, vero? C’è un sacco di gente che è passata alla fase successiva e stavano pensando all’iPad ed il design per i tablet in generale.
Dan vuole sapere: in che modo progettare per un dispositivo piccolo come un iPhone, è diverso da progettare per la sua controparte più grande, l’iPad?

Josh: Sì, è una domanda eccellente ed è facile assumere che le regole siano le stesse, soprattutto quando si parla di passare da iPhone a iPad. Hanno lo stesso sistema operativo, giusto? E come sapete, una moltitudine di persone quando l’iPhone è stato annunciato, ha detto: “Bene, bell’affare l’iPad. A chi può interessare? In fondo è un grande iPhone, niente di che.

Beh, come mi piace dire, l’iPad sta all’iPhone, come una piscina sta ad una vasca da bagno. Hanno le stesse caratteristiche, ma la loro forma e il loro contesto incoraggiano utilizzi completamente diversi. Si vede che sono anche diversi le motivazioni che portano le persone a sceglierli.

Così, per esempio, un iPad, è praticamente necessario usarlo con due mani; cercare di utilizzarlo con una mano, è una cosa diversa. Significa, che quando hai portato qualcuno ad usare tutte e due le mani (e lo si vede anche quando la gente usa uno smartphone in modalità orizzontale), hai tutta la sua attenzione, perché hai impegnato entrambe le sue mani.

Questo cattura maggiormente l’attenzione delle gente, sull’interfaccia, quindi sei già in uno stato di maggiore attenzione. Inoltre, i tablet sono difficili da usare quando si sta in piedi. In qualche modo favoriscono una postura seduta.

Tutto questo porta ad un atteggiamento mentale più tranquillo e contemplativo nell’uso dei tablet, con sessioni più lunghe e con più attenzione. Ciò significa anche che i vostri progetti dovrebbero riflettere, in generale, questo stato d’animo più calmo, più gradevole. A meno che non si stia sviluppando un gioco, per esempio, dove, si sa, più adrenalina c’è, meglio è.

Quindi in termini di estetica, non si deve pensare di affollare e stipare più contenuto possibile in quello schermo, che invece, è quello che si vede fare ad un sacco di gente. E’ un impulso irresistibile: “oh mio Dio, io vengo da iPhone e ora ho tutto questo spazio. Lo userò tutto.”

Oppure, chi viene dal desktop pensa: “beh, è abbastanza simile. Credo che possiamo stipare la nostra interfaccia desktop nello schermo del tablet”. Sai, in realtà è meglio pensare solo ad una interfaccia più piacevole. Aggiungo che lo spazio bianco, rende questi design più tranquilli. Spostare qualche informazione alla distanza di qualche tocco, va bene.

Dovrei menzionare, proprio perché penso che ne valga la pena, che il web ci ha resi un po’ schizzinosi sui clic in più, o in questo caso i ‘tocchi’ in più. E questo, a causa del tempo di latenza della rete, giusto? Sul web ogni clic comporta un’attesa e gli utenti si irritano; bisogna ridurre questo disagio. Con i ‘tap’, il contenuto in genere è già più o meno lì, non c’è il problema della latenza.

Quindi, se hai a che fare con quel tipo di situazione dove il contenuto della cache è disponibile subito e non induce alcun ritardo, credo che dove fare pochi ‘tocchi’ in più vada bene; perché è meglio avere una schermata in cui ci sia chiarezza, in cui sono stati messi meno contenuti, ma più mirati e mettere i contenuti aggiuntivi a distanza di un tocco. Nelle interfacce mobili, sia che si tratti di tablet o telefoni, la chiarezza la spunta sempre sulla densità.

Credo che la quantità dei tocchi, per questo motivo, sia molto meno importante della qualità del tocco; quanto è agevole utilizzare la schermata di fronte a voi? Quindi, fintanto che ogni tocco offre quella qualità, che porta al completamento di un’attività o fornisce informazioni, o anche se accade qualcosa di divertente e delizioso, allora va bene avere dei ‘tocchi’ supplementari.

Beh, ho fatto un po’ guazzabuglio parlando dell’estetica del design per l’iPad, comunque anche l’ergonomia è diversa. L’iPad non si afferra dal fondo, in modo che, come si fa con uno smartphone, il pollice sia di solito posizionato nell’angolo in basso, alla base del telefono.

L’iPad, di solito lo si afferra sulla parte alta e di generalmente con due mani, in modo che i pollici siano posizionati verso gli angoli in alto. E così gli angoli in alto a sinistra e destra, sia in posizione verticale che orizzontale, sono le aree su cui focalizzarsi, piuttosto che sulla parte inferiore dello schermo.

Quindi per un tablet, c’è una sorta di ritorno, in sostanza, al nostro familiare posizionamento desktop, perché la dimensione dello schermo è più grande rispetto agli smartphone. Lo schermo è grande abbastanza, da rendere possibile non vedere cose che stanno nella parte inferiore.

Anche se lo si tiene sulla pancia, per me, il tablet affonda nella mia pancia, un po’ più di quanto vorrei e questo rende effettivamente difficile toccare i pulsanti nella parte inferiore dello schermo. Se sto nella mia poltrona reclinabile, con il sacchetto di cornetti di formaggio, non mi trovo in una posizione molto ergonomica.

Quindi, gli angoli in alto a sinistra e destra sono sempre luoghi ideali per i controlli. Evitare la metà superiore, perché, come dicevamo prima, questo significa che l’intera mano, o anche tutto il braccio, va a coprire il contenuto. Se si raggruppano i controlli verso gli angoli in alto a sinistra e a destra, sia lungo la parte superiore che sui lati, allora potete mantenerli fuori dai piedi, ma anche ergonomicamente a portata di mano.

Adam: Dispositivi mobili, persone in movimento che fanno un sacco di cose, cercando di farle rapidamente. Chauncey vuole sapere che impatto hanno le prestazioni del caricamento delle schermate sulla una user experience di una app?

Josh: Già. Le prestazioni sono super importanti per qualsiasi applicazione, che si tratti di mobile o no. Voglio dire, Google ha fatto studi, dove anche pochi microsecondi di ritardo mostrano una marcata diminuzione dell’utilizzo. La gente se ne va, anche se rilevano pochi microsecondi di cambiamento. Nel caso della ricerca, ad esempio, si cercherà di meno.

Quindi c’è comunque questo problema che, se la risposta non è brillante, anche nei casi in cui ti domandi come hanno potuto rendersene conto in una manciata di microsecondi, nonostante tutto, in qualche modo se ne accorgono e se ne vanno. Quindi le prestazioni, sono super importanti in tutti i contesti, ma soprattutto, come dici tu, nel mobile.

Ed è un aspetto davvero importante. Fondamentalmente, penso alle applicazioni mobili, come ad un ristorante che consegna a domicilio. Se non è veloce, infrange una promessa. Quindi le prestazioni devono essere eccellenti.

Nonostante tutto, purtroppo, lo vediamo succedere in alcune applicazioni native che in effetti si percepiscono come più lente. In realtà potrebbero non essere più lente, ma si avvertono come tali, a causa del modo in cui gestiscono i dati, rispetto alle loro controparti web. Se si utilizza la app per iPad del New York Times, per esempio, ci vorrà qualche secondo per caricare e mostrare tutto il contenuto della home page. Quindi, è chiaro che raccoglie tutto il contenuto in una volta.

C’è questa sensazione di lentezza che non si ha, quando si va sul sito web. Eppure, visitando ogni pagina, si sperimenta più di un solo ritardo, giusto? Ma in qualche modo, sono distribuiti nel corso dell’esperienza, piuttosto che concentrati in una lunga attesa, che si manifesta quando lanci l’applicazione la prima volta. E questo lo vedete nel The Daily, che è la app per iPad della grande News Corporation. Ci vogliono qualcosa come 30 secondi per caricare quel giornale.

Se stai sviluppando una applicazione nativa, uno dei tuoi grandi vantaggi è la velocità e le prestazioni. E se hai costruito la tua applicazione in modo che si avverta una maggiore lentezza rispetto la tua applicazione web, beh, allora, probabilmente qualcosa è eccezionalmente ben fatto nella tua applicazione web, il che è meraviglioso, ma significa anche che qualcosa non va nella tua applicazione nativa. Deve dare la sensazione di essere veloce, deve dare la sensazione di essere brillante.

Adam: Bene Josh, eccellente. Grazie per essere tornato con noi a rispondere a quelle domande che erano rimaste fuori.

Josh: E’ stato un grande piacere.

Adam: Per il nostro pubblico: approfondirete la visione di Josh, e potrete vedere e ascoltare in modo più esteso le sue analisi, sul nostro Web App Masters Tour, verso la fine della primavera, sia a Seattle che a Minneapolis.

Ancora una volta, al nostro pubblico, grazie per il vostro sostegno al programma Virtual Seminar e per l’ascolto di oggi.

Podcast integrale dell’intervista

Adam Churchill Adam Churchill

Josh ClarkJosh Clark

Questo articolo è stato ripubblicato con l’autorizzazione di User Interface Engineering. Per altri alrticoli e informazioni, visitate il sito http://www.uie.com/

Traduzione di

Stampa articolo Scarica il file in formato PDF

 Iscriviti alla newsletter


Argomenti correlati: mobile · usabilità web.

Lascia un commento