To jeszcze pracuje: postęp, przerwanie i powrót do długiego zadania

Paczka materiałów jest gotowa w 97 procentach. Przez następne kilka minut nic się nie zmienia. Użytkownik zdążył przeczytać nazwę każdego pliku, sprawdzić pocztę i nabrać osobistego stosunku do pozostałych trzech procent. Nie wie jednak, czy może zamknąć kartę i wrócić później.

Przy długim zadaniu informacja o postępie ma pomagać podjąć decyzję: czekać, zająć się czymś innym, zatrzymać pracę albo odebrać rezultat. Ruchomy wskaźnik to tylko jeden element. Projekt musi wyjaśniać stan zadania oraz dostępne działania, także po utracie połączenia i powrocie do serwisu.

W fikcyjnym panelu pracowni Barwa klient wybiera materiały do większej paczki. Serwis przygotowuje archiwum z rysunkami i zdjęciami. Wynik nie pojawia się od razu, a jego przygotowanie może trwać dłużej niż pobyt człowieka na stronie. Ułóżmy tę drogę od zlecenia do odzyskania pliku, bez zgadywania, co robi zaplecze.

Stan zadania ma prowadzić do decyzji

Najpierw ustal, co znaczy przyjęcie prośby. Kliknięcie przycisku nie musi oznaczać, że zadanie zostało zapisane i trafiło do wykonania. Ekran powinien rozróżniać wysyłanie żądania, potwierdzone przyjęcie i rozpoczętą pracę, jeżeli między tymi momentami istnieje odczuwalna różnica. Treść musi odpowiadać sygnałom rzeczywiście dostępnym w systemie.

W Barwie widok zadania powinien pokazywać, czego dotyczy paczka, kiedy ją zlecono i gdzie sprawdzić wynik. Sam napis „przetwarzanie” nie pomoże po powrocie, gdy użytkownik uruchomił dwa różne zadania. Nazwa oraz zakres materiału pozwalają wybrać właściwe bez otwierania każdej pozycji.

Uzgodnij, czy paczka obejmuje wybór z chwili zlecenia, czy aktualną zawartość listy. Klient może w międzyczasie usunąć zdjęcie albo dodać nowy rysunek. W widoku zadania pokaż zakres, który rzeczywiście jest przygotowywany, oraz ewentualną drogę utworzenia kolejnej paczki. Bez tego zmieniona lista i wcześniejsze zadanie będą wyglądać jak dwa widoki tego samego stanu, choć zawierają inne materiały.

Rozdziel oczekiwanie na rozpoczęcie od wykonywania. Jeżeli zadanie czeka w kolejce, nie pokazuj, że archiwum już powstaje. Z kolei chwilowy brak aktualizacji nie dowodzi zatrzymania. Pokaż stan potwierdzony przez serwis, a przy braku aktualizacji pozwól ponownie sprawdzić informację.

Wskaż również zakończenia inne niż pełen sukces: przerwanie na prośbę, błąd oraz gotowy wynik z brakującym materiałem. Użytkownik podejmuje wobec nich inne decyzje. Jeden czerwony komunikat „Nie udało się” nie wyjaśni, czy powinien wybrać inne pliki, spróbować później czy odebrać część paczki.

Jeżeli wynik jest częściowy, pokaż dostępne i pominięte pozycje wraz z przyczyną wymagającą reakcji. „Brakuje dwóch rysunków” powinno prowadzić do ich rozpoznania. Ustal, czy użytkownik może odebrać niepełną paczkę i co oznacza ponowienie: tylko brakujące pliki czy nowe przygotowanie całości. Nazwy przycisków powinny zachować tę różnicę. W przeciwnym razie człowiek ponowi zadanie, a potem nie rozpozna, który z dwóch wyników ma przekazać dalej.

Przygotowanie archiwum i jego pobranie na urządzenie to dwa etapy. „Gotowe do pobrania” potwierdza pierwszy. Nie mów jeszcze „Plik zapisany”, jeśli człowiek dopiero zobaczył przycisk. Podobne rozróżnienie między przyjęciem a rezultatem opisuje strona po wysłaniu formularza. Przy długim zadaniu trwa ono przez całą drogę do wyniku.

Liczba ma opisywać coś policzonego

Carbon w wytycznych paska postępu rozróżnia postęp obliczalny względem celu i wskaźnik nieokreślony, używany bez znanego postępu lub czasu zakończenia. Ten drugi sygnalizuje trwające przetwarzanie, nie podaje procentu. To rozróżnienie pomaga dobrać prezentację do dostępnej informacji.

