3 dibattiti eterni sulla UI: una guida pratica

Il lavoro del designer è sottovalutato. Quando un’interfaccia funziona, l’utente la scorre in maniera semplice, senza rendersi conto di tutte le insidiose questioni con le quali il designer ha dovuto interfacciarsi per arrivare al risultato finale.

Solo chi mette mano ogni giorno alle piattaforme conosce la complessità che ci sta dietro. A volte si tratta di microinterazioni, ma richiedono ore di ragionamento e, spesso, discussioni anche tra membri dello stesso team.

Con questo articolo vogliamo sbrogliare un po’ della matassa. Sebbene si tratti puramente di convenzioni, cerchiamo di dare delle motivazioni concrete alle nostre scelte.

I tooltip, nemico silenzioso dell’usabilità

Cosa c’è di controverso nei tooltip? Del resto, si tratta di componenti che tutti noi conosciamo e utilizziamo quotidianamente, presenti in larga parte delle piattaforme web. 

Eppure, spesso dietro a un semplice tooltip c’è un vero e proprio problema di usabilità:

• Se l’utente non sa che è presente e non passa accidentalmente con il mouse sull’elemento che lo fa comparire, rischiano di essere invisibili e, pertanto, inutili.
• Spesso, i tooltip non sono visibili al focus, impedendone l’utilizzo agli utenti che usano la piattaforma tramite navigazione da tastiera. Persino librerie di larghissimo impiego, come MUI, a meno che il programmatore non prenda provvedimenti come quello di fornire al componente tooltip un figlio cliccabile (come IconButton nella documentazione), non provvedono automaticamente a farlo comparire al focus.

Un’ulteriore problematica è che i tooltip rendono pigri. “Non è perfettamente comprensibile come usare questa sezione della piattaforma? D’accordo, mettiamo un tooltip per spiegarlo meglio!”; questo ragionamento 一che speriamo appartenga a pochi designer e solamente in situazioni di pressione temporale一 è scorretto e non risolve il vero problema: una piattaforma poco chiara per l’utente.

Quando (e come) usare i tooltip

Ma abbiamo veramente bisogno di un tooltip? Probabilmente esistono situazioni in cui la risposta è: sì. Perché può capitare che la funzione proposta all’utente sia complessa e una buona UI non sia sufficiente a far capire all’utente come utilizzarla. Perché magari, per questa funzionalità, creare un intero tutorial sarebbe una precauzione esagerata e interromperebbe il flusso dell’utente sulla piattaforma.

Per questi casi, la soluzione è solo una:

• Assicurarsi che possano essere utilizzati anche da tastiera. Quando programmiamo una piattaforma dobbiamo essere consapevoli del fatto che potremmo avere utenti con abitudini (o necessità) di utilizzo diverse tra loro. Perciò, è bene provvedere a ciascuno di loro.
• Facilitare la visibilità del tooltip. Ciò può avvenire sia collegandolo a elementi interattivi in sé, come un pulsante, oppure usando simboli convenzionali, come ad esempio un punto interrogativo in un punto rilevante per la funzionalità spiegata.

Quando invece evitare i tooltip

Non sempre la risposta alla domanda precedente è sì; a volte, non abbiamo davvero bisogno di un tooltip. In linea generale, il nostro consiglio è che se siamo in grado di spiegare quello che dobbiamo fare con elementi diversi e sempre presenti a schermo, è preferibile farlo.

Un esempio di uso diffuso dei tooltip è per indicare quali sono le caratteristiche richieste per scegliere una password (come il numero minimo di caratteri, la necessità di una lettera minuscola o di almeno un numero, ecc.). 

In questo caso, la soluzione migliore è dare all’utente l’informazione di cui necessita senza nasconderla. Si può farlo con un elenco puntato al di sotto della casella di testo, oppure, se la presenza del tooltip era dettata da esigenze di spazio, inserire un piccolo testo al di sotto della casella, nello spazio solitamente riservato al messaggio di errore, fintanto che quest’ultimo non compare.

Mostra password: occhietto chiuso o aperto?

Ogni developer scrupoloso si è trovato almeno una volta a chiederselo: se la password è nascosta, il pulsante per renderla visibile dovrebbe mostrare un occhietto chiuso o aperto?

Si tratta di una sottigliezza, d’accordo, ma una direttiva chiara e universalmente condivisa non sembra esistere. Ragioniamo quindi su quale sia la soluzione migliore.

Il componente fa la differenza

Non c’è dubbio, ovviamente, sul fatto che l’occhietto (o la scritta, per chi preferisce questa versione) sia un bottone. Perché questo è rilevante per rispondere alla nostra domanda? Perché solitamente nei pulsanti è scritta l’azione che verrà compiuta nel momento in cui verrà cliccato, ergo la logica porterebbe a propendere per mostrare l’occhio aperto.

Ma, c’è un ma. Per la sua funzione, questo pulsante è assimilabile a uno switch. E negli switch, viceversa, ci aspettiamo di vedere lo stato corrente dell’elemento, come quando Apple ci fa sapere che la Modalità aereo è attiva mostrando lo switch con sfondo blu, chiaro indicatore di stato “on”, o che è disattiva in grigio, equiparabile a un “off”.

