Zacznij od wejścia do produktu.
Klient może przyjść z linku w wiadomości, strony firmy lub kodu w punkcie obsługi. Pracownik może codziennie otwierać narzędzie na firmowym telefonie. Te sytuacje prowadzą do innych wymagań dotyczących instalacji, konta i powrotu do ostatniej czynności.
PWA jest rozwiązaniem webowym z dodatkowymi możliwościami zależnymi od środowiska. Aplikacja natywna jest przygotowana dla konkretnej platformy. Żadna nazwa nie rozstrzyga, czy produkt poprawnie obsłuży rezerwację, zamówienie lub pracę w terenie.
Zapisz, jak odbiorca ma znaleźć produkt i co powinien zrobić podczas pierwszego użycia. Jeśli instalacja jest zbędnym krokiem przed krótką czynnością, warto sprawdzić pełny proces w przeglądarce. Jeśli korzystanie jest częste, porównaj również wygodę powrotu.
Ikona nie oznacza identycznych możliwości.
Obsługiwane PWA można instalować i uruchamiać w osobnym oknie. Warunki oraz ścieżka dodania do urządzenia różnią się między przeglądarkami i systemami. W projekcie potrzebny jest także poprawny wariant bez instalacji, dostępny przez adres internetowy.
Wersja natywna ma własny sposób dystrybucji i aktualizacji. Produkt dla publicznych klientów i narzędzie wewnętrzne firmy mogą wymagać różnych ustaleń. Konto wydawcy, materiały oraz obsługiwane urządzenia są częścią planu, nie dodatkiem po zakończeniu kodowania.
Nie obiecuj odbiorcom tych samych funkcji tylko dlatego, że oba produkty mają ikonę na telefonie. Przed wyborem PWA lub wersji mobilnej trzeba sprawdzić konkretną listę potrzeb.
Które funkcje urządzenia są konieczne?
Aparat, skan kodu, powiadomienia czy praca w tle mają sens wtedy, gdy prowadzą do określonego rezultatu. Zaznacz funkcje niezbędne oraz te, które jedynie skracają wygodną już ścieżkę. Ich dostępność może przesądzić o wariancie rozwiązania.
Dla każdej funkcji sprawdź urządzenie, system i zachowanie po odmowie uprawnienia. Zespół w terenie może mieć starsze telefony niż klienci firmy. Test na jednym nowym urządzeniu nie wystarcza do uznania całej listy za obsługiwaną.
Jeśli możliwość zależy od przeglądarki, zaprojektuj ścieżkę zastępczą lub jasną informację. Nie warto budować głównego zadania na założeniu, którego nie można potwierdzić w środowisku odbiorcy. Funkcje telefonu omawiamy także osobno.
Offline wymaga opisanych granic.
Zarówno w rozwiązaniu webowym, jak i mobilnym trzeba zdecydować, co jest dostępne bez internetu. Odczyt wcześniej pobranego zadania różni się od zatwierdzenia nowej rezerwacji. Interfejs powinien pokazać, które dane są aktualne i które operacje oczekują na potwierdzenie.
Przygotowany formularz może pozostać szkicem do późniejszego wysłania. W takim przypadku określ reakcję na zmianę danych po stronie firmy. Dwa identyczne wysłania nie powinny tworzyć dwóch zleceń, a nieaktualny termin nie może być przedstawiony jako pewna rezerwacja.
Samo użycie PWA lub technologii mobilnej nie tworzy automatycznie kompletnego trybu offline. Potrzebne są reguły lokalnego przechowywania, wysyłania, konfliktów i ochrony danych. To oddzielny element projektu i testów.
Przykład dwóch właściwych punktów wyjścia.
Dla klienta składającego raz na jakiś czas zamówienie hurtowe ważny może być dostęp z linku i czytelny formularz. PWA lub zwykła aplikacja webowa może być dobrym początkiem, jeśli wymagane funkcje działają w wybranych przeglądarkach.
Dla technika regularnie dodającego zdjęcia i pracującego w uzgodnionych warunkach offline warto porównać wariant natywny. Decyzja nadal zależy od telefonu, danych i konkretnych ograniczeń. Te przykłady nie są gotową regułą dla całej branży.
Wybieraj według pełnej ścieżki: dotarcie, instalacja lub link, działanie, potwierdzenie i aktualizacja. Zamiast pytać wyłącznie o nazwę technologii, poproś o pokazanie, jak produkt zachowa się w najtrudniejszym potrzebnym scenariuszu.
Porównaj także zaplecze i rozwój.
Koszt obejmuje więcej niż sam interfejs telefonu. Konta, panel, zapis danych, integracje i testy mogą być potrzebne w obu wariantach. Dlatego porównywanie ofert wymaga tej samej listy wymagań i jednoznacznych wyłączeń.
Pierwszy etap może skupiać się na procesie webowym, a następny na dodatkowych możliwościach urządzenia. Nie trzeba deklarować pełnego zakresu wszystkich platform na start. Zasady wyceny ApkaPro rozdzielają mały zakres webowy i indywidualnie wyceniane produkty mobilne.
Dokumentacja do dalszego sprawdzenia.
Możliwości platform zależą od środowiska i konfiguracji. Poniższe materiały wyjaśniają ich zasady; nie oznaczają partnerstwa ApkaPro z dostawcami.
Jaką decyzję podjąć dalej?
Dla wyboru potrzebnych możliwości telefonu przeczytaj Funkcje aplikacji na telefon: powiadomienia, zdjęcia i offline.
Przy planowaniu uruchomienia produktu mobilnego zobacz Jak przygotować publikację aplikacji na iOS i Android?.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Aplikacje PWA.