Przed narysowaniem paska ustal, co jest mianownikiem. Liczba przygotowanych plików, przesłane bajty i wykonane etapy nie muszą opisywać tego samego udziału w całej pracy. Dziewięć małych zdjęć i jeden duży model mogą dawać dziewięć z dziesięciu plików, lecz nie dziewięć dziesiątych czasu. Nazwij to, co liczysz.

Jeżeli pokazujesz „Przygotowano 9 z 10 plików”, użytkownik otrzymuje konkretną informację. Nie dopisuj do niej automatycznie „Pozostało kilka sekund”. Oszacowanie czasu wymaga osobnej podstawy i może się zmieniać. Jeżeli system nie ma wiarygodnej prognozy, lepiej wskazać aktualny etap i sposób powrotu niż utrzymywać pozornie precyzyjny zegar.

Przy kilku etapach można pokazać, które zakończono, który trwa i co nastąpi później. Nie dziel paska na równe części tylko dlatego, że są trzy nazwy. Przygotowanie materiałów może zająć znacznie dłużej niż zapisanie odnośnika do gotowego archiwum. Proporcja wizualna nie powinna udawać pomiaru czasu.

Ruchomy wskaźnik połącz z nazwą czynności. „Przygotowujemy wybrane rysunki i zdjęcia” mówi więcej niż samo kółko. Gdy zmienia się etap, pokaż nową informację w miejscu, w którym człowiek jej szuka. Nie każ śledzić kilku oddzielnych animacji, żeby rozpoznać stan jednej paczki. Jeśli dalszy krok wymaga decyzji człowieka, nazwij ją i pokaż dostępne działanie. Napis „Wybierz brakujący wariant” opisuje inną sytuację niż „Przygotowanie trwa”. Wskaźnik nie powinien sugerować samodzielnej pracy systemu wtedy, gdy proces czeka na uzupełnienie po stronie użytkownika.

O sygnałach krótkich zmian piszemy przy mikrointerakcjach na stronie. Tutaj dochodzi czas na odejście od ekranu. Użytkownik nie powinien przez kilka minut pilnować animacji tylko po to, by nie przegapić jednosekundowego potwierdzenia zakończenia.

Komunikat musi być dostępny także bez obserwowania ekranu. Objaśnienie WAI dotyczące komunikatów statusu opisuje ich udostępnianie technologiom asystującym bez przenoszenia na nie fokusu, czyli bieżącego miejsca obsługi klawiaturą. Wskazuje też ryzyko nadmiarowych ogłoszeń. Zmiana stanu ma informować, a nie zagłuszać wykonywane zadanie.

W projekcie ustal, które momenty wymagają powiadomienia i jaka informacja pozwoli je zrozumieć. Samo odczytanie „dziewięć” może nie wyjaśnić, że chodzi o dziewięć przygotowanych plików. Odbierz komunikaty wraz z ich kontekstem i częstotliwością. Wykonaj próbę odpowiednimi narzędziami, zamiast wnioskować o rezultacie po samym wyglądzie paska.

Wyjście z widoku i anulowanie to odrębne czynności

Przed opuszczeniem strony człowiek powinien wiedzieć, co stanie się z zadaniem. Jeżeli wykonuje się ono dalej niezależnie od otwartej karty, wskaż miejsce powrotu. Jeśli zamknięcie strony rzeczywiście przerywa pracę w używanym rozwiązaniu, wyjaśnij skutek przed wyjściem. Nie próbuj rozstrzygnąć tego samym doborem słowa na przycisku.

Etykieta „Zamknij” nie mówi, czy zamyka okno postępu, czy zatrzymuje przygotowanie. Jeżeli dostępne są obie czynności, nazwij je przez skutek, na przykład „Wróć do materiałów” oraz „Anuluj przygotowanie paczki”. Odbiorca ma móc odejść od widoku bez przypadkowego zlecenia innej operacji.

Dla anulowania ustal, czy system potwierdza od razu zatrzymanie, czy najpierw przyjęcie prośby. Jeżeli zadanie jeszcze kończy bieżący krok, status powinien zachować tę różnicę. Natychmiastowy napis „Anulowano” jest mylący, gdy proces nadal może utworzyć wynik. Zespół projektujący potrzebuje uzgodnienia zachowania z osobami odpowiedzialnymi za wykonanie.

Pomyśl też o chwili, w której wynik zdążył już powstać. Prośba o anulowanie może dotrzeć po zakończeniu zadania. Ekran powinien pokazać potwierdzony stan i dostępne działania, zamiast przyjąć każdą intencję za spełnioną. Gotowy plik można usunąć lub pozostawić według ustalonej reguły; to inna czynność niż zatrzymanie obliczeń.

