Zacząć na komputerze, dokończyć telefonem. Co ma przejść razem z użytkownikiem?

Opis usterki wygodnie wpisuje się na komputerze. Zdjęcie pękniętego zawiasu najłatwiej zrobić telefonem. Między tymi dwiema rozsądnymi czynnościami często pojawia się trzecia: wysłanie fotografii samemu sobie, odnalezienie jej w poczcie i pobranie na komputer. Człowiek zgłasza walizkę do naprawy, a przy okazji organizuje mały transport plików między własnymi kieszeniami.

Można zaprojektować krótszą drogę: przekazać telefonowi etap dodania zdjęcia do tej samej sprawy. Nie wystarczy jednak otworzyć na nim formularza od początku. Użytkownik powinien rozpoznać zgłoszenie, wykonać brakującą czynność i zobaczyć jej wynik po powrocie na komputer. To jeden proces obsługiwany przez dwa urządzenia.

W fikcyjnym portalu serwisu wyposażenia Jarek zgłasza walizkę na narzędzia. Na komputerze wskazał model i opisał problem. Brakuje fotografii zawiasu. Telefon ma dodać tę fotografię, a ostatnia decyzja o wysłaniu zgłoszenia pozostaje na komputerze. Ten podział jest celowy: nie przenosimy wszystkich funkcji tylko dlatego, że oba ekrany potrafią pokazać stronę.

Przekazujesz etap czy całe zadanie?

Najpierw ustal, co po przejściu ma robić pierwsze urządzenie. Może pozostać miejscem końcowego sprawdzenia, zostać zablokowane na czas edycji telefonu albo oddać zadanie w całości. Każda wersja wymaga innych komunikatów. Przy dodawaniu zdjęcia komputer może nadal pokazywać opis. Przy przeniesieniu całej edycji trzeba natomiast rozstrzygnąć, gdzie powstaje obowiązująca wersja.

Microsoft Teams odróżnia przeniesienie spotkania od dodania drugiego urządzenia. Po przeniesieniu pierwsze urządzenie opuszcza spotkanie; przy dodaniu oba pozostają w nim. To dwie jawnie różne czynności w jednym produkcie.

W naszym serwisie wybieramy model pomocniczego telefonu. Przycisk na komputerze może brzmieć „Dodaj zdjęcie telefonem”. Nie nazywaj go „Kontynuuj na telefonie”, jeśli odbiorca ma wrócić do komputera, aby zakończyć zgłoszenie. Użytkownik powinien znać zakres przejścia jeszcze przed sięgnięciem po drugie urządzenie.

Jeśli zgłoszenie od początku powstaje na telefonie, nie pokazuj kodu wymagającego zeskanowania z tego samego ekranu. Użytkownik powinien przejść bezpośrednio do dodania zdjęcia w bieżącym przebiegu. Na komputerze można natomiast pozostawić zwykłe wybranie gotowego pliku jako równorzędną drogę. Telefon jest ułatwieniem dla określonego etapu, a nie nowym obowiązkiem dla osoby, która już ma właściwą fotografię.

Drugim ustaleniem jest moment zapisu przygotowanej sprawy. Jarek musi mieć rozpoznawalny szkic, do którego trafi fotografia. Jeśli model i opis nadal istnieją wyłącznie w otwartej karcie komputera, samo pokazanie kodu nie tworzy trwałego związku. W projekcie określ, kiedy szkic otrzymuje potwierdzony zapis i co zrobić, gdy ten zapis się nie powiedzie.

Takie zachowanie szkicu łączy się z formularzem na kilka podejść, lecz ma dodatkowy warunek: dwa urządzenia są dostępne równocześnie. Nie chodzi tylko o wznowienie jutro. Komputer oczekuje wyniku etapu wykonywanego teraz na telefonie. Trzeba określić, skąd pozna przejęcie i zakończenie oraz co pokaże, gdy telefon nigdy się nie połączy.

Kod jest wejściem, nie potwierdzeniem przejęcia

Na komputerze pokaż cel, rozpoznawalny szkic i sposób przejścia. Obok kodu można napisać „Otwórz ten etap na telefonie, aby dodać zdjęcie zawiasu do szkicu 284”. Numer jest przykładowy. Jarek powinien wiedzieć, co zobaczy po otwarciu, a nie tylko otrzymać polecenie skierowania aparatu na kwadrat.

Zapewnij również drogę bez skanowania, jeśli odpowiada przyjętemu rozwiązaniu. Może to być odnośnik przesłany uzgodnionym kanałem albo ręczne otwarcie wskazanej strony i podanie przygotowanego kodu. Wybór musi uwzględniać sposób dostępu do sprawy. Nie należy sugerować, że każdy przepisany krótki numer samodzielnie uprawnia do oglądania dokumentów klienta.

Przy kodach QR na materiale drukowanym także zachowujemy obietnicę po drugiej stronie. Tutaj dochodzi żywy stan procesu. Samo odczytanie symbolu nie mówi komputerowi, że właściwy telefon otworzył właściwą sprawę. Dopóki system tego nie potwierdzi, status powinien mówić o oczekiwaniu.

