Strona prosi o kamerę. Czy użytkownik wie po co?

„Ta strona chce używać kamery”. Klient chciał tylko przeczytać, jak zgłosić uszkodzoną lampę. Jeszcze nie znalazł formularza, ale już ma udostępnić kawałek salonu. W nim stoi sama lampa, stos prania i człowiek, który nie umawiał się na występ w instrukcji obsługi.

Prośba przeglądarki pojawia się nad stroną, lecz jej sens powstaje wcześniej w projekcie. Użytkownik powinien rozumieć, jaką czynność uruchomił, dlaczego wymaga ona danego zasobu i co może zrobić zamiast tego. Samo zdanie „Potrzebujemy uprawnień do poprawnego działania” nie odpowiada na żadne z tych pytań.

Posłużmy się fikcyjnym serwisem lamp. Klient może dołączyć zdjęcie tabliczki z modelem, opisać uszkodzenie i wybrać punkt obsługi. Zespół rozważa także krótką notatkę głosową. Każda z tych funkcji dotyczy innego zasobu urządzenia. Nie ma powodu, żeby wszystkie uruchamiały swoje pytania od razu po wejściu na stronę.

Przed pytaniem pokaż czynność i jej granicę

Przy numerze modelu można zaoferować „Zrób zdjęcie tabliczki”. Obok pozostają „Wybierz gotowe zdjęcie” i pole do ręcznego wpisania oznaczenia, jeżeli proces przyjmuje taką informację. Krótkie wyjaśnienie mówi, po co fotografia jest potrzebna: ułatwi obsłudze rozpoznanie lampy. Nie sugeruje automatycznego odczytania każdego numeru, jeśli serwis nie ma takiej sprawdzonej funkcji.

Wskazówki web.dev dotyczące uprawnień zalecają pytanie po działaniu użytkownika, w zrozumiałym kontekście, oraz alternatywną drogę tam, gdzie jest możliwa. To zalecenie projektowe, nie gwarancja konkretnego wyniku biznesowego.

W naszym przypadku klient najpierw wybiera aparat. Własny opis przygotowuje go na pytanie przeglądarki, ale nie podszywa się pod nie. Przycisk „Przejdź do aparatu” nie musi nazywać się „Wyrażam zgodę”, bo nie zastępuje decyzji w oknie urządzenia. Tym bardziej nie powinien sugerować akceptacji regulaminu albo wszystkich późniejszych sposobów wykorzystania materiału. Tutaj projektujemy dostęp do funkcji, a nie warunki prawne obsługi danych.

Trzeba też pokazać moment wysyłki. Uruchomienie aparatu, wykonanie ujęcia i przekazanie zdjęcia do sprawy to różne etapy. Klient może chcieć poprawić kadr lub zrezygnować po zobaczeniu podglądu. Jeśli materiał jest przesyłany wcześniej, opis i zachowanie muszą to ujawniać. Nie pozostawiaj etykiety „podgląd”, która w praktyce oznacza już automatyczne dołączenie do zgłoszenia.

Pytaj o zasób potrzebny do tej funkcji. Zdjęcie tabliczki nie wymaga w naszym przykładzie mikrofonu. Gdy klient wybierze notatkę głosową, dostanie osobne wyjaśnienie nagrania. Łączenie wszystkiego w pierwszej prośbie utrudnia rozpoznanie celu i późniejszego problemu: ktoś odmawia dźwięku, choć chciał tylko zrobić fotografię.

Nazwy na stronie powinny zgadzać się z dalszą drogą. Po „Zrób zdjęcie” oczekuje się aparatu lub wyjaśnienia, jak go uruchomić. Po „Dodaj zdjęcie” może pojawić się wybór pliku. Jeśli projekt korzysta z innego zachowania systemu, trzeba je sprawdzić na wspieranych urządzeniach. Rysunek okna przeglądarki w makiecie nie określa zachowania telefonu użytkownika.

Dobrze przygotowane komunikaty marki w interfejsie mogą zachować spokojny ton bez ukrywania skutku. „Pokażmy lampę w najlepszym świetle” nadaje się może do hasła na stronie. Obok dostępu do aparatu lepiej powiedzieć, co zostanie uruchomione i po co. Krótki opis powinien uprzedzać o uruchomieniu aparatu; żart może go co najwyżej uzupełnić.

Odmowa to tylko jedna z możliwych odpowiedzi

Projekt często zawiera dwa widoki: aparat działa albo klient „nie wyraził zgody”. W rzeczywistym zadaniu przyczyn braku obrazu jest więcej. Może nie być odpowiedniego urządzenia, dostęp może ograniczać konfiguracja, a użytkownik może w ogóle nie odpowiedzieć na pytanie. Wtedy formularz nie powinien czekać bez końca z napisem „Uruchamiamy kamerę”.