Powrót po przerwie rozwija również tekst o formularzu na kilka podejść z zapisem pracy. Przy paczce nie odtwarzasz jednak samej zawartości pól. Odszukujesz zadanie i jego bieżący rezultat. Wybór materiałów zapisany w formularzu nie jest dowodem zakończenia przygotowania.

Przy przesyłaniu własnych plików zachowaj jeszcze granicę między transferem a dalszym przetwarzaniem. Załączniki w formularzu wymagają czytelnego postępu i reakcji na błąd. Komunikat „Przesłano” nie powinien jednocześnie obiecywać, że zakończono całą pracę nad wynikiem. Jeśli są to dwa etapy, pokaż oba.

Po powrocie pokaż zadanie, a nie nowy początek

W Barwie człowiek wraca do listy przygotowanych paczek. Przy każdej widzi nazwę, czas zlecenia i aktualny status. Wybiera tę dotyczącą właściwego zestawu materiałów. Jeżeli projekt przewiduje odnośnik w wiadomości, sprawdź tę drogę osobno: odbiorca może otworzyć go na innym urządzeniu albo po wygaśnięciu sesji.

Po zalogowaniu zachowaj rozpoznawalny cel powrotu. Nie kieruj człowieka automatycznie do pustego wyboru plików, jeśli przyszedł odebrać istniejący wynik. Jeżeli system wymaga ponownego logowania, po jego zakończeniu pokaż właściwe zadanie i jego stan. Sprawdź tę drogę od otwarcia wiadomości do widoku wyniku.

Gdy statusu nie udało się pobrać, nazwij problem z odczytem. Nie przedstawiaj go od razu jako niepowodzenia całego zadania. Wynik mógł powstać, choć ekran go nie potwierdził. Przyciskiem ponowienia nie uruchamiaj bez wyjaśnienia nowej paczki, jeśli człowiek chciał jedynie odświeżyć informację o poprzedniej.

Zachowaj też czas ostatniego potwierdzenia, jeżeli ekran nadal pokazuje poprzedni stan. Informacja „Przygotowanie trwa” sprzed kilku minut nie jest bieżącym odczytem po utracie połączenia. Pokaż ostatni znany stan z czasem potwierdzenia i możliwością ponownego sprawdzenia. Nie cofaj przy tym paska do zera tylko dlatego, że interfejs przestał otrzymywać aktualizacje. Taki skok sugerowałby nowy początek, którego system nie potwierdził.

Przy wielu plikach dopilnuj ich związku z zadaniem. Powiązanie wyników wsadowych z rekordami pokazuje ten problem w procesie AI. W interfejsie użytkownik potrzebuje prostego potwierdzenia, że pobiera materiały z wybranego zlecenia, a nie ostatni plik wygenerowany dla całego konta.

Jeśli paczka wygasa, pokaż ten warunek przy wyniku i w drodze powrotu. Po terminie wyjaśnij, co można zrobić: przygotować ją ponownie z aktualnych materiałów albo skorzystać z innej dostępnej ścieżki. Nowa paczka może już zawierać inne wersje plików. Nie przedstawiaj jej jako odzyskania identycznego archiwum bez sprawdzenia zawartości.

Przy gotowym przycisku podaj nazwę pliku, format i wielkość, jeżeli pomagają podjąć decyzję o pobraniu. Wskaż również zakres paczki i czas jej przygotowania. Dwie podobnie nazwane listy z różnych dni nie powinny wyglądać identycznie. Po zapisaniu na urządzeniu sam plik powinien pozostać rozpoznawalny bez ponownego otwierania panelu.

Przed oddaniem projektu przejdź kilka rzeczywistych dróg w kontrolowanej wersji serwisu: przyjęcie, długie oczekiwanie, wyjście, powrót i brak dostępu do statusu. Sprawdź również anulowanie przed zakończeniem oraz prośbę przychodzącą po utworzeniu wyniku. To proponowany zakres próby, nie deklaracja testu wykonanego w tym artykule.

W jednej z prób otwórz to samo zadanie w dwóch kartach. W pierwszej poproś o anulowanie, w drugiej odśwież stan i sprawdź dostępny przycisk pobrania. Chodzi o zgodność widoków wobec jednego zadania, nie o tworzenie dwóch niezależnych zleceń. Zanotuj również zachowanie po ponownym kliknięciu przycisku przygotowania. Użytkownik powinien rozpoznać, czy wraca do istniejącej paczki, czy świadomie zleca następną.

W ofercie Aeneia Design ekran oczekiwania jest częścią całej drogi użytkownika. Przygotowana paczka ma być możliwa do odnalezienia i odebrania bez domyślania się znaczenia kółka. Wtedy człowiek może spokojnie zająć się czymś innym, zamiast osobiście pilnować trzech ostatnich procentów.