Quando progetto un’interfaccia per un’applicazione mobile, a che risoluzione devo lavorare? Che formato hanno gli schermi dei telefonini? La profondità in bit? Che differenze ci sono tra lo schermo di un telefono e uno schermo normale? Quante informazioni metto in una pagina? E su cosa si clicca… anzi, tocca esattamente?

Quando progetto un’interfaccia per il web, le risposte a queste domande tecniche di base sono scontate: la mia prima decisione riguarda il tipo di layout (fisso o fluido), poi studio la pagina conoscendo le risoluzioni più usate (1024 x 768 e 1280 x 1024) e dando per scontata la risoluzione video (72 dpi). Ormai uso abitualmente le griglie per avere un migliore controllo degli spazi e del ritmo. E faccio uso di zone di respiro, spazi vuoti che guidano l’utente nella lettura. Almeno, questa è lo sguardo che cerco di avere.

Su telefonino, la storia cambia.

Inquadrare questo nuovo contesto è stata la fase più impegnativa del lavoro. La trovo interessante anche ora, a distanza di qualche mese, perché rileggendo le domande che facevo ad Alfredo, riflettendo sulle sue risposte e guardando come cambiava il design dell’interfaccia si vede chiaramente che c’è stato un passaggio nella mia testolina: da interfaccia per il web a interfaccia per applicazione mobile. E sì, perché il nostro Dolcevita è appunto un’applicazione e non un sito. La differenza sembra sottile, ma in realtà non lo è. Evito di riscrivere qualcosa che ha già detto bene Maurizio Boscarol nel lontano 2001. Altre considerazioni sono ben spiegate in questa presentazione di Luca Mascaro, in cui il discorso viene contestualizzato nel 2009: il panorama è molto sfumato, comanda il device più che le differenze tra web e applicazione, tanto più ora che siamo sempre più connessi, che parliamo più di web applications che di siti web… da sola, questa riflessione meriterebbe un post a parte.

Dato che fino a quest’estate non avevo ancora uno smartphone, per capire che tipo di interazione ha l’utente con un’applicazione mobile mi sono guardata alcuni video sulle applicazioni Android più diffuse:

• Google Contacts
• Google Calendar
• Google Talk
• Gmail
• YouTube per Android

Ho anche sbirciato le interfacce grafiche più belle per iPhone, leggendo qualche articolo qui e là. Su tutti, segnalo “30 iPhone Apps with Sexy Interfaces”: vedrete che alcune sono meravigliose, ma anche piuttosto complicate da tradurre in codice.

Dal punto di vista grafico e funzionale, Dolcevita restituisce le informazioni in modo classico: schermata di avvio, elenco eventi e scheda di un singolo evento. Ma dato che l’applicazione permette di filtrare un po’ tutti i contenuti secondo vari criteri (per amico, per popolarità, per network, per vicinanza…), ho fatto molta fatica a capire dove avrebbe dovuto toccare l’utente per poter filtrare i contenuti. Su developer.android.com non ci sono molte spiegazioni sull’uso logico del menù globale e dei menù contestuali, perciò ci siamo dati noi le nostre regole, cercando di rendere l’uso dell’applicazione fluido, semplice e cercando di seguire quelli che stanno già diventando standard per le interfacce mobile. Sempre sul sito ufficiale degli sviluppatori per Android, si dà per scontato che il grafico sappia come dev’essere impostato il file :( Dato che così non è, mi sono confrontata con Alfredo:

• A che risoluzione lavoro?
  (Alfredo) La programmazione di interfacce per mobile segue il principio secondo il quale di spazio disponibile ce n’è sempre poco, quindi occorre sfruttarlo tutto al massimo. Inoltre, in circolazione ci sono solamente due dispositivi con Android, il G1 e il G2, e per entrambi la risoluzione dello schermo è 320×480 (HVGA). C’è da considerare anche il landscape, dato che il G1 ha la tastiera hardware e per usarla si passa in modalità landscape. A queste risoluzioni, ovviamente, va tolto lo spazio usato dagli elementi di sistema come la barra principale in alto. Direi quindi di prevedere un layout fluido e dinamico che si basa su un minimo comune denominatore di 320×320 pixel. Tutto si dovrebbe poi adattare dinamicamente ad una maggiore larghezza o altezza. Nelle liste di elementi come gli eventi o i contatti, quello che non entra a schermo in altezza sarà gestito tramite scrollbar, comunque già implementate da questo controllo. I singoli elementi delle liste avranno invece un layout che permetterà la visibilità degli elementi principali con una larghezza di 320 pixel, ma si adatterà bene anche ai 480 pixel. Utilizzando gli elementi del sistema operativo (menù principale, menù contestuale ed altro), la maggior parte di questa gestione fluida verrà realizzata automaticamente, senza codice aggiuntivo.

• In alcuni filmati che ho visto sul canale Android di YouTube, si parla dei 9 Patch: non ho capito cosa sia.
  (Alfredo) Tutto parte da una considerazione fondamentale nella progettazione di interfacce per il mobile: lo spazio è poco, variabile come dimensione, e occorre sfruttarne il massimo possibile ogni volta. Ad esempio, un bottone potrebbe dover riempire dinamicamente una certa area dello schermo, crescendo e riducendo le sue dimensioni a seconda dello spazio a sua disposizione. Con un semplice ridimensionamento dell’immagine del bottone si otterrebbero bordi sgranati o troppo compressi a seconda della dimensione, e ridisegnarlo ogni volta in maniera vettoriale potrebbe non sempre essere il massimo per le performance dell’applicazione, soprattutto se l’elemento è complesso o ce ne sono molti in gioco. Per questo motivo si è pensato di dividere l’immagine che il sistema disegnerà durante il render del controllo in 9 parti: i quattro angoli che non verranno mai ridimensionati, due aree in alto che verranno ridimensionate solo il larghezza, due aree laterali che verranno ridimensionate solo in altezza e un’area centrale che verrà ridimensionata sia in larghezza che in altezza. In questo modo, si riescono ad ottenere controlli che possono crescere senza grossi problemi di visualizzazione, con una sola immagine che li descrive, basta solo che questa immagine sia di tipo 9 patch. Per realizzarla praticamente, si prende l’immagine normale, con un apposito programma la si “seziona” e il risultato di questo lavoro viene salvato come file .9.png

• Oggetti di sistema come menù a tendina, bottoni, checkbox, radio button, loader ecc: usiamo quelli di sistema?
  (Alfredo) Direi che finché non abbiamo bisogno di fare diversamente per particolari motivi, la riusabilità di quanto già esiste è sempre buona cosa. Considera che, pur continuando ad usare un listview standard, posso ridefinire senza problema l’aspetto di un elemento che compare in questa lista (in gergo, view), magari per mostrare tutte le informazioni necessarie ad un evento o un contatto, oppure un colore di sfondo diverso in base alla fonte dal quale proviene l’elemento.

• Il menù globale è sempre agganciato in fondo? Alcune applicazioni lo lasciano aperto altre lo fanno aprire cliccando sull’icona.
  (Alfredo) beh, direi che il menù in fondo è un’abitudine ormai consolidata. Dato il poco spazio a disposizione e la quantità di dati da visualizzare (eventi, contatti ecc), direi che più spazio a schermo abbiamo a disposizione, meglio è. Quindi lo terrei chiuso.

Dopo questo scambio di domande e risposte, ho iniziato a lavorare su wireframe e grafica.