Prawdziwe kłamstwa optymistycznych interfejsów użytkownika

Trzy interfejsy użytkownika (UI) trafiają do pubu. Pierwszy zamawia drinka, potem jeszcze kilku. Kilka godzin później prosi o rachunek i wychodzi z pubu pijany. Drugi interfejs użytkownika zamawia drinka, płaci za niego z góry, zamawia kolejnego drinka, płaci za niego i tak dalej, po czym za kilka godzin wychodzi z pubu pijany. Trzeci interfejs wychodzi z pubu już pijany zaraz po wejściu — wie, jak działają puby i jest na tyle wydajny, że nie traci czasu. Słyszałeś o tym trzecim? Nazywa się to „optymistycznym interfejsem użytkownika”.

Ostatnio, omawiając psychologiczną optymalizację wydajności na wielu konferencjach poświęconych zarówno front-endowi, jak i UX, byłem zaskoczony, widząc, jak mało temat optymistycznego projektowania interfejsu użytkownika jest poruszany w społeczności. Szczerze mówiąc, sam termin nie jest nawet dobrze zdefiniowany. W tym artykule dowiemy się, na jakich koncepcjach się opiera, przyjrzymy się kilku przykładom, a także przyjrzymy się jego psychologicznemu podłożu. Następnie przejrzymy obawy i główne punkty dotyczące tego, jak zachować kontrolę nad tą techniką UX.

Dalsze czytanie na SmashingMag:

• Użytkownik jest anonimowym projektantem stron internetowych
• Projektowanie interfejsów użytkownika opartych na kartach
• Interfejsy konwersacyjne: gdzie jesteśmy dzisiaj?
  

Ale zanim zaczniemy, prawdę mówiąc, żadnej rzeczy nie można nazwać „optymistycznym interfejsem użytkownika”. Jest to raczej model mentalny stojący za implementacją interfejsu. Optymistyczny projekt interfejsu użytkownika ma swoją historię i uzasadnienie.

Pewnego razu

Dawno temu — kiedy słowo „tweet” odnosiło się głównie do ptaków, Apple był na skraju bankructwa, a ludzie wciąż umieszczali numery faksów na wizytówkach — interfejsy sieciowe były dość ascetyczne. A zdecydowana większość z nich nie miała nawet cienia optymizmu. Na przykład interakcja z przyciskiem może przebiegać według scenariusza podobnego do następującego:

1. Użytkownik klika przycisk.
2. Przycisk przechodzi w stan nieaktywny.
3. Połączenie jest wysyłane do serwera.
4. Odpowiedź z serwera jest wysyłana z powrotem na stronę.
5. Strona jest ponownie ładowana, aby odzwierciedlić stan odpowiedzi.

Może to wyglądać na dość nieefektywne w 2016 roku; jednak, co zaskakujące, ten sam scenariusz jest nadal używany w wielu stronach internetowych i aplikacjach i nadal jest częścią procesu interakcji dla wielu produktów. Powodem jest to, że jest to przewidywalne i mniej lub bardziej odporne na błędy: użytkownik wie, że akcja została zażądana z serwera (wyłączony stan przycisku wskazuje na to), a gdy serwer odpowie, zaktualizowana strona wyraźnie wskazuje koniec tej interakcji klient-serwer-klient. Problemy z tego rodzaju interakcjami są dość oczywiste:

• Użytkownik musi czekać. Na razie wiemy, że nawet najkrótsze opóźnienie w czasie reakcji serwera ma negatywny wpływ na postrzeganie przez użytkownika całej marki, nie tylko na tej konkretnej stronie.
• Za każdym razem, gdy użytkownik otrzymuje odpowiedź na swoje działanie, jest ona prezentowana w dość destrukcyjny sposób (wczytuje się nowa strona zamiast aktualizować istniejącą), co przerywa kontekst zadania użytkownika i może wpłynąć na jego tok myślenia. Chociaż w tym przypadku niekoniecznie mówimy o wielozadaniowości, zmiana kontekstu mentalnego jest nieprzyjemna. Tak więc, jeśli akcja nie jest z natury przeznaczona do zmiany kontekstu (płatność online jest dobrym przykładem tego, kiedy zmiana jest naturalna), zmiana wywoła nieprzyjazny ton dialogu między użytkownikiem a systemem.

