{"id":655,"date":"2016-09-15T16:04:42","date_gmt":"2016-09-15T14:04:42","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/motion-with-meaning-animazione-semantica\/"},"modified":"2016-09-15T16:04:42","modified_gmt":"2016-09-15T14:04:42","slug":"motion-with-meaning-animazione-semantica","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/motion-with-meaning-animazione-semantica\/","title":{"rendered":"Motion with meaning: animazione semantica nell’interface design"},"content":{"rendered":"
\n

L’animazione sta rapidamente diventando una parte essenziale dell’interface design e non \u00e8 difficile capirne il motivo. Ci fornisce una dimensione completamente nuova con cui giocare<\/a>: il tempo, il che crea opportunit\u00e0 per migliorare le interfacce ad ogni livello: pu\u00f2 renderle pi\u00f9 semplici da capire<\/a>, pi\u00f9 piacevoli da usare e pi\u00f9 belle da guardare.<\/p>\n

Per esempio, l’animazione pu\u00f2 contribuire a scaricare parte del lavoro (PDF)<\/a> di elaborazione dei cambiamenti dell’interfaccia dal nostro cervello allo schermo. Pu\u00f2 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\u00f9 complessa un’interfaccia.<\/p>\n

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\u00f9 per trovare la finestra ridotta nel dock?<\/p>\n

<\/p>\n

I tagli netti rendono difficile capire i cambiamenti di stato, perch\u00e9 cambiare l’intera pagina significa che dovete riesaminare l’intera pagina per capire cosa \u00e8 cambiato<\/a>.<\/p>\n<\/div>\n

Fin qui niente da obiettare, giusto? L’animazione \u00e8 una buona cosa<\/em> (perlomeno quando \u00e8 fatta bene<\/a>). Ma c’\u00e8 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\u00f9 chiare.<\/p>\n

Considerate il seguente processo:<\/p>\n

<\/div>\n

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.<\/p>\n

<\/div>\n

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

L’icona dell’app \u00e8 sia nella<\/em> schermata home sia vicino<\/em> alla schermata home. Le due animazioni ci danno informazioni contrastanti su dove si trovino nello spazio la schemata home e le app.<\/p>\n

<\/p>\n

Le due animazioni con effetto zoom hanno in questo caso effetti completamente differenti.<\/p>\n<\/div>\n

Queste animazioni potrebbero<\/em> 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.<\/p>\n<\/div>\n

\n

Storia<\/h2>\n

Come siamo arrivati qui? Facciamo un passo indietro e rivediamo brevemente la storia che ci ha condotto fino a questo punto.<\/p>\n

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

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

<\/p>\n

Esempio di un’animazione incredibilmente fluida in una vecchia versione di Mac OS.<\/p>\n<\/div>\n

Al crescere della capacit\u00e0 dei computer, l’animazione ha cominciato ad essere usata pi\u00f9 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.<\/p>\n

Solo adesso si comincia ad arrivare a un punto in cui le risorse dei computer non sono pi\u00f9 un ostacolo per le interfacce. Con i device di oggi<\/a>, tutto pu\u00f2 essere animato e sempre pi\u00f9 cose lo sono. Il problema \u00e8 che il processo di design non si \u00e8 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<\/a>.<\/p>\n

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

Ora che abbiamo capito come siamo arrivati fin qui, pensiamo a come poter evitare certe trappole.<\/p>\n<\/div>\n

\n

Un semplice cambiamento<\/h2>\n

Fondamentalmente, l’aggiunta di animazioni all’interfaccia le cambia ed \u00e8 necessario un nuovo modo di pensare. Noi chiamiamo questo approccio animazione semantica<\/em>. Inizia tutto con un semplice cambiamento concettuale:<\/p>\n

\n

Non potete trattare schermate individuali come entit\u00e0 separate se le transizioni tra queste sono animate. Per l’utente, l’intera esperienza \u00e8 uno spazio continuo.<\/p><\/blockquote>\n<\/div>\n

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

Questo vuol dire che quando aggiungete le animazioni, un’interfaccia non \u00e8 pi\u00f9 una serie di schermate, ma una collezione di componenti semantiche all’interno di un singolo spazio continuo<\/a>. Queste componenti autonome racchiudono tutto quello che \u00e8 loro associato, come meta informazioni o controlli interattivi.<\/p>\n

<\/p>\n

Esempio di come un post su Dribbble<\/a> possa funzionare come una componente semantica. Il post rimane sempre un elemento logico, che semplicemente cambia la sua rappresentazione nel tempo.<\/p>\n<\/div>\n

Pu\u00f2 suonare complicato, ma in pratica \u00e8 in realt\u00e0 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.<\/p>\n<\/div>\n

\n

Spiegate le relazioni tra gli elementi<\/h2>\n

Le animazioni sono pi\u00f9 utili quando riflettono e rafforzano le relazioni semantiche<\/a> tra gli elementi: per esempio, \u201cquesto commento appartiene a questo articolo\u201d o \u201cqueste voci di menu fanno parte di questo menu\u201d.<\/p>\n

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 \u201cfade in\u201d: 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.<\/p>\n

Abbiamo reso l’idea, vero? Una volta che vi sarete abituati a questo modo di pensare, diventer\u00e0 praticamente automatico.<\/p>\n

<\/p>\n

I dialogs su Meteor Toys<\/a> sono un ottimo esempio di componenti semantiche.<\/p>\n<\/div>\n

I seguenti esempi mostrano due approcci completamente diversi allo stesso problema: uno \u00e8 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.<\/p>\n

<\/p>\n

Launchpad di OS X.<\/p>\n<\/div>\n

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

<\/p>\n

GNOME application launcher.<\/p>\n<\/div>\n

Rappresentazioni multiple<\/h3>\n

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\u00e9 non ha senso dal punto di vista dell’utente vedere la stessa cosa in pi\u00f9 posti contemporaneamente.<\/p>\n

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

<\/div>\n

Perch\u00e9 l’immagine si trova sia nella visualizzazione a lista sia<\/em> sull’altra schermata? Le versioni ingrandite delle immagini sono tutte impilate sulla destra?<\/p>\n

Google ha recentemente cambiato questo esempio nelle loro linee guida. Ecco la versione aggiornata:<\/p>\n

<\/div>\n

Il nuovo esempio \u00e8 migliore perch\u00e9 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.<\/p>\n

Ora, c’\u00e8 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\u00e9 dubbi semantici. La transizione \u00e8 cos\u00ec tranquilla che si nota a malapena il cambiamento di stato.<\/p>\n

<\/div>\n

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

Un altro esempio di una buona esecuzione di questo \u00e8 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?<\/p>\n

La transizione tra visualizzazione a lista e visualizzazione di dettaglio \u00e8 cos\u00ec fluida che non pensereste ad essa come ad una transizione: gli elementi si muovono semplicemente in maniera naturale nello spazio. Questa \u00e8 animazione semantica al top!<\/p>\n

<\/div>\n
\n

Mantenete la consistenza nello spazio<\/h2>\n

Le animazioni creano aspettative su dove si trovino gli elementi animati nello spazio. Per esempio, se una sidebar esce verso sinistra, intuitivamente, sapete che \u00e8 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?<\/p>\n

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\u00e9 ci\u00f2 sia problematico: due transizioni diverse comunicano all’utente cose in conflitto, rompendo completamente il loro modello mentale dell’interfaccia.<\/p>\n

<\/div>\n

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 \u00e8 pi\u00f9 all’interno<\/em> del primo workspace, per cui la consistenza spaziale \u00e8 conservata.<\/p>\n

<\/div>\n

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

\n

Considerazioni pratiche<\/h2>\n

Magari adesso starete pensando: \u201cAspetta, non c’\u00e8 modo di applicare questo a tutto<\/em>!\u201d Ebbene s\u00ec, probabilmente avete ragione.<\/p>\n

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<\/a>, un’interfaccia utente \u201cpura\u201d su cui fare zoom<\/a> tende ad essere problematica nella pratica, perch\u00e9 \u00e8 difficile navigarvi oltre un certo livello di complessit\u00e0 (PDF)<\/a>.<\/p>\n

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\u00e0 mai al 100% corretta da un punto di vista di animazione semantica, ma va bene cos\u00ec. L’animazione semantica \u00e8 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 \u00e8 di aiuto nel trovare soluzioni semplici che abbiano senso per le persone che usano i vostri prodotti.<\/p>\n

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\u00f9 intuitive e comprensibili.<\/p>\n

Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

L’animazione sta rapidamente diventando un pilastro dell’interface design, ma si discute raramente di un particolare aspetto dell’animazione. Amin Al Hazwani e Tobias Bernard discutono sul fatto che l’aggiunta dell’animazione alle interfacce le cambia radicalmente ed \u00e8 quindi necessario di un cambiamento concettuale, un approccio che gli autori chiamano animazione semantica. Le schermate individuali non dovrebbero essere trattate come entit\u00e0 separate se le transizioni tra queste sono animate: l’intera esperienza \u00e8 uno spazio continuo.<\/p>\n","protected":false},"author":818,"featured_media":7000809,"comment_status":"open","ping_status":"open","template":"","categories":[279,155],"tags":[],"coauthors":[485,486],"class_list":["post-655","article","type-article","status-publish","has-post-thumbnail","hentry","category-interaction-design","category-numero-140-15-settembre-2016"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/655","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=655"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000809"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=655"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=655"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=655"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=655"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}