Basta con gli spinner: c’è di meglio

by Giuseppe Lanzi on 7 aprile 2017

Quanti di noi sono abituati a vedere uno spinner di caricamento nelle app che usiamo tutti i giorni? Tutti.
Quanti di noi hanno cercato di realizzare un bello spinner, che potesse piacere agli utenti e che fosse accattivante? Molti.
Quanto è davvero utile uno spinner di caricamento? Poco.

Almeno questo è il parere di un articolista di UXDesign, espresso in un articolo davvero interessante che mi è capitato di leggere di recente e che oggi vi voglio proporre.

Le ragioni dietro a questa opionione valgono la pena un piccolo ragionamento. Uno spinner:

  • non dà informazioni sul progresso dell’operazione;
  • dà all’utente una sensazione di incertezza, finché non sparisce per lasciare posto al contenuto;
  • dà l’impressione che l’app richieda uno spinner, e quindi che sia lenta;
  • non dà alcuna informazione su ciò che verrà dopo, che resta una sorpresa.

Ma allora qual è la soluzione suggerita dall’articolista? Semplice: Skeletons (scheletri), di videata che replichino ciò che verrà mostrato all’utente al termine del caricamento, da popolare gradualmente mano a mano che il contenuto è disponibile.

Questa soluzione ha diversi vantaggi:

  • aiuta la percezione di velocità (perché c’è subito qualcosa da vedere);
  • elimina l’effetto sorpresa;
  • permette di realizzare un caricamento progressivo in modo semplice;
  • mostra chiaramente all’utente quali sono i contenuti per i quali sta aspettando.

Nell’articolo ci sono diversi esempi da vedere, a cui vi suggerisco di dare un’occhiata per avere spunti su come disegnare la prossima app.

Bello, c’è sempre qualcosa da imparare :)

{ 2 comments… read them below or add one }

1 Poidomani Giovanni 8 aprile 2017 alle 21:27

bellissima idea … quando potremo sfruttarla con INDE?

2 Enrico 9 aprile 2017 alle 14:53

Credo che l’idea dello spinner sia più che altro associata al concetto:
ehi, mica mi son piantato, sto ancora lavorando.

Le idee esposte sopra sono interessanti sulla carta, ma laboriose da implementare, e si applicano ad un piccolo sottoinsieme di casi pratici, a mio parere.
Prevedere tutte le possibili tempistiche un cui un dato potrà essere disponibile ed adeguare di conseguenza il sistema descritto sopra è un compito bestiale.

Intendo: immaginiamo una videata con 10 campi, ognuno impiega 2 secondi ad essere calcolato: sarebbe perfetto, giusto? ma quante volte capiterà qualcosa di simile? se la seconda videata avesse 9 campi disponibili subito, ma il decimo richiedesse 20 secondi? in questo caso l’utente avrebbe una sensazione di incertezza ben peggiore rispetto allo spinner.
Bisognerebbe avere un algoritmo che preveda il tempo di calcolo di ogni dato, dopodiché “simulare” un riempimento progressivo…
mah, vedrei meglio uno spinner più comunicativo, tipo pallina che gira e sotto qualche informazione semitecnica sulle operazioni in corso.

Leave a Comment

Previous post:

Next post: