Motion with meaning: animazione semantica nell’interface design

L’animazione sta rapidamente diventando una parte essenziale dell’interface design e non è difficile capirne il motivo. Ci fornisce una dimensione completamente nuova con cui giocare: il tempo, il che crea opportunità per migliorare le interfacce ad ogni livello: può renderle più semplici da capire, più piacevoli da usare e più belle da guardare.

L’articolo prosegue sotto

Per esempio, l’animazione può contribuire a scaricare parte del lavoro (PDF) di elaborazione dei cambiamenti dell’interfaccia dal nostro cervello allo schermo. Può anche essere usata per spiegare il significato degli elementi dell’interfaccia e le relazioni tra questi, e addirittura insegnare agli utenti come fare le cose, il tutto senza rendere più complessa un’interfaccia.

A volte tutti questi fattori convergono: quando riducete una finestra, siete in grado di dire dove va a finire senza un’animazione? Quanto tempo vi occorrerebbe in più per trovare la finestra ridotta nel dock?

I tagli netti rendono difficile capire i cambiamenti di stato, perché cambiare l’intera pagina significa che dovete riesaminare l’intera pagina per capire cosa è cambiato.

Fin qui niente da obiettare, giusto? L’animazione è una buona cosa (perlomeno quando è fatta bene). Ma c’è un aspetto dell’animazione di cui nessuno sembra non parlare mai: alcune animazioni, seppure tecnicamente ben eseguite, ottengono l’effetto di complicare le interfacce invece di renderle più chiare.

Considerate il seguente processo:

Quando facciamo tap sull’icona dell’app Overcast sulla schermata home, l’icona si ingrandisce e si trasforma nell’app. Le altre icone rimangono al loro posto. Sono ancora nelle loro posizioni iniziali, disposte su una griglia attorno all’app aperta.

Cominciamo a fare multitasking. L’app si riduce. Dovremmo tornare alle icone intorno all’app sulla schermata home, ma al contrario vediamo una pila di altre app. Perché l’icona adesso è sopra l’app? Dove sono tutte le altre icone? E perché appare un’altra schermata home vicino alle app?

L’icona dell’app è sia nella schermata home sia vicino alla schermata home. Le due animazioni ci danno informazioni contrastanti su dove si trovino nello spazio la schemata home e le app.

Le due animazioni con effetto zoom hanno in questo caso effetti completamente differenti.

Queste animazioni potrebbero aver senso se progettaste schermate singole, nel vuoto. La situazione diventa confusa solo quando si cerca di farle funzionare tutte insieme come parte di una sola esperienza. Il problema non risiede in nessuna delle transizioni individuali ma nel fatto che le animazioni si contraddicono a vicenda.

Storia#section1

Come siamo arrivati qui? Facciamo un passo indietro e rivediamo brevemente la storia che ci ha condotto fino a questo punto.

Fin dal loro inizio negli anni ’70, le graphical user interfaces sono praticamente state un insieme di schermate statiche (PDF) collegate tra loro senza transizioni. Ogni cambiamento di stato era un taglio netto.

Sebbene ci siano dei notevoli esempi antichi di buona animazione dell’interfaccia risalenti al Macintosh originale (PDF), a causa delle capacità grafiche limitate dei computer di allora, l’animazione efficace era l’eccezione piuttosto che la regola.

Esempio di un’animazione incredibilmente fluida in una vecchia versione di Mac OS.

Al crescere della capacità dei computer, l’animazione ha cominciato ad essere usata più frequentemente per cose come l’ingrandimento delle finestre o l’apertura di nuovi tab. Tuttavia, era ancora in gran parte relegata in servizi per piccole cose, piuttosto che avere un ruolo influente nella struttura generale delle interfacce.

Solo adesso si comincia ad arrivare a un punto in cui le risorse dei computer non sono più un ostacolo per le interfacce. Con i device di oggi, tutto può essere animato e sempre più cose lo sono. Il problema è che il processo di design non si è messo in pari con questo cambiamento tecnologico. Per la maggior parte, le interfacce sono ancora concepite come schermate statiche separate e poi collegate insieme con animazioni relativamente grezze.

Il nostro esempio del multitasking è probabilmente saltato fuori in questo modo: parti diverse dell’esperienza sono state progettate separatamente e poi messe insieme senza considerare né le relazioni tra queste né le conseguenze della loro sistemazione in quel determinato modo. Il problema è che se l’animazione (e quindi la struttura spaziale di un’interfaccia) viene presa in considerazione solo in un secondo momento, è fin troppo facile creare comportamenti contraddittori.

Ora che abbiamo capito come siamo arrivati fin qui, pensiamo a come poter evitare certe trappole.