Dobre, nie tak stare dni

Następnie pojawił się tak zwany Web 2.0, który zapewnił nowe sposoby interakcji ze stronami internetowymi. Rdzeniem z nich były XMLHttpRequest i AJAX. Te nowe tryby interakcji zostały uzupełnione „spinnerami”: najprostszą formą wskaźnika postępu, którego jedynym celem było poinformowanie użytkownika, że ​​system jest zajęty wykonywaniem jakiejś operacji. Teraz nie musieliśmy ponownie ładować strony po otrzymaniu odpowiedzi z serwera; moglibyśmy zamiast tego zaktualizować część już wyrenderowanej strony. Dzięki temu sieć była znacznie bardziej dynamiczna, a jednocześnie zapewniała płynniejsze i bardziej angażujące wrażenia dla użytkowników. Typowa interakcja z przyciskiem mogłaby teraz wyglądać tak:

1. Użytkownik klika przycisk.
2. Przycisk jest uruchamiany w stanie wyłączonym, a na przycisku pojawia się jakiś rodzaj pokrętła, aby wskazać, że system działa.
3. Połączenie jest wysyłane do serwera.
4. Odpowiedź z serwera jest wysyłana z powrotem na stronę.
5. Wizualny stan przycisku i strony jest aktualizowany zgodnie ze stanem odpowiedzi.

Ten nowy model interakcji rozwiązał jeden z wyżej wymienionych problemów starej metody interakcji: aktualizacja strony odbywa się bez destrukcyjnego działania, zachowując kontekst dla użytkownika i angażując go w interakcję znacznie lepiej niż wcześniej.

Ten rodzaj wzorca interakcji jest szeroko stosowany w mediach cyfrowych. Pozostaje jednak jeden problem: użytkownicy nadal muszą czekać na odpowiedź z serwera. Tak, możemy sprawić, że nasze serwery będą reagowały szybciej, ale bez względu na to, jak bardzo staramy się przyspieszyć infrastrukturę, użytkownicy wciąż muszą poczekać. Ponownie użytkownicy nie lubią czekać, delikatnie mówiąc. Na przykład badania pokazują, że 78% konsumentów odczuwa negatywne emocje w wyniku powolnych lub zawodnych stron internetowych. Co więcej, według ankiety przeprowadzonej przez Harris Interactive dla Tealeaf 23% użytkowników przyznaje się do przeklinania przy swoich telefonach, 11% na nich krzyczy, a całe 4% faktycznie rzuciło telefonem, gdy miało problem z transakcją online. Wśród tych problemów są opóźnienia.

Nawet jeśli pokazujesz jakiś wskaźnik postępu, gdy użytkownik czeka, chyba że jesteś bardzo kreatywny z tym wskaźnikiem, w dzisiejszych czasach to po prostu nie wystarczy. W większości ludzie przyzwyczaili się do spinnerów wskazujących na powolność systemu. Spinners są teraz bardziej kojarzone z czysto pasywnym oczekiwaniem, gdy użytkownik nie ma innej opcji niż czekanie na odpowiedź serwera lub całkowite zamknięcie karty lub aplikacji. Wymyślmy więc krok, aby poprawić ten rodzaj interakcji; spójrzmy na tę koncepcję optymistycznego interfejsu użytkownika.

Optymistyczny interfejs użytkownika

Jak wspomniano, optymistyczny interfejs użytkownika to nic innego jak sposób obsługi interakcji człowiek-komputer. Aby zrozumieć główne idee, które się za tym stoją, będziemy trzymać się naszego scenariusza „użytkownik klika przycisk”. Ale zasada będzie taka sama w przypadku prawie każdego rodzaju interakcji, które możesz chcieć nabrać optymistycznie. Według Oxford English Dictionary:

op-ti-mis-tic , przym. z nadzieją i ufnością w przyszłość.

Zacznijmy od części „pewni w przyszłość”.

