Czy proponować instalację strony? Najpierw znajdź powód do powrotu

Jeszcze nie wiadomo, czy w sali prób zmieści się perkusja, a strona już proponuje instalację aplikacji. Klient przyszedł sprawdzić dostępność czwartku. Zamiast tego podejmuje decyzję o nowym lokatorze ekranu telefonu. Propozycja może być technicznie poprawna i zupełnie nie w porę.

Instalowana aplikacja internetowa, często nazywana PWA, może ułatwiać regularne powroty do serwisu. Nie tworzy jednak powodu do powrotu. Najpierw trzeba wskazać czynność, którą człowiek będzie powtarzał, oraz miejsce, do którego ma trafić po naciśnięciu ikony. Dopiero wtedy można sensownie projektować zaproszenie do instalacji.

Rozważmy fikcyjną pracownię udostępniającą sale muzyczne. Zespół rezerwuje próbę, później sprawdza godzinę i wyposażenie, a tydzień później szuka kolejnego terminu. Nowy klient może wejść tylko raz, żeby porównać ceny. Obie osoby korzystają z tej samej strony, ale instalacja ma dla nich inne znaczenie. Nie muszą dostawać identycznego powitania.

Najpierw rozpisz zwykły powrót

W naszej pracowni powtarzalnym zadaniem jest sprawdzenie najbliższej rezerwacji i znalezienie kolejnego wolnego terminu. Ekran po uruchomieniu powinien temu służyć. Jeżeli ikona otwiera za każdym razem stronę z historią marki, klient nadal musi przedrzeć się przez menu. Instalacja skróciła wpisywanie adresu, lecz nie skróciła drogi do godziny próby.

Zanim powstanie baner, narysuj trzy konkretne wejścia: pierwszy klient porównujący sale, wracający użytkownik z rezerwacją i członek zespołu otwierający przesłany odnośnik. Każdy ma inny punkt startu. Wspólny ekran może zawierać drogę do terminarza i własnych rezerwacji, ale nie powinien udawać, że wszyscy już coś zamówili. Pierwsze użycie i pusty stan pozostają potrzebne także po instalacji.

Ułatwienie zwykłej strony jest często pierwszą użyteczną poprawką. Czy da się odnaleźć terminarz przez menu mobilne? Czy wiadomość potwierdzająca prowadzi do właściwej rezerwacji? Czy jej nazwa odróżnia pracownię od podobnej firmy? Instalacja nie powinna być warunkiem naprawienia tych ścieżek. Osoba odmawiająca nadal ma prawo sprawnie załatwić zadanie w przeglądarce.

Nie każda ikona na ekranie oznacza to samo. MDN rozróżnia zakładkę, skrót do zwykłej strony oraz instalację PWA; sposób instalacji zależy od przeglądarki i platformy.

W rozmowie z zespołem opisz więc oczekiwany efekt, zamiast poprzestawać na „dodajmy apkę”. Dla pracowni może nim być bezpośredni powrót do rezerwacji, czytelna nawigacja we własnym oknie oraz rozpoznawalna nazwa na urządzeniu. Każda z tych rzeczy wymaga osobnego potwierdzenia w działającym rozwiązaniu. Sama nowa ikona nie dowodzi wykonania całej obietnicy.

Wariant jednorazowy prowadzi do innej decyzji. Ktoś wynajmuje salę na sobotnie nagranie i potrzebuje później tylko adresu oraz zasad wejścia. Dobrze przygotowana wiadomość może mu wystarczyć. Nie musi instalować serwisu, żeby odczytać opłaconą rezerwację. Zespół projektowy powinien umieć wskazać również sytuację, w której świadomie rezygnuje z zachęty. Dzięki temu propozycja nie konkuruje z ważniejszą informacją o godzinie otwarcia albo zmianie sali.

Dobra chwila nie jest numerem wizyty

Po potwierdzeniu pierwszej rezerwacji można pokazać niewielką propozycję: „Wracasz na próby? Dodaj Pracownię do urządzenia, żeby łatwiej otwierać terminarz”. Klient właśnie zobaczył usługę, rozumie przyszłe użycie i nie musi przerywać wpisywania danych. Obok pozostaje zwykła droga do szczegółów rezerwacji. Klient może ją pominąć i od razu odczytać potwierdzenie.

Nie przyjmuj jednak zasady, że każda pierwsza rezerwacja kończy się tym samym oknem. Osoba mogła już zainstalować serwis w innym środowisku albo korzystać z pożyczonego urządzenia. Może też rezerwować salę jednorazowo na warsztat. Krótkie „Nie teraz” powinno zamykać temat na tę chwilę bez utrudniania dalszej pracy. Nie trzeba pytać za każdym kolejnym otwarciem szczegółów.