Un semplice cambiamento#section2

Fondamentalmente, l’aggiunta di animazioni all’interfaccia le cambia ed è necessario un nuovo modo di pensare. Noi chiamiamo questo approccio animazione semantica. Inizia tutto con un semplice cambiamento concettuale:

Non potete trattare schermate individuali come entità separate se le transizioni tra queste sono animate. Per l’utente, l’intera esperienza è uno spazio continuo.

In maniera simile, due rappresentazioni dello stesso elemento su schermi diversi non possono essere viste come separate tra loro. Per l’utente c’è solo un elemento che cambia semplicemente forma.

Questo vuol dire che quando aggiungete le animazioni, un’interfaccia non è più una serie di schermate, ma una collezione di componenti semantiche all’interno di un singolo spazio continuo. Queste componenti autonome racchiudono tutto quello che è loro associato, come meta informazioni o controlli interattivi.

Esempio di come un post su Dribbble possa funzionare come una componente semantica. Il post rimane sempre un elemento logico, che semplicemente cambia la sua rappresentazione nel tempo.

Può suonare complicato, ma in pratica è in realtà piuttosto semplice: invece di progettare schermate e di aggiungere le transizioni tra queste in un secondo tempo, si comincia dal progettare le componenti individuali e a pensare al modo in cui cambiano e si muovono nei vari contesti. Una volta sistemato questo, il layout e l’animazione ne scaturiranno in maniera naturale, seguendo la struttura semantica del contenuto.

Spiegate le relazioni tra gli elementi#section3

Le animazioni sono più utili quando riflettono e rafforzano le relazioni semantiche tra gli elementi: per esempio, “questo commento appartiene a questo articolo” o “queste voci di menu fanno parte di questo menu”.

Pensate ad ogni elemento della vostra interfaccia come ad una singola componente autosufficiente con uno specifico significato, stato e posizione nello spazio. Poi dovrete essere sicuri che le animazioni riflettano questi aspetti. Se un popover appartiene a un pulsante, non dovrebbe semplicemente fare “fade in”: dovrebbe apparire da quel pulsante. Quando aprite un’email, l’intero messaggio non dovrebbe solo arrivare da un lato, ma dovrebbe provenire dall’interno della preview.

Abbiamo reso l’idea, vero? Una volta che vi sarete abituati a questo modo di pensare, diventerà praticamente automatico.

I dialogs su Meteor Toys sono un ottimo esempio di componenti semantiche.

I seguenti esempi mostrano due approcci completamente diversi allo stesso problema: uno è screen-based, l’altro prende in considerazione l’animazione semantica. Quando aprite Launchpad su OS X, le icone delle app semplicemente compaiono con un fade in e il background viene sfumato. Questo non dice nulla all’utente sulla provenienza delle icone e sulla loro relazione con le altre parti dell’interfaccia.

Launchpad di OS X.

D’altro canto, l’app drawer in GNOME (un ambiente desktop per GNU/Linux) usa un’animazione che spiega elegantemente da dove provengono le icone e dove sono quando non sono visibili.

GNOME application launcher.

Rappresentazioni multiple#section4

Un problema comune a cui prestare attenzione sono le diverse rappresentazioni di un singolo elemento che sono visibili nello stesso momento: questo non va bene perché non ha senso dal punto di vista dell’utente vedere la stessa cosa in più posti contemporaneamente.

Nel seguente esempio tratto dalle Material Design Guidelines di Google, quando fate tap su un’immagine in una visualizzazione a lista, viene mostrata una versione più grande dell’immagine. La versione ingrandita arriva da destra su un livello separato. Questo è un caso da manuale di rappresentazioni multiple: non c’è alcuna connessione tra le due immagini.

Perché l’immagine si trova sia nella visualizzazione a lista sia sull’altra schermata? Le versioni ingrandite delle immagini sono tutte impilate sulla destra?

Google ha recentemente cambiato questo esempio nelle loro linee guida. Ecco la versione aggiornata:

Il nuovo esempio è migliore perché non ci sono rappresentazioni multiple ma l’animazione non riesce a tenere in considerazione gli elementi dell’interfaccia in cima, che cambia senza alcuna animazione.

Ora, c’è un’istanza di qualcosa che controlla tutti i box: la timeline di Facebook Paper rende completamente ovvia la relazione tra visualizzazione thumbnail e visualizzazione di dettaglio. Non ci sono rappresentazioni multiple né dubbi semantici. La transizione è così tranquilla che si nota a malapena il cambiamento di stato.

Vedete come gli elementi dell’interfaccia sul fondo della vista di dettaglio provengono dall’interno dell’immagine? L’immagine è una componente autosufficiente, che contiene tutte le informazioni e azioni ad essa associate.

