Bez zasięgu też można pracować. Co strona zapisuje, a co naprawdę wysyła?

W hali wystawienniczej działa oświetlenie, ekspres i sześć rozmów naraz. Zasięg najwyraźniej poszedł obejrzeć inne stoisko. Osoba sprawdzająca wyposażenie naciska „Zapisz” i widzi zielone potwierdzenie. Godzinę później biuro nadal nie ma informacji o uszkodzonym panelu. Czy zapis się nie udał, czy udało się coś innego, niż obiecywał ekran?

W aplikacji działającej bez sieci zapis na urządzeniu jest użytecznym rezultatem. Człowiek może kontynuować oględziny, dopisać uwagę i zrobić zdjęcie. Problem zaczyna się wtedy, gdy ten rezultat wygląda tak samo jak potwierdzenie przyjęcia danych przez firmę. Potrzebny jest projekt całej drogi zmiany: od lokalnej czynności do rozstrzygnięcia jej po powrocie połączenia.

Prześledźmy to w fikcyjnej firmie wypożyczającej wyposażenie wystaw. Techniczka Ola obchodzi stanowiska z telefonem. Zaznacza sprawdzone elementy, opisuje uszkodzenie i dołącza fotografię. Biuro na innym urządzeniu planuje następne wydania. Obserwacje z telefonu mają więc trafić do wspólnego obiegu, w którym w tym samym czasie pracuje ktoś inny.

Przygotowanie do wyjścia jest częścią pracy

Ola potrzebuje przed obchodem listy elementów z właściwego wydarzenia, ich oznaczeń i ostatnio potwierdzonego stanu. Sama strona startowa zapamiętana przez przeglądarkę nie daje jej tego zestawu. Projekt powinien pokazać, które materiały są już dostępne na telefonie, a które dopiero czekają na pobranie. Lista stu pozycji nie pomoże, jeżeli szczegóły każdej otwierają pusty ekran bez sieci.

Przygotowanie pakietu także może zostać przerwane. Załóżmy, że telefon zdążył zapisać dane dwunastu elementów, ale nie pobrał instrukcji do pozostałych. Po ponownym otwarciu pokaż dostępny zakres i możliwość dokończenia przygotowania. Samo uruchomienie aplikacji nie jest jeszcze zakończeniem tego etapu. Ola powinna móc rozpocząć obchód gotowej części albo wrócić po resztę materiałów, wiedząc, których stanowisk jeszcze nie obejmie. Numer wydarzenia i lista braków pomagają podjąć tę decyzję bez przeglądania każdego elementu osobno.

Zacznij od rozdzielenia czynności. Odczyt wcześniejszej instrukcji, zapis uwagi i potwierdzenie wydania sprzętu mogą wymagać innego poziomu aktualności. W naszym przykładzie oględziny dają się zapisać roboczo. Obietnica dostępności panelu dla innego wydarzenia wymaga już odniesienia do bieżącego stanu firmy. Jedna etykieta „tryb offline” nie wyjaśnia tych różnic.

MDN opisuje Background Synchronization API jako mechanizm odraczania synchronizacji do odzyskania połączenia. Dokumentacja oznacza jego dostępność jako ograniczoną i wymaga bezpiecznego kontekstu, czyli HTTPS.

Przy wysyłaniu automatycznym Ola potrzebuje miejsca do sprawdzenia przyjęcia danych. Przy wysyłaniu ręcznym — widocznego działania kończącego obchód. Techniczna nazwa mechanizmu może pozostać w dokumentacji wykonawcy. Ekran ma wyjaśnić, co użytkowniczka może zrobić teraz i co stanie się z oczekującym materiałem.

Przed wyjściem na halę aplikacja może podsumować: „Na tym telefonie dostępna jest lista wyposażenia wydarzenia Jesień. Ostatnie dane z 8:40”. Taki komunikat powinien dotyczyć rzeczywiście przygotowanego zestawu. Jeśli zdjęcia referencyjne nie zostały pobrane, warto wskazać ten brak przy ich roli, zamiast obiecywać gotowość całej aplikacji.