Jak myślisz: Jak często Twój serwer zwraca błąd przy jakiejś akcji użytkownika? Na przykład, czy Twój interfejs API często ulega awarii, gdy użytkownicy klikają przycisk? A może bardzo zawodzi, gdy użytkownicy klikają link? Szczerze, nie sądzę. Oczywiście może się to różnić w zależności od API, obciążenia serwera, poziomu obsługi błędów i innych czynników, w które Ty, jako front-end developer lub specjalista UX, możesz nie chcieć się angażować. Ale o ile API jest stabilny i przewidywalny, a frontend poprawnie komunikuje prawidłowe działania w interfejsie użytkownika, wtedy liczba błędów w odpowiedzi na akcje inicjowane przez użytkownika będzie dość niska. Posunąłbym się do stwierdzenia, że ​​nigdy nie powinny przekraczać 1 do 3%. Oznacza to, że w 97 do 99% przypadków, gdy użytkownik kliknie przycisk na stronie, odpowiedź serwera powinna być udana i bezbłędna. To zasługuje na lepszą perspektywę:

Pomyśl o tym przez chwilę: gdybyśmy byli w 97 do 99% pewni sukcesu odpowiedzi, moglibyśmy być pewni przyszłości tych odpowiedzi — cóż, przynajmniej o wiele bardziej pewni przyszłości niż kot Schrodingera. Moglibyśmy napisać zupełnie nową historię o interakcji przycisków:

1. Użytkownik klika przycisk.
2. Wizualny stan przycisku natychmiast przechodzi w tryb sukcesu.

Otóż ​​to! Przynajmniej z punktu widzenia użytkownika, nie ma w tym nic więcej — bez czekania, bez patrzenia na wyłączony przycisk i nie kolejny irytujący spinner. Interakcja jest płynna, bez konieczności wkraczania systemu w celu przypomnienia użytkownikowi o sobie.

Z punktu widzenia dewelopera cały cykl wygląda tak:

1. Użytkownik klika przycisk.
2. Wizualny stan przycisku natychmiast przechodzi w tryb sukcesu.
3. Połączenie jest wysyłane na serwer.
4. Odpowiedź z serwera jest odsyłana z powrotem do strony.
5. W 97 do 99% przypadków wiemy, że odpowiedź zakończy się sukcesem, więc nie musimy niepokoić użytkownika.
6. Dopiero w przypadku niepowodzenia żądania system odezwie się. Nie martw się tym na razie — do tego dojdziemy w dalszej części artykułu.

Spójrzmy na kilka przykładów optymistycznych interakcji. Prawdopodobnie znasz przyciski „lubię to”, które można znaleźć na Facebooku i Twitterze. Przyjrzyjmy się temu drugiemu.

Oczywiście zaczyna się od kliknięcia przycisku. Ale zwróć uwagę na wizualny stan przycisku, gdy użytkownik nie naciska już ani nie unosi się nad przyciskiem. Natychmiast przechodzi w stan sukcesu!

Zobaczmy, co dzieje się w tej chwili na karcie „Sieć” w narzędziach programistycznych naszej przeglądarki.

Zakładka „Sieć” pokazuje, że żądanie serwera zostało wysłane, ale nadal trwa. Licznik „polubień” nie został jeszcze zwiększony, ale wraz ze zmianą koloru interfejs wyraźnie informuje użytkownika o sukcesie, nawet przed otrzymaniem odpowiedzi z serwera.

Po otrzymaniu pozytywnej odpowiedzi z serwera licznik jest aktualizowany, ale przejście jest znacznie subtelniejsze niż natychmiastowa zmiana koloru. Zapewnia to użytkownikowi płynne, nieprzerwane wrażenia, bez odczuwalnego oczekiwania.

Inny przykład optymistycznej interakcji widać na Facebooku z własnym przyciskiem „Lubię to”. Scenariusz jest dość podobny, z wyjątkiem tego, że Facebook natychmiast aktualizuje licznik, wraz z kolorem przycisku sukcesu, nie czekając na odpowiedź serwera.

Należy jednak zwrócić uwagę na jedną rzecz. Jeśli spojrzymy na czas odpowiedzi serwera, zobaczymy, że wynosi on nieco ponad 1 sekundę . Biorąc pod uwagę, że model RAIL zaleca 100 milisekund jako optymalny czas odpowiedzi dla prostej interakcji, byłby to zwykle zdecydowanie za długi czas. Jednak użytkownik nie odczuwa w tym przypadku żadnego czasu oczekiwania ze względu na optymistyczny charakter tej interakcji. Miły! To kolejny przykład optymalizacji wydajności psychologicznej .

