Le animazioni di transizione nell'interfaccia

Home » Articoli » Le animazioni di transizione nell'interfaccia

25/06/2015

Le animazioni di transizione nell'interfaccia

[di Maurizio Boscarol]

Le animazioni che rendono più fluide o reattive le transizioni fra stati di un’interfaccia stanno acquisendo sempre maggior importanza, grazie alla maggior facilità di realizzazione tramite CSS3 e Javascript. Sono diverse dalle animazioni complesse, perché di solito servono a sottolineare piccoli aspetti dell’interazione. Come utilizzarle?

Il recente redesign di un form di login da parte di GoSquared costituisce un interessante caso di studio (anche su altri aspetti, per cui rimando all’articolo originale) e un esempio adatto per riflettere sul ruolo delle animazioni.

Label che si muovono

Il problema

Per risparmiare spazio le label vengono spesso inserite all’interno del campo, e fatte sparire quando un utente inizia a scriverci. Il fatto che spariscano può far mancare la comprensione di quale tipo di dato inserire ad utenti frettolosi, che iniziano a scrivere prima di guardare la label, e poi magari si fanno venire il dubbio.

Fare sparire le label quando si scrive può non essere insomma la soluzione migliore, seppur solo per una certa quota (ipotetica) di utenti.

Non stiamo parlando di problemi osservati nei test, ma di cura del designer affinché quei problemi, anche solo supposti, non si presentino.

La soluzione animata

La soluzione qui adottata è stata quella di non far sparire la label, ma di spostarla fuori dal campo, in modo da farla rimanere sempre visibile:

: Label che si sposta a lato durante la compilazione

Nei dispositivi mobili la label viene spostata in alto anziché a lato:

: Nei dispositivi mobili la label si sposta verso l’alto. Notate che fin da subito c’è maggior spazio fra il primo e il secondo campo rispetto all’immagine precedente, per far posto alla label del secondo campo quando si sposterà verso l’alto.

Lo spostamento avviene con un gradevole effetto di animazione come bonus.

Sì, ma… dov’è il guadagno di spazio?

La soluzione è ingegnosa, ma poiché di solito la label viene posizionata dentro il campo per risparmiare spazio, c’è un’osservazione da fare:

Se riserviamo in anticipo lo spazio per spostare le etichette a sinistra o sopra il campo, dov’è il vantaggio di posizionare le label dentro il campo?

Non sarebbe più semplice posizionare da subito le label esterne ai campi?

«E’ per soddisfarti meglio»

La risposta è ovvia: la soluzione non serve a risparmiare spazio, ma a rendere l’interfaccia più piacevole.

L’animazione è inaspettata, è elegante e fluida, e restituisce un senso di “reattività” piacevole. Almeno, questo è quello che si aspettano i designer (bisognerebbe valutare se è anche l’effetto ottenuto).

Insomma, la scelta non è legata a ragioni di efficienza o di maggior comprensibilità, ma al tentativo di migliorare gli aspetti “ludici” dell’esperienza utente. Benché non necessaria, la soluzione non è certamente peggiorativa, anzi, a parità di efficienza rende l’interfaccia più “giocabile”. Notate il “a parità di efficienza”… Quindi:

La soluzione di GoSquared è equivalente ad una tradizionale sul piano della facilità di compilazione e dello spazio occupato.
Ma è probabilmente superiore nella percezione di gradevolezza dell’interfaccia.

Le animazioni sono feedback!

Le animazioni devono dunque essere sostanzialmente solo gradevoli? Decisamente no, ma la gradevolezza può anche essere un obiettivo sufficiente, purché non contrasti con quelli più funzionali.

Lo scopo funzionale vero delle animazioni di transizione (anche nel caso di GoSquared) è quello di fornire feedback su cosa è avvenuto e anticipare cosa sta per avvenire.

Le animazioni di transizione sono feedback. A volte feedforward. Anche quando il feedback è ridondante o inutile, svolgono questo ruolo. E esagerarle o utilizzarle senza questa consapevolezza rischia di creare interfacce pesanti, inappropriate, che si “rivolgono” all’utente in modi sgraditi, o fuorviano i propri messaggi all’utente.

Un esempio noto

Le animazioni migliori sono quelle sottili e discrete, che segnalano meccanismi dell’interfaccia che altrimenti potrebbero non essere chiari; e, già che ci sono, lo fanno in modo divertente. Tenendo cioè conto dei principi di animazione usati nel cinema (di cui parleremo più diffusamente in altro articolo).