Przewodnik web.dev o propozycji instalacji opisuje beforeinstallprompt, czyli sygnał przeglądarki umożliwiający własną propozycję instalacji. Zaznacza jednak brak jego obsługi we wszystkich przeglądarkach. Własny przycisk nie daje powszechnej możliwości wywołania systemowego okna.

Projekt potrzebuje zatem kilku prawdziwych wariantów. Gdy można uruchomić instalację, przycisk prowadzi do odpowiedniego przebiegu. Gdy dostępna jest instrukcja ręczna, wyjaśnia kroki dla rozpoznanego środowiska. Gdy instalacja nie jest dostępna lub nie wiadomo, jak ją poprawnie zaoferować, podstawowa strona pozostaje użyteczna. Martwy przycisk „Zainstaluj” z długą instrukcją naprawy nie pomaga wrócić na próbę.

Instrukcja powinna kończyć się rozpoznawalnym rezultatem. Nazwij ikonę, której użytkownik ma szukać, i pokaż, co otworzy się po jej wybraniu. Nie umieszczaj jednego zrzutu menu jako instrukcji dla wszystkich telefonów. Różnice w nazwach i położeniu poleceń mogą być istotą problemu. W dokumentacji projektu zapisz, dla jakiej konfiguracji przygotowano konkretny wariant.

Warto pozostawić możliwość znalezienia propozycji później, na przykład w pomocy serwisu. Zamknięcie banera nie musi oznaczać odrzucenia instalacji na zawsze. Użytkownik mógł wtedy nie mieć czasu albo korzystać z niewłaściwego urządzenia. Późniejsza droga powinna być dostępna bez wywoływania presji: nadal ma nazywać korzyść i prowadzić do aktualnej metody, a nie prosić o cofnięcie wcześniejszej decyzji.

Własny komunikat i okno przeglądarki warto oglądać razem. Czy używają tej samej nazwy pracowni i rozpoznawalnej ikony? Czy obiecana funkcja wynika z tego, co klient właśnie zobaczył? Jeżeli na stronie występuje nazwa sali, a przy instalacji nieznana nazwa technicznego projektu, człowiek może przerwać nawet całkiem prosty proces. Do próby przygotuj ostateczne elementy identyfikacji, nie tymczasowy kwadrat z literą. Odbiorca nie zna wewnętrznych nazw zespołu.

Instalacja kończy się poza twoim ekranem

Naciśnięcie własnego przycisku nie jest jeszcze potwierdzeniem instalacji. Użytkownik może zamknąć następne okno, przerwać proces albo stracić orientację po przejściu do menu przeglądarki. W projekcie oddziel te momenty. Informacja „Zainstalowano” powinna wynikać z rozpoznanego zdarzenia, a nie z samego dotknięcia zachęty.

Nie ma też potrzeby zostawiania człowieka na pustym ekranie, gdy instalacja przebiega gdzie indziej. Szczegóły rezerwacji nadal powinny być dostępne. Jeśli po powrocie z menu zniknął wpisywany wcześniej wybór terminu, propozycja spowodowała dodatkową pracę. Dlatego nie wstawiaj jej między wyborem godziny a zatwierdzeniem tylko dlatego, że akurat w tym miejscu mieści się graficzny komunikat.

Przy odbiorze rozróżnij, co naprawdę potrafisz stwierdzić. MDN wyjaśnia, że tryb wyświetlania nie odpowiada jednoznacznie statusowi instalacji. Zainstalowany serwis może nadal zostać otwarty w karcie przeglądarki.

To ma praktyczny skutek dla treści. Ekran w karcie nie powinien bezwarunkowo oznajmiać: „Nie masz naszej aplikacji”. Bezpieczniej opisać dostępną czynność lub aktualny sposób otwarcia. Własny tekst nie musi zgadywać całej historii urządzenia. Zespół powinien znać różnicę między brakiem sygnału o instalacji a potwierdzonym brakiem instalacji, zanim użyje tego rozpoznania do wielokrotnego wyświetlania zaproszenia.

Pierwsze otwarcie z ikony jest osobnym projektem

W pracowni klient instaluje serwis na stronie potwierdzenia czwartkowej próby. Tydzień później naciska ikonę. Czy otworzy się to samo potwierdzenie, aktualna lista rezerwacji czy terminarz? Każda z tych decyzji może mieć uzasadnienie, lecz domyślny start nie powinien wynikać z przypadkowego miejsca, w którym wyświetlono zachętę.

Opis start_url w MDN wskazuje zalecany adres startowy zapisany w manifeście, czyli pliku opisującym aplikację. Dokumentacja zaznacza, że przeglądarki mają swobodę jego obsługi.

Własny projekt może przyjąć ekran „Twoje próby”, pokazujący najbliższą rezerwację i przejście do nowych terminów. Kiedy nie ma aktywnych rezerwacji, nie pokazuje starego czwartku jako aktualnego. Osoba niezalogowana rozumie, jak wejść na konto lub przeglądać dostępność. Zmiana daty między instalacją a powrotem jest częścią zadania, a nie egzotycznym przypadkiem testowym.

Ustal również nawigację bez zwykłego otoczenia przeglądarki. Klient otwiera szczegóły sali, przechodzi do wyposażenia i chce wrócić do wyboru godziny. Powinien mieć widoczną drogę w serwisie, jeżeli używany tryb nie pokazuje znanych przycisków przeglądarki. Dotyczy to także pomocy i wyjścia na zewnętrzną stronę. Nie zakładaj, że użytkownik odnajdzie ukryty gest tylko dlatego, że projektant wykonuje go odruchowo.

Ikona nie rozwiązuje logowania. Jeżeli po powrocie potrzebne jest potwierdzenie dostępu, pokaż powód i zachowaj cel wejścia. Przy wygaśnięciu sesji klient nadal szuka wskazanej rezerwacji. Nie przenoś klienta po udanym logowaniu na przypadkową stronę główną. Przy stosowaniu kluczy dostępu osobnej uwagi wymaga rozpoznanie metody i sytuacja po zmianie urządzenia. Instalacja serwisu i dostęp do konkretnego konta pozostają różnymi sprawami.

Jeżeli telefon bywa pożyczany innym muzykom, ekran startowy nie może utożsamiać ikony z osobą. Po wylogowaniu nadal powinna istnieć jasna droga do terminarza, lecz szczegóły prywatnej rezerwacji wymagają odpowiedniego dostępu. W próbie najpierw wyloguj pierwszego użytkownika, a potem otwórz ikonę ponownie. Zapisz, które informacje mają się pojawić i dlaczego. Nie wnioskuj o tożsamości na podstawie tego, kto kiedyś zainstalował serwis.

Podobnie potraktuj brak sieci. Zainstalowana ikona nie jest obietnicą, że można teraz zarezerwować dostępną godzinę bez kontaktu z terminarzem. Jeśli pokażesz zapisaną wcześniej rezerwację, oznacz, z jakiego stanu pochodzi. Praca offline i późniejsze wysyłanie zmian wymagają własnych reguł. W naszej pracowni sensowną decyzją może być podgląd zapisanych informacji bez możliwości potwierdzania nowych terminów.

Przygotuj też zmianę rezerwacji dokonaną inną drogą, na przykład przez obsługę pracowni. Po powrocie z ikony klient powinien rozpoznać aktualną salę albo informację o braku świeżego odczytu. Stary ekran potwierdzenia nie może udawać nowego sprawdzenia. W materiale do odbioru rozdziel to, co ma być odświeżane z systemu rezerwacji, od informacji zachowanej do podglądu. W ten sposób projekt opisuje konkretną odpowiedzialność widoku, zamiast zakładać, że instalacja zapewnia aktualność danych.

Wróć inną drogą niż przed chwilą

Do próby przygotuj co najmniej dwa wejścia: z ikony oraz z odnośnika do konkretnej rezerwacji w wiadomości. Drugi nie powinien tracić wskazanego celu tylko dlatego, że istnieje również ogólny ekran startowy. Użytkownik chce zobaczyć tę jedną próbę. To, czy otworzy ją w karcie czy osobnym oknie, musi zostać sprawdzone w rzeczywiście wspieranej konfiguracji.

Przeprowadź też zwykłe zadanie po odmowie instalacji. Czy da się zmienić termin, odnaleźć pomoc i odczytać potwierdzenie bez ponawianej zachęty? Następnie sprawdź powrót z pustym kontem, z wygasłym dostępem i bez połączenia. W zapisie odbioru nazwij konfigurację urządzenia, przeglądarki oraz sposób wejścia. Sam zrzut ikony nie opisuje żadnego z tych przebiegów.

Oddziel również miarę zainteresowania instalacją od oceny użyteczności. Można policzyć otwarcia propozycji, lecz odpowiedź na nasze pytanie wymaga obserwacji powrotu: czy klient odnalazł najbliższą próbę i rozpoczął szukanie kolejnego terminu? Zapisz, czy wrócił z ikony, wiadomości czy zwykłej zakładki. Nie przypisuj instalacji każdego późniejszego udanego zadania. Bez takiego rozróżnienia łatwo dopracować zachętę, która zdobywa akceptacje, a pozostawia niewygodny terminarz.

W Aeneia Design taki zakres można opracować jako projekt ekranów i interakcji z konkretnymi warunkami ich pokazania. Punktem wyjścia będzie mapa powrotów, a nie zamówienie uniwersalnego banera. Na koniec naszej próby klient ma odnaleźć aktualną rezerwację i wiedzieć, gdzie szukać kolejnej godziny. Instalacja jest przydatna wtedy, gdy pomaga mu wrócić do tej pracy także po zamknięciu prezentacji projektu.