Czym jest optymistyczny interfejs i kiedy go używać

Optymistyczny interfejs użytkownika to wzorzec UX, w którym aplikacja zakłada, że mutacja zakończy się powodzeniem, i natychmiast aktualizuje interfejs — jeszcze przed odpowiedzią serwera. Użytkownik od razu widzi rezultat swojego działania, a rzeczywiste żądanie sieciowe jest wykonywane w tle. Jeśli żądanie się powiedzie, nic się nie zmienia. Jeśli się nie powiedzie, interfejs wycofuje zmianę.

Żądania sieciowe, szczególnie na urządzeniach mobilnych lub przy wolnych połączeniach, wprowadzają opóźnienia, przez które aplikacje wydają się powolne. Optymistyczny interfejs użytkownika eliminuje odczucie oczekiwania. Przycisk polubienia zmienia stan natychmiast po dotknięciu. Element pojawia się na liście w chwili dodania. Aplikacja sprawia wrażenie natychmiastowej, nawet gdy sieć taka nie jest.

Optymistyczne aktualizacje są odpowiednie, gdy mutacja ma bardzo duże szanse powodzenia, a koszt ewentualnego błędu jest niski. Dobrymi kandydatami są: przełączanie polubienia lub zakładki, dodawanie elementu do listy zakupów, aktualizowanie preferencji ustawień oraz zmienianie kolejności elementów na liście metodą przeciągnij i upuść. Są to operacje o niewielkim znaczeniu, w przypadku których krótkotrwała niespójność jest akceptowalna.

Optymistyczny interfejs użytkownika jest nieodpowiedni w przypadku operacji o dużym znaczeniu lub nieodwracalnych. NIE należy go używać w przypadku: transakcji finansowych (wyświetlania płatności jako zakończonej powodzeniem przed potwierdzeniem serwera), trwałego usuwania rekordów, tworzenia rekordów wymagających walidacji po stronie serwera (unikatowych nazw użytkowników, kodów zaproszeń) ani żadnej operacji, w której fałszywe powodzenie mogłoby doprowadzić do uszkodzenia danych.

Każda optymistyczna aktualizacja musi mieć plan wycofania zmian. Gdy serwer odrzuci mutację — z powodu konfliktu, błędu autoryzacji, niepowodzenia walidacji lub przekroczenia czasu oczekiwania na sieć — interfejs musi powrócić do poprzedniego stanu. Brak implementacji wycofania zmian pozostawia interfejs w niespójnym stanie, który nie odzwierciedla już rzeczywistości.

Gdy optymistyczna aktualizacja się nie powiedzie i zostanie wycofana, użytkownicy muszą wiedzieć, co się stało. Najlepszą praktyką jest wyświetlenie dyskretnego toastu z błędem lub komunikatu o błędzie w interfejsie, który wyjaśnia problem i oferuje możliwość ponowienia. Wycofanie zmian powinno przebiegać płynnie — należy unikać gwałtownych przeskoków interfejsu, które mogą dezorientować użytkowników.

Skeleton loadery wyświetlają zawartość zastępczą podczas oczekiwania na załadowanie danych — NIE eliminują oczekiwania, lecz sprawiają, że interfejs wydaje się mniej pusty. Optymistyczny interfejs użytkownika całkowicie eliminuje odczucie oczekiwania, wyświetlając od razu stan końcowy. Skeleton loadery służą do początkowego pobierania danych, a optymistyczne aktualizacje — do obsługi mutacji. Rozwiązują różne problemy.

Optymistyczny interfejs użytkownika działa, ponieważ zdecydowana większość mutacji kończy się powodzeniem. Gdy użytkownik przełącza przycisk polubienia, żądanie kończy się powodzeniem w ponad 99% przypadków. Projektowanie z myślą o pomyślnej ścieżce i sprawne obsługiwanie rzadkich błędów jest bardziej przyjazne dla użytkowników niż zmuszanie wszystkich do każdorazowego oczekiwania na potwierdzenie serwera.

Użytkownicy, którzy zetknęli się z optymistycznym interfejsem użytkownika w aplikacjach takich jak Twitter, Gmail czy Slack, oczekują natychmiastowej reakcji. Aplikacje wymagające wyświetlenia wskaźnika ładowania po każdym działaniu wydają się przy nich powolne. Kształtowanie takich oczekiwań jest częścią nowoczesnego projektowania produktów — responsywne interfejsy nie są już opcjonalnym dodatkiem.

W niektórych przypadkach można subtelnie sygnalizować niepewność podczas wykonywania mutacji. Przygaszony stan, mały wskaźnik ładowania na samym elemencie (nieblokujący całego interfejsu) lub wskaźnik „Zapisywanie...” informuje użytkowników, że operacja jest w toku, bez blokowania interakcji. Jest to rozwiązanie pośrednie między pełnym optymizmem a blokującymi wskaźnikami ładowania.

Optymistyczny interfejs użytkownika zwiększa złożoność: trzeba zarządzać poprzednim stanem na potrzeby wycofania zmian, obsługiwać warunki wyścigu, uzgadniać tymczasowe identyfikatory i jasno komunikować błędy. Taki kompromis jest uzasadniony w przypadku często wykonywanych mutacji o niskim ryzyku. W przypadku złożonych mutacji z istotnym ryzykiem niepowodzenia dodatkowa złożoność może nie rekompensować korzyści dla UX.

Co musi się stać, gdy serwer odrzuci mutację, która została już optymistycznie wyświetlona w interfejsie?

Optymistyczny interfejs użytkownika aktualizuje interfejs przed potwierdzeniem serwera, dzięki czemu aplikacje sprawiają wrażenie natychmiastowych. Należy go stosować w przypadku mutacji o niewielkim znaczeniu i dużym prawdopodobieństwie powodzenia (polubień, dodawania elementów do list, ustawień). Należy unikać go w przypadku operacji finansowych, nieodwracalnego usuwania danych lub unikatowości sprawdzanej przez serwer. Każda optymistyczna aktualizacja wymaga planu wycofania zmian. Błędy należy komunikować za pomocą toastów z błędami i oferować możliwość ponowienia. Kompromisem jest większa złożoność w zamian za znacznie bardziej responsywny UX.