Un esempio di questo tipo è il “genie effect” di finestre dal dock di Mac OsX. Le finestre per la prima volta vengono presentate come oggetti flessibili, gommosi o gassosi come un genio che esce dalla lampada per assumere una consistenza.

: Il “Genie effect” di minimizzazione/massimizzazione delle finestre dal Dock

In questo caso gli autori di Mac OsX hanno usato l’animazione, che già esisteva nei sistemi operativi a finestra ma “scalava” le finestre mantenendone le proporzioni, per suggerire una metafora: il computer è la nostra lampada di Aladino, che attiva diversi geni a piacimento.

Piccola nota a margine a proposito dell’efficienza: l’animazione “genie effect” di Mac Os X è più lenta della corrispondente animazione “scale”. I peggioramenti dell’efficienza sarebbe meglio non ci fossero, ma se sono nell’ordine di pochi millisecondi per compiti relativamente poco frequenti, possono essere tollerati da gran parte degli utenti. Ma per dimostrare che questi piccoli peggioramenti sono sgraditi a parte dell’utenza, è sufficiente consultare i molti forum e siti dove gli utenti discutono di come eliminare il genie effect per tornare a un più rapido “effetto scale”!

Le pagine web non sono sistemi operativi!

Questo genere di “significati latenti” possono essere attivati dalle animazioni ma non sono così frequenti. E sono certamente più facili da adottare nei sistemi operativi, usati quotidianamente e sui quali gli utenti formano abitudini precise, che sulle pagine web, che vedono utilizzi più rari e meno costanti.

In sintesi: calibrate bene le animazioni, rendetele divertenti, ma senza peggiorare l’efficienza dell’interfaccia e anzi sottolineando passaggi di causa-effetto, migliorando “apprendibilità”, offrendo feedback, eventualmente con effetti divertenti. Ma rigorosamente senza strafare. Il che significa: con perizia anche tecnica.

Attenzione agli aspetti tecnici!

Buona parte del javascript che accompagna le pagine di GoSquared è dedicato ad una forte ottimizzazione delle animazioni. Questo è essenziale per evitare di rallentare il rendering e il funzionamento della pagina.

Per chi fosse interessato agli aspetti tecnici (tipo, che le animazioni di GoSquared hanno un framerate di 60fps…), lo scorso anno lo stesso blog aveva pubblicato un articolo proprio sull’ottimizzazione nei browser di Javascript e CSS per ottenere la massima fluidità tenendo conto della CPU, della GPU, del funzionamento dei browser e dei problemi di caricamento.

Raccomandazioni

Lievi animazioni di transizione in pagina possono essere efficaci e utili, ma portano con sé il rischio di strafare o di fare male. Per trovare la giusta misura bisogna valutare una serie di questioni:

Non dovrebbero peggiorare l’efficienza (il numero di click, di passaggi, o il tempo) nell’esecuzione di un compito o di un’azione.
Non dovrebbero portare ad un aumento significativo del peso della pagina (in termini di javascript o css addizionale).
Dovrebbero essere risposte ad azioni dell’utente, e dovrebbero a quelle azioni essere commisurate, non sovrastarle. Ad un’azione piccola e banale come posizionarsi su un campo non deve partire un jingle animato di 30 secondi, ma una label può tranquillamente muoversi per rimanere visibile!
Dovrebbero essere fluide e non appesantire CPU e GPU
Dovrebbero degradare dolcemente: i browser non compatibili dovrebbero ricevere una versione che funziona bene anche senza animazione
Dovrebbero focalizzarsi su alcune categorie di eventi o situazioni:
1. Dovrebbero essere usate per sottolineare il comportamento di un oggetto o di una procedura: offrire un feedback, un feedforward, un indizio. Vi rientrano le animazioni di flip (servono a far capire che si sta vedendo il retro della stessa card), quelle delle label qui sopra, lo spostamento di un oggetto in un carrello, ecc.
2. Dovrebbero essere usate in maniera più discreta per far notare l’esistenza o la possibile funzione di un oggetto in pagina (ad esempio attraverso un lieve tremolìo, un cambio di colore, un piccolo movimento).
3. Nel primo caso (sottolineare un comportamento) possono essere più esplicite e occupare un angolo visivo ampio, ma limitato all’esecuzione di una certa azione; nel secondo dovrebbero limitarsi all’area dell’oggetto, per non rischiare di vampirizzare l’attenzione dell’utente.