Możliwe etykiety dla naszego szkicu są konkretne: „Czekamy na otwarcie etapu na telefonie”, później „Etap otwarty na telefonie”, a na końcu „Zdjęcie dodane do szkicu 284”. Każda wymaga własnego potwierdzonego zdarzenia. Nie zastępuj ich animacją przechodzącą automatycznie do sukcesu po kilku sekundach od pokazania kodu.

Jeśli przejście uruchamia systemowe udostępnianie adresu, przycisk powinien opisywać właśnie tę czynność. Jarek może wybrać aplikację, zrezygnować lub wysłać link w inne miejsce. Nie pokazuj „Telefon połączony” tylko dlatego, że otworzył się panel udostępniania.

MDN opisuje różne momenty zakończenia metody share: na Windows może to być uruchomienie okna udostępniania, a na Androidzie przekazanie danych do wybranego celu. Żaden z tych opisów nie potwierdza dodania zdjęcia do naszego zgłoszenia.

Osobno rozstrzygnij ważność wejścia. Kod może wygasnąć, zostać zastąpiony nowym albo utracić użyteczność po zakończeniu etapu. Jarek powinien zobaczyć konkretny stan i drogę powrotu do istniejącego szkicu. Wygaśnięcie połączenia nie powinno sugerować, że trzeba od nowa opisać walizkę.

Po ponowieniu przejścia komputer powinien wyraźnie pokazywać, której próby teraz oczekuje. Otwarta wcześniej strona telefonu może nadal wyglądać znajomo, ale wymagać odświeżenia lub ponownego potwierdzenia. Zespół powinien uzgodnić to zachowanie przed przygotowaniem komunikatu „po prostu zeskanuj ponownie”.

Otwórz ten sam etap także na drugim telefonie próbnym. Produkt musi określić, czy oba urządzenia mogą dodawać materiały, czy drugie przejmuje pracę po potwierdzeniu. W naszym wariancie wybieramy jeden aktywny etap fotografowania. Pierwszy telefon po przejęciu nie powinien nadal pokazywać nieaktualnej zachęty do wysłania. Komunikat ma wskazać zmianę i pozwolić wrócić do istniejącej sprawy.

Na telefonie najpierw rozpoznaj sprawę

Pierwszy widok telefonu powinien potwierdzić kontekst: serwis, model walizki i rozpoznawalny szkic. Nie trzeba kopiować wszystkich danych wpisanych na komputerze. Wystarczy tyle, aby Jarek wiedział, że dodaje zdjęcie do właściwej sprawy. Jeśli ma dwa zgłoszenia podobnego modelu, sam obraz walizki nie wystarczy.

Przy pracy w imieniu kilku firm zachowaj również aktywną organizację. Telefon może pamiętać inną przestrzeń niż komputer. Udane logowanie nie powinno po cichu kierować fotografii do ostatnio otwartego zgłoszenia innej firmy. Przed dodaniem materiału trzeba rozpoznać adresata tej konkretnej czynności.

Nie utożsamiaj posiadania kodu z tożsamością osoby. Mechanizm dostępu i dopuszczony zakres działania wymagają osobnego uzgodnienia technicznego. Projekt ma pokazać, co użytkownik zatwierdza, oraz nie zacierać różnicy między otwarciem etapu a udzieleniem szerszego dostępu do konta. Krótki proces nie powinien ukrywać długotrwałego skutku.

RFC 10027 o bezpieczeństwie przebiegów między urządzeniami opisuje ataki wykorzystujące skopiowane kody i zmianę kontekstu prośby o autoryzację. Dotyczy także przekazywania sesji, czyli zachowanego stanu dostępu. Sam znajomy format QR nie potwierdza właściwego celu takiej prośby.

W naszym przykładzie Jarek ma dodać zdjęcie, nie aktywować telefonu jako stałego narzędzia dostępu do wszystkich dokumentów firmy. Jeśli rozwiązanie wymaga dodatkowego potwierdzenia, nazwij jego zakres. Nie mieszaj instrukcji fotografowania z niejasną zgodą na „połączenie urządzeń”. Widok może pomóc rozpoznać zamiar; nie zastępuje jednak zabezpieczenia mechanizmu.

Następnie pozwól wybrać gotową fotografię albo zrobić nową, zgodnie z możliwościami produktu. Gdy strona prosi o dostęp do kamery, prośba powinna nastąpić przy tej czynności. Odmowa nie musi kasować szkicu. Można zachować wybór pliku z urządzenia lub wskazać inną obsługiwaną drogę.

Przed wysłaniem pokaż podgląd i możliwość poprawy. Jarek mógł sfotografować całą walizkę zamiast zawiasu albo wybrać starsze ujęcie. Celem telefonu jest dostarczenie konkretnego materiału, nie samo uruchomienie aparatu. Krótkie przypomnienie „Pokaż pęknięcie i mocowanie zawiasu” pomaga bardziej niż ogólne „Dodaj załącznik”.