To odmienna potrzeba niż zapis formularza na kilka podejść. Tam człowiek odkłada uzupełnienie materiałów. Tutaj pracuje dalej i tworzy kolejne zmiany, choć wspólny stan firmy jest chwilowo poza zasięgiem. Interfejs musi pozwolić ocenić zarówno własną pracę, jak i aktualność informacji, na której się opiera.

Miejsce zapisu powinno być widoczne

Ola dopisuje „pęknięty narożnik” przy panelu P-18. Telefon zachowuje uwagę i pokazuje ją na liście. W biurze panel nadal ma wcześniejszy stan. Obie osoby mogą patrzeć na poprawny zapis swojego urządzenia, lecz dotyczy on innego momentu i innego miejsca. Przy lokalnej zmianie potrzebna jest więc informacja o jej zasięgu: „Zapisano na tym telefonie. Zmiana czeka na wysłanie”.

Licznik oczekujących zmian pomaga, jeżeli prowadzi do konkretnych pozycji. „Oczekują 4 zmiany” powinno dać się rozwinąć do uwagi o panelu, dwóch potwierdzeń przeglądu i fotografii. Po zakończeniu obchodu Ola nie musi pamiętać, które działanie wykonała przed utratą sieci. Ma je rozpoznać w aplikacji.

Fotografia potrzebuje własnego stanu. Lokalnie zachowana uwaga nie dowodzi, że zachowano również plik, a wysłany opis nie potwierdza transferu zdjęcia. W widoku panelu można pokazać oba elementy blisko siebie, z różnym potwierdzeniem. Wtedy biuro rozpozna później, czy dostało sam opis uszkodzenia, czy kompletny materiał do decyzji.

Rozstrzygnij też znaczenie kolejnych poprawek jednej uwagi. Ola najpierw wpisuje „pęknięcie”, a po bliższych oględzinach zmienia tekst na „rysa na folii ochronnej”. Jeżeli celem jest przekazanie aktualnej obserwacji, podsumowanie ma pokazać poprawiony opis. Jeżeli firma potrzebuje również historii zmian, powinna być oddzielona od treści bieżącej. Licznik dwóch operacji nie może sugerować dwóch uszkodzonych paneli. Jednostka liczenia musi odpowiadać temu, co biuro później odbierze.

MDN rozróżnia przechowywanie danych przeglądarki typu best-effort (domyślne) i persistent (trwałe). Dane pierwszego rodzaju mogą zostać usunięte przez przeglądarkę; użytkownik może też sam wyczyścić zapisane dane.

Przy lokalnym zapisie pokaż urządzenie oraz drogę wysłania materiału. Gdy brakuje miejsca na fotografię, użytkownik powinien dostać informację przy tej fotografii, z możliwością ograniczenia materiału lub wybrania innej drogi. Ogólny komunikat o całym obchodzie ukryłby, że pozostałe notatki są już zachowane.

Instalacja strony może ułatwiać powrót do narzędzia, ale sama ikona nie rozstrzyga trwałości danych. Propozycję instalacji PWA warto oceniać osobno od gotowości do pracy bez połączenia. Ola powinna sprawdzić przygotowany zestaw niezależnie od tego, czy otworzyła serwis z ikony, zakładki czy wiadomości.

Połączenie wróciło, potwierdzenie jeszcze nie

W połowie korytarza pojawia się Wi-Fi. To dobry moment na próbę kontaktu z serwerem, ale jeszcze nie dowód przyjęcia wszystkich zmian. Widok „Online” oraz cztery nadal oczekujące pozycje mogą być prawidłowe. Błędny projekt schowa licznik natychmiast po zmianie symbolu sieci i odbierze użytkownikowi możliwość rozpoznania nieprzekazanego materiału.

Dokumentacja navigator.onLine wyjaśnia, że połączenie z siecią lokalną może dawać stan online mimo braku dostępu do internetu. Sam wskaźnik nie potwierdza dostępności waszego serwisu.