Un altro esempio di una buona esecuzione di questo è l’app Passbook di Apple. Sulle prime potrebbe sembrare irrilevante, ma immaginatevi se si comportasse come l’esempio del Material, con le full card che entrano da destra quando fate tap su una voce dell’elenco. Sarebbe ridicolo, vero?

La transizione tra visualizzazione a lista e visualizzazione di dettaglio è così fluida che non pensereste ad essa come ad una transizione: gli elementi si muovono semplicemente in maniera naturale nello spazio. Questa è animazione semantica al top!

Mantenete la consistenza nello spazio#section5

Le animazioni creano aspettative su dove si trovino gli elementi animati nello spazio. Per esempio, se una sidebar esce verso sinistra, intuitivamente, sapete che è da qualche parte a sinistra dell’elemento visibile. Pertanto, quando ritorna nella visualizzazione, vi aspettate che entri da sinistra, dove l’avete vista l’ultima volta. Come vi sentireste se entrasse da destra?

A meno che rompano lo spazio stabilito da animazioni precedenti, le animazioni non dovrebbero comunicare informazioni contraddittorie. Il nostro esempio precedente del multitasking di iOS mostra esattamente perché ciò sia problematico: due transizioni diverse comunicano all’utente cose in conflitto, rompendo completamente il loro modello mentale dell’interfaccia.

Curiosamente, OS X fa qualcosa di simile, ma lo gestisce in maniera consistente nello spazio. Quando mettete una finestra a tutto schermo, questa si ridimensiona per riempire l’intero schermo, in maniera simile ad iOS. Tuttavia, si sposta anche orizzontalmente in un nuovo spazio di lavoro. La finestra non è più all’interno del primo workspace, per cui la consistenza spaziale è conservata.

Ricordate: violare la consistenza spaziale è l’equivalente di un quadro di M.C. Escher per le interfacce utente. Quindi, a meno che la vostra app sia Monument Valley, per favore, assicuratevi di mantenere semplice e non contraddittorio il vostro spazio.

Considerazioni pratiche#section6

Magari adesso starete pensando: “Aspetta, non c’è modo di applicare questo a tutto!” Ebbene sì, probabilmente avete ragione.

Se ci siete riusciti, vi troverete con qualcosa come un’unica superficie su cui poter fare zoom che contiene ogni possibile stato del sistema. E, sebbene si tratti di un’idea interessante, un’interfaccia utente “pura” su cui fare zoom tende ad essere problematica nella pratica, perché è difficile navigarvi oltre un certo livello di complessità (PDF).

Quando si progettano prodotti reali, l’animazione semantica deve essere bilanciata da altre considerazioni come la user experience e la performance. Probabilmente, la maggior parte delle vostre interfacce non sarà mai al 100% corretta da un punto di vista di animazione semantica, ma va bene così. L’animazione semantica è un modo di ragionare. Una volta che l’avrete adottato, sarete sorpresi da quante sono le cose a cui potrete applicarla e da quanto sia semplice ottenere animazioni semantiche. Vi costringe a pensare alla gerarchia e alla semantica, che è di aiuto nel trovare soluzioni semplici che abbiano senso per le persone che usano i vostri prodotti.

Si noti che noi, gli autori, siamo ancora ben lontani dall’aver capito tutto questo. Il nostro articolo non tocca molte questioni importanti (che stiamo ancora esplorando) collegate alle conseguenze dell’animare interfacce. Ciononostante, siamo convinti che l’animazione semantica sia un’idea promettente con del vero potenziale per rendere le interfacce digitali più intuitive e comprensibili.

Illustrazioni: {carlok}

Sull’autore

Amin Al Hazwani

Amin Al Hazwani è un designer italiano attualmente residente a Berlino. Progetta app, crea siti web e insegna web e media design alla Free University of Bolzano (Sud Tirolo, Italia). Si interessa di pattern libraries, architetture CSS e animazione. Inoltre, è appassionato di tutto quello che riguarda la tipografia.

Tobias Bernard

Tobias Bernard è un designer e web developer italiano. Attualmente vive in Olanda, dove sta prendendo una laurea in Human Computer Interaction alla University of Twente. Passa molto tempo a riflettere su oscure idee di interface design e a realizzare prototipi di tali idee. Probabilmente è l'unico designer ad usare Arch GNU/Linux.

Nessun commento

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altro da ALA

Webwaste

In questo estratto da World Wide Waste, Gerry McGovern esamina l'impatto ambientale di siti web pieni zeppi di asset inutili. Digital is physical. Sembra economico e gratis ma non lo è: ci costa la Terra.
Industry