Dokumentacja getUserMedia w MDN opisuje różne przyczyny błędów oraz możliwość pozostawienia pytania bez odpowiedzi. Nie każdy brak obrazu oznacza świadomą odmowę użytkownika.

W materiale projektowym przydadzą się osobne sytuacje, z nazwami odnoszącymi się do tego, co naprawdę wiadomo:

• Oczekiwanie na wybór. Strona wyjaśnia, gdzie może znajdować się pytanie przeglądarki, i pozostawia wyjście do innej metody. Nie ogłasza ani odmowy, ani uruchomienia aparatu.
• Dostęp zablokowany. Klient widzi możliwość zmiany ustawienia lub wykonania zadania inaczej. Komunikat nie może obiecywać, że naciśnięcie „Spróbuj ponownie” zawsze wywoła nowe okno.
• Brak działającego obrazu. Gdy rozpoznano problem urządzenia, treść dotyczy urządzenia. Gdy przyczyna jest nieznana, strona zachowuje tę niepewność zamiast stwierdzać winę klienta.
• Podgląd gotowy. Użytkownik rozumie, czy obraz tylko widzi, czy już coś zapisuje. Ma czytelny sposób wykonania zdjęcia i zakończenia tej czynności.
• Powrót po zmianie ustawień. Formularz nadal zawiera opis uszkodzenia. Strona rozpoznaje nowy stan lub informuje, co ponowić, bez rozpoczynania całego zgłoszenia od początku.

MDN wymienia stany uprawnienia: granted (przyznane), denied (odmowa) i prompt (bez wyraźnego przyznania). Ostatni nie jest obietnicą, że pytanie zostanie pokazane; próba użycia funkcji może też zakończyć się odmową.

Te nazwy pomagają wykonawcy ustalić zachowanie, lecz nie muszą trafić do klienta w technicznej postaci. „Dostęp jest zablokowany” mówi więcej niż sam kod błędu. Jeśli nie ustalono, czy ograniczenie pochodzi z decyzji użytkownika czy innego warunku, nie dopisuj „Zablokowałeś aparat”. Ludzie potrafią poczuć się niesłusznie oskarżeni nawet przez całkiem mały prostokąt.

Przy zmianie ustawień pokaż instrukcję dla właściwej konfiguracji. Nie każ szukać kłódki w miejscu, w którym używana przeglądarka pokazuje inny symbol. Ważniejsza od szczegółowej grafiki jest możliwość wrócenia do własnego formularza. Klient może zamknąć instrukcję, poprawić ustawienie i nadal potrzebować wpisanego opisu lampy.

Odmowa powinna prowadzić do pełnego wariantu zadania. „Wybierz zdjęcie” wymaga własnej drogi przyjęcia pliku, a ręczny numer modelu powinien trafiać w użyteczne miejsce zgłoszenia. Stany załączników nie znikają dlatego, że wcześniej pytano o kamerę. Wybrany obraz nadal może wymagać przesłania i sprawdzenia.

Nie każda alternatywa dostarczy jednak ten sam materiał. W serwisie sam numer modelu może wystarczyć do pierwszego pytania, lecz do oceny widocznego uszkodzenia potrzebne będzie zdjęcie. Nazwij tę różnicę przed wysłaniem. Klient bez aparatu może rozpocząć rozmowę i dostarczyć fotografię później, jeśli firma rzeczywiście tak pracuje. Jeżeli materiał jest konieczny od razu, pokaż uzgodnioną pomoc zamiast udawać, że dowolny tekst zastąpi dowód potrzebny obsłudze.

Warto oddzielić też zdjęcie od materiału już przyjętego. Klient wykonuje ujęcie, widzi je w formularzu i naciska „Wymień”. Projekt powinien określić, czy poprzedni plik pozostaje przy sprawie do chwili poprawnego zastąpienia. Uprawnienie do aparatu nie wyjaśnia losu wcześniejszej fotografii. Ten sam dostęp może posłużyć do wielu ujęć, ale klient potrzebuje rozpoznać jedno wybrane do wysyłki.

Jest też trudniejsza kolejność: klient nie zauważa pytania przeglądarki, wybiera gotowy plik, a dopiero później zezwala na aparat. Spóźniona odpowiedź nie powinna bez wyjaśnienia zastąpić wybranego zdjęcia nowym podglądem. W projekcie przypisz wynik do czynności, która go wywołała, i określ zachowanie po jej porzuceniu. Przy odbiorze przejdź właśnie ten wariant. Widok sprawdzony wyłącznie przez natychmiastowe naciśnięcie „Zezwól” pomija konflikt dwóch metod.

Co zmienia mikrofon, a co lokalizacja