Ale spójrzmy prawdzie w oczy: nadal istnieje 1 do 3% szansy, że serwer zwróci błąd. A może użytkownik jest po prostu offline. Lub, co bardziej prawdopodobne, być może serwer zwraca odpowiedź, która jest technicznie pomyślna, ale odpowiedź zawiera informacje, które muszą być dalej przetwarzane przez klienta. W rezultacie użytkownik nie otrzyma wskaźnika niepowodzenia, ale nie możemy też uznać odpowiedzi za sukces. Aby zrozumieć, jak radzić sobie z takimi przypadkami, powinniśmy przede wszystkim zrozumieć, dlaczego i jak optymistyczne interfejsy użytkownika działają psychologicznie.

Psychologia stojąca za optymistycznym interfejsem użytkownika

Jak dotąd nie słyszałem, aby ktokolwiek narzekał na wspomniane wyżej optymistyczne interakcje na głównych portalach społecznościowych. Załóżmy więc, że te przykłady przekonały nas, że optymistyczne interfejsy użytkownika działają. Ale dlaczego pracują dla użytkowników? Działają po prostu dlatego, że ludzie nienawidzą czekać. To wszystko, ludzie! Możesz przejść do następnej części artykułu.

Ale jeśli nadal czytasz, prawdopodobnie chcesz wiedzieć, dlaczego tak jest. Zagłębmy się więc nieco głębiej w psychologiczne podłoże tego podejścia.

Optymistyczny interfejs użytkownika ma dwa podstawowe składniki, które warto przeanalizować psychologicznie:

• szybka reakcja na działanie użytkownika;
• obsługa potencjalnych awarii na serwerze, w sieci i gdzie indziej.

Szybka reakcja na akcję użytkownika

Kiedy mówimy o optymistycznym projektowaniu interfejsu użytkownika, mówimy o optymalnym czasie reakcji w interakcji człowiek-komputer. A rekomendacje dla tego typu komunikacji istnieją już od 1968 roku. Wtedy Robert B. Miller opublikował swój przełomowy artykuł „Response Time in Man-Computer Conversational Transactions” (PDF), w którym zdefiniował aż 17 różne typy odpowiedzi, jakie użytkownik może uzyskać z komputera. Jeden z tych typów Miller nazywa „reakcją na sterowanie aktywacją” — opóźnieniem między naciśnięciem klawisza a wizualną informacją zwrotną. Nawet w 1968 roku nie powinien przekraczać 0,1 do 0,2 sekundy. Tak, model RAIL nie jest pierwszym, który to poleca — rada ta istnieje od około 50 lat. Miller zauważa jednak, że nawet to krótkie opóźnienie w sprzężeniu zwrotnym może być zbyt wolne dla wykwalifikowanych użytkowników. Oznacza to, że najlepiej byłoby, gdyby użytkownik otrzymał potwierdzenie swojego działania w ciągu 100 milisekund . To wchodzi w zakres jednej z najszybszych nieświadomych czynności, jakie może wykonać ludzkie ciało — mrugnięcia okiem. Z tego powodu interwał 100 milisekund jest zwykle postrzegany jako natychmiastowy. „Większość ludzi mruga około 15 razy na minutę, a mrugnięcie trwa średnio od 100 do 150 milisekund”, mówi Davina Bristow z Instytutu Neurologii University College London, dodając, że „oznacza to, że ogólnie mrugamy przez co najmniej 9 dni w roku. ”

Ze względu na natychmiastową reakcję wizualną (nawet przed zakończeniem faktycznego żądania), optymistyczny interfejs użytkownika jest jednym z przykładów technik wczesnego wypełniania stosowanych w psychologicznej optymalizacji wydajności. Ale fakt, że ludzie lubią interfejsy, które reagują w mgnieniu oka, nie powinien być dla większości zaskoczeniem. I nie jest to trudne do osiągnięcia. Nawet w dawnych czasach wyłączaliśmy przyciski natychmiast po ich kliknięciu, a to zwykle wystarczało do potwierdzenia wpisu użytkownika. Ale stan wyłączenia w elemencie interfejsu oznacza pasywne oczekiwanie: użytkownik nie może nic z tym zrobić i nie ma kontroli nad procesem. A to jest bardzo frustrujące dla użytkownika. Dlatego całkowicie pomijamy stan wyłączenia w optymistycznym interfejsie użytkownika — komunikujemy pozytywny wynik zamiast zmuszać użytkownika do czekania.