Na liście zmian pokaż wynik kolejnych prób. Uwaga może już być przyjęta, zdjęcie nadal się przesyłać, a potwierdzenie jednego elementu wymagać decyzji. Zbiorcze „Synchronizacja zakończona” powinno odpowiadać uzgodnionej definicji zakończenia. Jeżeli dotyczy tylko transferu, nie może udawać rozstrzygnięcia konfliktu z danymi biura.

Szczególnie przydatna jest próba z utraconym potwierdzeniem. Uwaga dociera do biura, ale telefon nie odbiera odpowiedzi przed kolejnym zerwaniem połączenia. Ola nadal widzi stan oczekiwania. Komunikat „nie wysłano” przesądzałby coś, czego aplikacja jeszcze nie wie. Bez połączenia pokaż: „Brak potwierdzenia. Sprawdzimy po odzyskaniu połączenia”. Etykieta „Sprawdzamy przyjęcie uwagi” pasuje dopiero do rzeczywiście rozpoczętego odczytu statusu po powrocie kontaktu. Oba stany dotyczą tej samej pozycji. Po uzyskaniu wyniku użytkownik ma rozpoznać przyjęcie uwagi albo potrzebny dalszy krok, zamiast wpisywać uszkodzenie od początku.

Po stronie biura ta sama uwaga może już służyć do działania. Dlatego w scenariuszu odbiorczym warto zestawić obie perspektywy: telefon bez potwierdzenia i przyjęty zapis. Różnica jest chwilowa i wyjaśnialna. Błędem byłoby dopiero utworzenie drugiej sprawy albo usunięcie istniejącej tylko po to, by oba ekrany wyglądały równie czysto.

MDN wskazuje, że przeglądarka może zatrzymać service workera, czyli mechanizm obsługujący część działań w tle. Taki mechanizm nie jest stale działającym procesem pod kontrolą użytkownika.

Dlatego w naszym projekcie Ola ma miejsce, do którego wróci po obchodzie i zobaczy potwierdzony stan każdej zmiany. Nie musi stać z odblokowanym telefonem pod routerem. Jeśli rozwiązanie wymaga ponownego otwarcia aplikacji, ta czynność powinna być opisana jako część zakończenia pracy, a nie odkrywana po braku materiału w biurze.

Ręczne „Spróbuj wysłać ponownie” powinno odnosić się do tej samej uwagi. Człowiek chce przekazać znaną zmianę, nie utworzyć drugie zgłoszenie uszkodzenia. Projekt widoku i techniczna obsługa ponowień bez duplikatów spotykają się w jednym miejscu: rozpoznawalnej pozycji z aktualnym wynikiem.

Jeżeli użytkownik usuwa oczekującą uwagę, trzeba nazwać to inaczej niż zamknięcie panelu. Może także zmienić opis przed wysłaniem. Na liście powinna pozostać ostatnia zamierzona treść, a po rozpoczęciu kontaktu z serwerem wynik wymaga potwierdzenia. Zniknięcie wiersza z ekranu samo nie wycofuje danych, które zdążyły dotrzeć dalej.

W biurze zdążono już zmienić ten sam panel

Podczas obchodu biuro wyłączyło P-18 z kolejnego wydania. Ola ma na telefonie wcześniejszy stan i dopisuje uszkodzenie. System może przyjąć nową uwagę jako dodatkową obserwację, ale nie powinien przez przypadek przywrócić starej dostępności panelu. Projekt może przyjąć fotografię niezależnie od decyzji o dalszej dostępności elementu. Znaczenie zmiany jest ważniejsze niż ogólna kolejność zapisywania całego rekordu.

Rozbij roboczy zapis na to, co użytkownik rzeczywiście zamierza zmienić. Dopisanie fotografii, potwierdzenie oględzin i zmiana statusu mają inne relacje z równoległą pracą. Jeśli projekt pokazuje tylko ogólne „Zapisz element”, odbiorca nie wie, czy zmienia jedną uwagę, czy cały zestaw danych widocznych przed wyjściem.