W naszym serwisie fotografia służy rozpoznaniu modelu. Nagranie głosowe miałoby zastąpić pisany opis. Zanim pojawi się przycisk mikrofonu, zespół powinien określić, kto odsłucha materiał i jak trafi on do sprawy. Sama możliwość nagrania nie oznacza, że obsługa potrafi go później użyć. Alternatywa tekstowa ma sens szczególnie tam, gdzie klient nie chce mówić na głos lub nie ma spokojnego miejsca.

Po wybraniu nagrywania potrzebne są odrębne sygnały: czy dźwięk jest właśnie zbierany, czy nagranie zatrzymano i który materiał zostanie wysłany. Gotowość mikrofonu nie oznacza rozpoczęcia wypowiedzi. W projekcie używaj nazw zgodnych z faktycznymi zdarzeniami. Po rezygnacji sprawdź, czy strona zakończyła używanie mikrofonu. Samo zamknięcie kolorowego okna tego nie potwierdza.

Przed wysłaniem notatki głosowej klient powinien móc rozpoznać, co przygotował. Odsłuch, usunięcie i ponowne nagranie wymagają czytelnych działań. Jeżeli zamiast samego dźwięku firma proponuje transkrypcję, czyli zapis wypowiedzi w tekście, trzeba osobno określić, który materiał otrzyma obsługa i co klient może poprawić. W naszym przykładzie obsługa otrzymuje nagranie. Klient odsłuchuje je przed wysłaniem i może zastąpić, jeśli zamiast opisu lampy utrwalił głównie radio stojące obok.

Lokalizacja ma jeszcze inny cel: znalezienie punktu serwisowego. Klient zgłaszający lampę z pracy może jednak chcieć oddać ją blisko domu. Nawet prawidłowo odczytane położenie urządzenia nie rozstrzyga, gdzie zamierza pojechać. Obok „Użyj mojej lokalizacji” pozostaw wpisanie miejscowości albo wybór z listy.

MDN opisuje pobranie położenia jako funkcję wymagającą uprawnienia. Wywołanie może być również ograniczone polityką strony; dopuszczalny wiek wyniku i czas oczekiwania mają osobne ustawienia.

Dla klienta liczy się rozpoznawalne miejsce początkowe i poprawny wybór punktu. Jeśli odczyt trwa lub się nie powiedzie, lista placówek nie musi znikać. Nie nazywaj „brakiem serwisu w okolicy” sytuacji, w której brakuje tylko danych o położeniu. Projekt mapy i listy punktów obsługi pomaga oddzielić lokalizację urządzenia od miejsca, które naprawdę przyjmuje daną sprawę.

Przejdź również zadanie po cofnięciu wcześniej udzielonego dostępu. Użytkownik mógł zmienić ustawienia między wizytami, a prototyp zachowujący poprzedni stan tego nie pokaże. Przy ponownym wejściu sprawdź treść pytania, dalszą drogę bez zasobu i zachowanie już przygotowanego zgłoszenia. Nie trzeba traktować poprzedniej decyzji jako obietnicy na całą przyszłość.

Podobnego rozdzielenia wymagają ustawienia powiadomień: wybór tego, o czym klient chce słyszeć, to inna decyzja niż techniczny dostęp do kanału. Jeden przycisk „Włącz wszystko” może ukrywać obie. W serwisie lamp najpierw trzeba ustalić, jak klient chce dostać odpowiedź na konkretną sprawę, zamiast prosić o wszystkie możliwe uprawnienia.

Do odbioru wystarczy rozpoznawalny scenariusz, lecz trzeba wykonać go kilkoma drogami. Klient fotografuje model, rezygnuje z aparatu, wraca z plikiem, zmienia ustawienie i kończy zgłoszenie. Próba z brakiem połączenia sprawdza dodatkowo, czy lokalny podgląd nie udaje już wysłanej fotografii. Przy każdym przebiegu obsługa powinna rozpoznać, jaki materiał rzeczywiście otrzymała.

Próbę wykonaj także bez rozpoznawania samych ikon. Nazwy działań powinny wyjaśniać aparat, wybór pliku i zamknięcie podglądu. Po powrocie z pytania przeglądarki klient musi znaleźć miejsce dalszej pracy również przy obsłudze klawiaturą lub czytnikiem ekranu. Jeśli podgląd zajmuje cały telefon, zostaw rozpoznawalne zakończenie tej czynności. Wyjście nie powinno wymagać gestu, którego nie podano ani nie sprawdzono w używanym środowisku.

Projekt takich ekranów w Aeneia Design zaczyna się od celu funkcji i informacji potrzebnej odbiorcy. W naszym przykładzie dobrym zakończeniem jest przyjęte zgłoszenie z właściwym numerem modelu, zdjęciem lub innym uzgodnionym materiałem. Po zakończeniu klient widzi przyjęty materiał przy swojej sprawie, a nie kolejną prośbę o uruchomienie aparatu.