Wynik etapu ma wrócić do komputera

Fotografia wybrana nie oznacza jeszcze fotografii przyjętej do szkicu. Projekt załączników w formularzu rozdziela wybór, przesyłanie i dalsze sprawdzenie. Tutaj stan musi być zrozumiały także na pierwszym urządzeniu. Nie pokazuj na komputerze gotowej miniatury pobranej tylko z lokalnego wyboru telefonu, jeśli plik nie jest jeszcze dostępny w sprawie.

Na telefonie po potwierdzonym dodaniu można napisać: „Zdjęcie jest w szkicu 284. Wróć do komputera, aby sprawdzić i wysłać zgłoszenie”. Ten komunikat zachowuje podział zadania z początku. Samo „Gotowe” może sugerować, że sprawa została już przekazana do serwisu. Jarek nie powinien odkrywać następnego dnia, że zgłoszenie nadal czekało w szkicach.

Komputer potrzebuje odpowiadającego temu wyniku: nazwy lub miniatury fotografii, stanu przyjęcia i dalszego przycisku. Jeżeli odświeżenie następuje ręcznie, nazwij potrzebną czynność. Automatyczny podgląd może być wygodny, ale nie należy udawać jego istnienia w projekcie, gdy uzgodnione rozwiązanie wymaga naciśnięcia „Sprawdź dodane zdjęcie”.

Przy opóźnieniu telefon i komputer mogą przez chwilę pokazywać różne etapy. To wymaga uczciwych komunikatów, nie wzajemnie sprzecznych deklaracji. Jeśli telefon potwierdził przyjęcie, a komputer jeszcze go nie odczytał, powinien móc sprawdzić stan tej samej operacji. Nie zachęcaj od razu do wysłania drugiej fotografii tylko dlatego, że miniatura nie pojawiła się natychmiast.

W przypadku przerwania transferu pokaż, co pozostało na każdym urządzeniu. Jarek może mieć wybrane zdjęcie wyłącznie na telefonie, a na komputerze zachowany opis bez załącznika. Droga ponowienia powinna dotyczyć fotografii. Utrata połączenia nie powinna tworzyć nowego numeru sprawy ani usuwać modelu wpisanego wcześniej na dużym ekranie.

Sprawdź również zmianę szkicu w czasie fotografowania. Jarek może na komputerze zamienić model walizki albo usunąć zgłoszenie, do którego telefon nadal ma otwarty etap. Przed przypisaniem zdjęcia system powinien ustalić aktualny stan, a ekran wyjaśnić ewentualną przeszkodę. Nie dodawaj pliku po cichu do innej sprawy o podobnej nazwie. Po zmianie modelu poproś użytkownika o potwierdzenie, czy fotografia nadal przedstawia właściwy przedmiot.

Jeżeli telefon wykonuje tylko ten etap, po zakończeniu nie musi zachęcać do przeglądania całego panelu. Warto jasno zakończyć pomocniczy przebieg i wskazać dalszą pracę na komputerze. Osobno ustal, czy pozostaje zwykła sesja konta i jak użytkownik może ją zakończyć. Zamknięcie ekranu zdjęcia oraz wylogowanie są różnymi czynnościami.

Gdy pierwszego ekranu już nie ma

Jarek może zamknąć komputer, zanim zrobi zdjęcie. Jeśli szkic jest zapisany, ponowne wejście powinno umożliwiać znalezienie tej samej sprawy i stanu materiału. Nie opieraj całej drogi na otwartym oknie oczekiwania. Pokaż, jak wrócić do zgłoszenia zwykłą ścieżką konta lub innym uzgodnionym sposobem.

Odwrotny przypadek to komputer nadal otwarty i zagubiony telefon. Użytkownik musi móc przerwać przekazanie etapu, zachowując to, co zostało już potwierdzone. Przerwanie nie powinno oznaczać automatycznego usunięcia poprawnego zdjęcia ani udawać odebrania dostępu, którego mechanizm w rzeczywistości nie zakończył. W projekcie potrzebne są oddzielne znaczenia tych działań.

Przy odbiorze przejdź drogę na dwóch rzeczywistych urządzeniach z jednym charakterystycznym szkicem. Sprawdź kontekst po zmianie konta, cofnięcie z aparatu i powrót po zamknięciu komputera. Porównaj plik w końcowym zgłoszeniu z fotografią zaakceptowaną na telefonie. Przekazanie jest użyteczne, kiedy oba ekrany potrafią opowiedzieć tę samą historię sprawy.

Do rozmowy z Aeneia Design przygotuj czynność, która wymaga dziś przesyłania materiału samemu sobie. To dobry punkt wyjścia do ustalenia krótszej drogi oraz granicy integracji. Jarek powinien na końcu wysłać jedno zgłoszenie z właściwym zdjęciem. Jego skrzynka pocztowa może spokojnie zrezygnować z pracy w charakterze prywatnego magazynu zawiasów.