Dla rozbieżności potrzebny jest widok decyzji: czego dotyczy własna zmiana, jaki stan potwierdzono w biurze i co można zachować. Komunikacja konfliktu edycji pomaga zaplanować porównanie. Przy pracy offline dochodzi jednak możliwość wielu godzin zaległości i kilku zmian, które wcale nie są ze sobą sprzeczne.

Ola może zakończyć obchód, choć dwie pozycje czekają na rozstrzygnięcie przez osobę z biura. Podsumowanie powinno pokazać ten stan wprost. Zablokowanie całego zadania do czasu odpowiedzi zmuszałoby ją do pilnowania telefonu, mimo że dalsza decyzja nie należy już do niej. Z kolei pełny sukces ukryłby pracę, której ktoś musi się podjąć.

Przy telefonie współdzielonym między zmianami dochodzi jeszcze pytanie o właściciela oczekującego materiału. Projekt wspólnego terminala wymaga oddzielenia kolejnych osób. W narzędziu terenowym wylogowanie nie powinno pozostawiać drugiej osobie cudzych notatek ani bez wyjaśnienia usuwać jedynej kopii niewysłanego przeglądu. Przed przekazaniem telefonu kolejnej osobie pokaż, czy pozostał na nim materiał wymagający działania.

Odbierz obchód z innej perspektywy niż projektant

Do próby przygotuj krótki, fikcyjny zestaw wyposażenia i wcześniej ustal oczekiwany wynik. Jedna osoba wykonuje obchód, druga pracuje w biurze. Po przygotowaniu listy odłącz połączenie na telefonie. Osoba w terenie dopisuje uwagę i zdjęcie, zamyka aplikację, otwiera ją ponownie i wskazuje, co ma zapisane. Nie podawaj nazw stanów, które powinna znaleźć; poproś o opis sytuacji własnymi słowami.

Następnie przywróć dostęp i porównaj widok telefonu z tym, co naprawdę pojawiło się po stronie biura. Część próby powinna obejmować nieudany transfer fotografii oraz równoległą zmianę jednego elementu. Powodzenie oznacza rozpoznawalny, zgodny z uzgodnionymi regułami rezultat każdej pozycji. Sam zanik paska ostrzegawczego jest za słabym kryterium.

Osobny przebieg powinien obejmować utratę dostępu do konta podczas obchodu. Po ponownym logowaniu Ola ma rozpoznać własny oczekujący materiał oraz właściwe wydarzenie. Jeżeli konto lub organizacja zmieniły się, aplikacja musi ujawnić tę różnicę przed wysłaniem. Sposób powrotu po wygaśnięciu sesji trzeba tu połączyć z lokalną kolejką. Materiał z poprzedniej pracy nie powinien trafić do nowego kontekstu tylko dlatego, że użytkownik odzyskał dostęp do samego serwisu.

Własny ślad pracy powinien być czytelny również następnego dnia. Nazwa wydarzenia, czas ostatniego potwierdzenia i lista nierozstrzygniętych pozycji pozwalają wrócić do właściwego obchodu. To nie wymaga pokazywania całego technicznego dziennika. Potrzebne są informacje, które odróżniają wczorajszy niewysłany materiał od dzisiejszego gotowego zadania.

Wytyczne projektowania offline w web.dev zalecają wyjaśniać dostępne czynności oraz pokazywać stan kilkoma środkami. Sam kolor lub techniczne słowo „offline” może nie przekazać użytkownikowi wystarczającej informacji.

W projekcie Aeneia Design warto zacząć od takiego przebiegu, z materiałami i rolami z waszej pracy. Ekrany pokażą wtedy konkretną różnicę między zachowaniem obserwacji na telefonie a przekazaniem jej do wspólnego obiegu. Ola może zejść do następnej hali, a biuro wie, czy czeka na zdjęcie, decyzję czy dopiero pierwszą informację. Każda strona widzi własny następny krok, bez konieczności szukania miejsca z jedną kreską więcej.