Obsługa potencjalnej awarii

Przejdźmy do drugiego interesującego psychologicznego aspektu optymistycznego projektowania interfejsu użytkownika — radzenia sobie z potencjalną awarią. Ogólnie rzecz biorąc, dostępnych jest wiele informacji i artykułów o tym, jak najlepiej radzić sobie z błędami interfejsu użytkownika. Jednak chociaż w dalszej części tego artykułu zobaczymy, jak radzić sobie z awariami, w optymistycznym interfejsie użytkownika najważniejsze jest nie to, jak radzimy sobie z błędami, ale kiedy to robimy.

Ludzie w naturalny sposób organizują swoją działalność w skupiska, kończące się realizacją subiektywnie określonego celu lub podcelu. Czasami nazywamy te skupiska „ciągiem myśli”, „przepływem myśli” (PDF) lub po prostu „przepływem”. Stan przepływu charakteryzuje się szczytową przyjemnością, energetycznym skupieniem i twórczą koncentracją. Podczas przepływu użytkownik jest całkowicie pochłonięty aktywnością. Tweet autorstwa Tammy Everts ładnie to ilustruje:

W sieci czasy trwania takich grup aktywności są znacznie krótsze. Wróćmy na chwilę do pracy Roberta B. Millera. Typy odpowiedzi, które cytuje, obejmują:

• odpowiedź na proste zapytanie dotyczące wymienionych informacji;
• odpowiedź na złożone zapytanie w formie graficznej;
• odpowiedź na „System, rozumiesz mnie?”

Wiąże je wszystkie z tym samym 2-sekundowym interwałem, w którym użytkownik powinien otrzymać odpowiedni typ odpowiedzi. Nie wnikając głębiej, powinniśmy zauważyć, że ten przedział zależy również od pamięci roboczej danej osoby (odnosząc się do okresu czasu, w którym osoba może przechowywać pewną ilość informacji w swojej głowie i, co ważniejsze, być w stanie nią manipulować). Dla nas, jako programistów i specjalistów UX, oznacza to, że w ciągu 2 sekund od interakcji z elementem, użytkownik będzie w przepływie i skupiony na oczekiwanej odpowiedzi. Jeśli serwer zwróci błąd w tym czasie, użytkownik nadal będzie „dialogował” z interfejsem, że tak powiem. Przypomina to dialog między dwojgiem ludzi, w którym mówisz coś, a druga osoba delikatnie się z tobą nie zgadza. Wyobraź sobie, że druga osoba przez długi czas kiwała głową na znak zgody (odpowiednik naszego wskazania stanu sukcesu w interfejsie), ale w końcu powiedziała ci „nie”. Niezręczne, prawda? Tak więc optymistyczny interfejs użytkownika musi informować użytkownika o niepowodzeniu w ciągu 2 sekund od przepływu.

Uzbrojeni w psychologię radzenia sobie z niepowodzeniem w optymistycznym interfejsie użytkownika, przejdźmy w końcu do tych 1 do 3% nieudanych żądań.

Pesymistyczna strona optymistycznego projektowania interfejsu użytkownika

Zdecydowanie najczęstszą uwagą, jaką słyszę, jest to, że optymistyczny projekt interfejsu użytkownika jest rodzajem czarnego wzoru — oszukiwanie, jeśli wolisz. Oznacza to, że stosując go, okłamujemy naszych użytkowników w sprawie wyniku ich interakcji. Prawnie każdy sąd prawdopodobnie poparłby ten punkt. Mimo to uważam tę technikę za przepowiednię lub nadzieję. (Pamiętasz definicję „optymizmu”? Tutaj zostawiamy trochę miejsca na „pełną nadziei” część tego.) Różnica między „kłamstwem” a „przewidywaniem” polega na tym, jak traktujesz te od 1 do 3% nieudanych żądań. Przyjrzyjmy się, jak optymistyczny przycisk „Lubię to” na Twitterze zachowuje się w trybie offline.

Po pierwsze, zgodnie z optymistycznym wzorcem interfejsu użytkownika, przycisk przełącza się w stan powodzenia zaraz po kliknięciu — ponownie, bez dłuższego naciskania przez użytkownika lub najeżdżania na niego kursorem, dokładnie tak, jak przycisk zachowuje się, gdy użytkownik jest online.