Dovremmo quindi trattarlo come un pulsante o come uno switch? La risposta è… dipende. Da un lato, l’utente base non ha idea del codice sottostante; per lui, tutto ciò che ha la funzione di uno switch è, di fatto, uno switch. Ciò quindi ci farebbe propendere per occhio chiuso per mostrare la password e occhio aperto per nasconderla.

Dall’altra parte, alcune volte il pulsante è, con molta evidenza, un pulsante. Ciò avviene per esempio quando si sceglie di usare un bottone con lo sfondo. Del resto, se anziché utilizzare l’icona scegliessimo di mettere una scritta, non avremmo dubbi a scrivere “Mostra” per far comparire la password e “Nascondi” per oscurarla.

Quale icona usare per nascondere la password?

L’ago della bilancia, secondo la nostra opinione, è YouTube. L’occhio della password, del resto, ha molto in comune con il pulsante “play”: è quasi sempre un pulsante con icona e anche in questo caso ha una funzionalità di toggle.

La scelta di YouTube, ma anche di Spotify e di altre app per l’ascolto, è quella di usare il pulsante “play” quando non in ascolto e il pulsante di pausa quando invece il video sta andando. L’equivalente nella casistica che stiamo valutando, quindi, è occhietto chiuso se la password è in vista e viceversa.

In compenso, se hai sempre fatto il contrario, non disperare: qualunque sia la tua scelta, all’utente sarà comunque chiaro quale azione compirà cliccando sull’occhietto, sia esso aperto o chiuso. L’importante è mantenere la coerenza in tutto il tuo prodotto.

E se proprio la spiegazione non ti convince e sei ancora in dubbio, puoi fare come gli ignavi di Google e risolvere con una inequivocabile checkbox con la label “Mostra password” sotto al campo di testo.

Skeleton o spinner, questo è il dilemma

Attendere è frustrante per l’utente e gli studi dimostrano che un caricamento sopra ai tre secondi si associa a un tasso elevato di abbandono: ben il 53% per quanto riguarda l’utilizzo da mobile! Perciò, gestire bene il caricamento è cruciale per non perdere utenti.

L’ultimo dibattito su cui vogliamo gettare luce in questo articolo è la scelta tra skeleton e spinner, due dei più comuni sistemi per gestire il caricamento. Lo diciamo fin da subito: non è uno di quei casi in cui uno dei due ne uscirà come il vincitore definitivo. 

Skeleton e spinner hanno entrambi il loro ruolo, entrambi presentano pregi e difetti, e proprio per questo esistono casi in cui uno dei due è, almeno secondo noi, più indicato. Vediamo quindi come si comportano nei vari casi.

Lo skeleton: un caricamento elaborato

Lo skeleton è un modo elaborato ed elegante per gestire il caricamento. Con il suo colore neutro (solitamente sui toni del grigio) e l’animazione che lo fa sembrare una sorta di fantasma, anticipa all’utente i contenuti che vedrà sulla pagina. Poiché dà l’impressione di avere già del contenuto nella pagina, contribuisce alla retention degli utenti.

È proprio questo il suo principale punto di forza: predispone l’utente a ciò che gli comparirà alla vista e, pertanto, quando finalmente il contenuto carica e compare nella pagina, lo spostamento degli elementi è minimo.

Ciò lo rende adatto soprattutto nel caso di:

• Caricamenti più lunghi e che coinvolgono ampie sezioni.
• Testi in attesa, che occupano uno spazio lungo e stretto.
• Caricamento di sezioni con forme particolari (ad esempio, i blocchi di attività mostrati all’interno di un calendario).

Dal canto opposto, per poter mostrare uno skeleton è necessario sapere che layout finale comparirà. Ciò non è sempre il caso, ad esempio quando si sta ottenendo un dato che ci dice se l’utente è admin o meno e, a seconda di ciò, il contenuto della pagina varia largamente.

Inoltre, da programmatori sappiamo che creare lo skeleton di una pagina intera richiede molto più tempo rispetto all’inserimento di un semplice spinner; va quindi messo in conto anche il rapporto tra sforzo e resa. Nonostante ciò, lo skeleton resta la scelta prediletta quando è possibile implementarlo per bene.

Lo spinner: un caricamento poco pretenzioso

Lo spinner è il simbolo del caricamento per eccellenza, il modo più ovvio di mostrare l’attesa. La rotellina rotante è inequivocabile e rapida da implementare. Lo spinner quindi è la scelta migliore quando abbiamo:

• Caricamenti di singole sezioni la cui forma non può essere anticipata prima di avere i dati caricati.
• Bottoni che compiono un’azione che richiede tempo; lo spinner può affiancare o sostituire il testo del pulsante, lasciando invariato il resto della pagina.
• Caricamento di sezioni “piene”, come video incorporati nella pagina, dove lo skeleton potrebbe generare confusione.

D’altro canto, però, lo spinner se utilizzato per larghe sezioni lascia molto spazio vuoto, inducendo l’utente rapidamente alla noia quando in attesa. 

Esistono quindi soluzioni adiacenti che possono rivelarsi migliori quando implementare lo skeleton è impossibile e uno spinner non è sufficiente, ad esempio animazioni di caricamento o barre di progressione. 

Ti è piaciuto questo articolo? Continua a seguire il nostro blog, con articoli nuovi ogni settimana. E se hai altre questioni di UI di cui vuoi sentirci parlare, o se semplicemente vuoi darci la tua opinione su queste, scrivici qui: