Optimistic UI for dummies [Teoria]
Migliorare la UX con feedback immediati sulla UI
Introduzione
In questo articolo vi mostrerò l’importanza di una gestione ottimistica dello stato, ma anche come fa Facebook a nascondere l’incredibile lentezza delle sue API (Voglio vedere voi con 1mld di utenti connessi simultaneamente da gestire :D).
Il pattern più comune per la gestione di un CRUD a livello UI, è quello che prevede l’attesa della response da parte del server per mostrare all’utente un nuovo stato sull’interfaccia.
Questo approccio sebbene molto solido, e corretto da utilizzare in tante situazioni, risulta invece in una interruzione della linearità dell’esperienza utente in altre.
Pensate al caso di un classico Like su un post Facebook. Al click abbiamo un feedback immediato dell’interfaccia che ci mostra il like in stato attivo.
In realtà il momento in cui vediamo il pollice del like accendersi, è in anticipo rispetto al momento in cui il server ci conferma il successo dell’operazione.
Facebook non sa assolutamente se la chiamata per aggiungere o rimuovere un like andrà a buon fine, ma è molto ottimista sul fatto che ciò avverrà, per cui decide di aggiornare lo stato della UI prima di avere una conferma definitiva del server… vedere per credere.
La conferma di success per l’operazione avviene circa 2 secondi dopo la rimozione del nostro like; Pensate quanto potrebbe risultare frustrante per un utente, aspettare quei due secondi, magari vedendo uno spinner girare sul bottone, ogni volta che clicca sull’ iconcina son il pollice all’insù.
Trattare i dati in modo ottimistico permette a Facebook di aumentare notevolmente l’esperienza utente, e allo stesso tempo colmare il gap di sistemi che ogni giorno devono gestire contemporaneamente miliardi di richieste.
Cosa succede quando l’operazione fallisce?
Come sappiamo niente è infallibile, nemmeno Facebook. Quindi, cosa succederebbe se le API fallissero o molto più probabilmente la nostra connessione andasse down?
Questo modo di trattare i dati dovrebbe prevedere sempre che in caso di fail, lo stato precedente possa essere ripristinato immediatamente, e un messaggio d’errore possa avvertire l’utente.
Per far ciò, è necessario che lo stato corrente sia “messo da parte” prima di essere cambiato ottimisticamente e ripristinato se qualcosa dovesse andare storto.
A tal proposito, ho scoperto che sul like di Facebook non esiste un fallback :D in caso di fail. Scollegandomi dalla rete wi-fi e provando a cliccare sul bottone lo stato di quest’ultimo risulta cambiare, anche se l’operazione non è mai stata completata sul server, senza fare alcun rollback sullo stato precedente. Qui ci troviamo di fronte a dei veri ottimisti XD.
Quando utilizzare un approccio ottimistico
Ovviamente questo modo di gestire il feedback della UI non è un approccio utilizzabile in ogni caso. Ad esempio quando vengono chiesti dei nuovi dati a un server il concetto non è applicabile.
Risulta invece un modo molto efficace nel migliorare il feedback della ui, in tutte quelle operazioni dove possiamo conoscere prima come lo stato della UI cambierà a seguito della risposta del server. La creazione di un nuovo elemento, l’update dello stesso o la sua cancellazione sono delle operazioni che possono essere gestite in modo ottimistico perchè i dati o le operazioni che li generano partono direttamente dall’utente(sono già disponibili).
Next step, diventiamo più ottimisti in pratica.
Dopo aver affrontato questo argomento in modo prettamente discorsivo, potrebbe essere interessante introdurre degli esempi pratici di applicazione di questo concetto.
Nel prossimo Articolo, mostrerò la modalità che di solito utilizzo per gestire questi comportamenti sulle app react, con l’aiuto di redux e saga, se intanto, tu che leggi questo articolo vuoi spiegare come gestisci questo concetto in pratica, ti aspetto nei commenti.