Ale ponieważ użytkownik jest w trybie offline, żądanie kończy się niepowodzeniem.

Tak więc, jak najszybciej w ramach przepływu użytkownika, awaria powinna być zakomunikowana. Ponownie, 2 sekundy to zwykle czas trwania takiego przepływu. Twitter komunikuje to w możliwie najsubtelniejszy sposób, po prostu przywracając stan przycisku.

Sumienny czytelnik mógłby tu powiedzieć, że tę obsługę awarii można posunąć o krok dalej, faktycznie powiadamiając użytkownika, że ​​żądanie nie może zostać wysłane lub że wystąpił błąd. Dzięki temu system byłby jak najbardziej przejrzysty. Ale jest pewien haczyk — a raczej seria problemów:

• Każde powiadomienie, które pojawia się nagle na ekranie, zmienia kontekst użytkownika, zachęcając go do przeanalizowania przyczyny niepowodzenia, która prawdopodobnie zostałaby przedstawiona w komunikacie o błędzie.
• Podobnie jak w przypadku każdego komunikatu o błędzie lub powiadomienia, ten powinien wprowadzić użytkownika w nowy kontekst, dostarczając przydatnych informacji.
• Te praktyczne informacje nadałyby jeszcze inny kontekst.

OK, teraz wszyscy możemy się zgodzić, że to się trochę komplikuje. Chociaż taka obsługa błędów byłaby rozsądna w przypadku, powiedzmy, dużego formularza na stronie internetowej, w przypadku czynności tak prostej, jak kliknięcie przycisku Lubię to, jest to przesada — zarówno pod względem wymaganego rozwoju technicznego, jak i pamięci roboczej użytkowników.

Więc tak, powinniśmy być otwarci na porażkę w optymistycznym interfejsie użytkownika i powinniśmy to jak najszybciej zakomunikować, aby nasz optymizm nie stał się kłamstwem. Ale powinno być proporcjonalne do kontekstu. W przypadku nieudanego polubienia powinno wystarczyć subtelne przywrócenie przycisku do pierwotnego stanu — to znaczy, chyba że użytkownik lubi status swojej znaczącej drugiej osoby, w którym to przypadku sprawa lepiej działa przez cały czas.

Ekstremalny pesymizm

Może pojawić się jeszcze jedno pytanie: co się stanie, jeśli użytkownik zamknie kartę przeglądarki zaraz po otrzymaniu wskaźnika sukcesu, ale przed zwróceniem odpowiedzi z serwera? Najbardziej nieprzyjemny byłby przypadek, gdyby użytkownik zamknął zakładkę jeszcze przed wysłaniem żądania do serwera. Ale jeśli użytkownik nie jest wyjątkowo zwinny lub nie potrafi spowolnić czasu, jest to prawie niemożliwe.

Jeśli optymistyczny interfejs użytkownika jest prawidłowo zaimplementowany, a interakcje są stosowane tylko do tych elementów, które nigdy nie czekają na odpowiedź serwera dłużej niż 2 sekundy, użytkownik musiałby zamknąć kartę przeglądarki w tym 2-sekundowym oknie. Nie jest to szczególnie trudne z naciśnięciem klawisza; jednak, jak widzieliśmy, w 97 do 99% przypadków żądanie zakończy się powodzeniem, niezależnie od tego, czy zakładka jest aktywna, czy nie (po prostu odpowiedź nie zostanie zwrócona klientowi).

Tak więc ten problem może pojawić się tylko dla tych 1 do 3%, które dostaną błąd serwera. Z drugiej strony, ilu z nich spieszy się, aby zamknąć kartę w ciągu 2 sekund? O ile nie biorą udziału w konkursie szybkości zamykania kart, nie sądzę, aby liczba ta była znacząca. Ale jeśli uważasz, że jest to istotne dla twojego konkretnego projektu i może mieć negatywne konsekwencje, użyj narzędzi do analizy zachowania użytkownika; jeśli prawdopodobieństwo takiego scenariusza jest wystarczająco wysokie, ogranicz optymistyczne interakcje do elementów niekrytycznych.

Celowo nie wspomniałem o przypadkach, w których wniosek jest sztucznie opóźniany; generalnie nie mieszczą się one pod parasolem optymistycznego projektowania interfejsu użytkownika. Co więcej, spędziliśmy więcej niż wystarczająco czasu na pesymistycznej stronie rzeczy, więc podsumujmy kilka głównych punktów dotyczących implementacji dobrego, optymistycznego interfejsu użytkownika.

Reguły kciuka

Mam szczerą nadzieję, że ten artykuł pomógł ci zrozumieć niektóre z głównych koncepcji optymistycznego projektowania interfejsu użytkownika. Być może jesteś zainteresowany wypróbowaniem tego podejścia w swoim następnym projekcie. Jeśli tak, przed rozpoczęciem należy pamiętać o kilku rzeczach:

• Warunek wstępny wszystkiego, o czym mówiliśmy do tej pory: upewnij się, że interfejs API, na którym polegasz, jest stabilny i zwraca przewidywalne wyniki. Wystarczająco powiedziane.
• Interfejs powinien wykrywać potencjalne błędy i problemy przed wysłaniem żądania do serwera. Co więcej, całkowicie wyeliminuj wszystko, co może spowodować błąd w interfejsie API. Im prostszy element interfejsu użytkownika, tym prostsze będzie nadanie mu optymizmu.
• Zastosuj optymistyczne wzorce do prostych elementów binarnych, dla których nie oczekuje się niczego więcej niż odpowiedzi na sukces lub niepowodzenie. Na przykład, jeśli kliknięcie przycisku zakłada odpowiedź serwera, taką jak „tak”, „nie” lub „może” (z których wszystkie mogą oznaczać sukces w różnym stopniu), taki przycisk byłby lepszy bez optymistycznego wzorca.
• Poznaj czasy odpowiedzi swojego interfejsu API. To jest kluczowe. Jeśli wiesz, że czas odpowiedzi na konkretne żądanie nigdy nie schodzi poniżej 2 sekund, prawdopodobnie najlepiej będzie najpierw rzucić trochę optymizmu na swoje API. Jak wspomniano, optymistyczny interfejs użytkownika działa najlepiej, gdy czas odpowiedzi serwera jest krótszy niż 2 sekundy. Wykroczenie poza to może prowadzić do nieoczekiwanych rezultatów i wielu sfrustrowanych użytkowników. Uważaj się za ostrzeżony.
• Optymistyczny interfejs użytkownika to nie tylko kliknięcia przycisków. Podejście to można zastosować do różnych interakcji i zdarzeń w cyklu życia strony, w tym do ładowania strony. Na przykład ekrany szkieletowe są zgodne z tą samą ideą: przewidujesz, że serwer zareaguje pomyślnie, aby wypełnić symbole zastępcze, aby jak najszybciej pokazać je użytkownikowi.

Optymistyczne projektowanie interfejsu użytkownika nie jest tak naprawdę nowością w sieci, ani nie jest to szczególnie zaawansowana technika, jak widzieliśmy. To po prostu inne podejście, kolejny model mentalny, który pomoże Ci zarządzać postrzeganą wydajnością Twojego produktu. Opierając się na psychologicznych aspektach interakcji człowiek-komputer, optymistyczny projekt interfejsu użytkownika, jeśli jest używany inteligentnie, może pomóc w tworzeniu lepszych, bardziej płynnych doświadczeń w Internecie, przy bardzo niewielkich wymaganiach do wdrożenia. Aby jednak uczynić ten wzór naprawdę skutecznym i aby nasze produkty nie okłamywały użytkowników, musimy zrozumieć mechanikę optymistycznego projektowania interfejsu użytkownika.

Zasoby

• „Czas reakcji w rozmowach między człowiekiem a komputerem” (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968
• „Przedstawiamy RAIL: model wydajności zorientowany na użytkownika”, Paul Irish, Paul Lewis, Smashing Magazine, 2015
• „Stres w sieci mobilnej: wpływ szybkości sieci na zaangażowanie emocjonalne i postrzeganie marki”, Tammy Everts, Radware Blog, 2013
• Zastosowania przepływu w rozwoju człowieka i edukacji , Mihaly Csikszentmihalyi, 2014
• „Szczegóły projektu mobilnego: unikaj spinnera”, Luke Wróblewski, 2013
• „Dlaczego wydajność ma znaczenie, część 2: Zarządzanie percepcją”, Denys Mishunov, Smashing Magazine, 2015