Zacznij od sytuacji użytkownika.
Pytanie „mobilna czy webowa” warto zadać po opisaniu głównego zadania. Inaczej korzysta się z jednorazowego formularza, inaczej z grafiku otwieranego co tydzień, a jeszcze inaczej z panelu dyspozytora. Miejsce, częstotliwość i urządzenie są lepszym punktem wyjścia niż prestiż posiadania aplikacji w sklepie.
Klient restauracji może wejść z linku w menu, a pracownik budowy potrzebować szybkiego widoku zadania na telefonie. Obie osoby używają komórki, lecz nie muszą potrzebować tego samego rodzaju produktu. Ustalamy też, czy użytkownik ma własne konto i do czego powinien regularnie wracać.
Spisz kilka scenariuszy: skąd użytkownik trafia do aplikacji, ile razy jej użyje i co musi zrobić przy słabym zasięgu. To pozwala ocenić wariant internetowy, mobilny lub ich połączenie bez automatycznego wyboru najdroższego zakresu.
Przeglądarka ułatwia pierwszy kontakt.
Aplikacja webowa działa pod adresem. Klient może otrzymać link, otworzyć go na telefonie lub komputerze i rozpocząć zadanie bez pobierania produktu ze sklepu. Ten wariant często pasuje do zapytania ofertowego, rezerwacji, zamówienia i panelu administracyjnego.
Wykonanie responsywnego interfejsu nie oznacza zmniejszenia widoku z komputera. Na telefonie trzeba dobrać kolejność informacji, szerokość pól i sposób pokazywania tabel. Panel firmy może korzystać z większej przestrzeni, a klient otrzymać krótszy przebieg tej samej sprawy.
Dostęp przez link nie usuwa potrzeby kont, uprawnień ani zapisu danych, jeśli produkt ich wymaga. To nadal pełna aplikacja z regułami, a nie wyłącznie strona informacyjna. Zobacz zakres aplikacji webowych.
iOS i Android dobieramy do częstych zadań.
Produkt mobilny warto rozważyć, gdy użytkownik regularnie wraca, potrzebuje powiadomień lub wykonuje zadania w terenie. Przykładem jest karta klubowicza albo lista zleceń pracownika. Trzeba jednak sprawdzić konkretne wymagania urządzenia i systemu, zamiast zakładać, że instalacja rozwiązuje wszystkie ograniczenia.
Dostęp do aparatu, lokalizacji czy pracy w tle wymaga określonego sposobu działania i ewentualnych zgód użytkownika. Nie należy projektować procesu tak, jakby takie uprawnienie zawsze było włączone. Odmowa dostępu powinna mieć czytelny rezultat i możliwy dalszy krok.
Wersje iOS oraz Android mają także własny zakres testów i publikacji. Podobny wygląd ekranów nie oznacza identycznego zachowania obu platform. Oferta mobilna obejmuje ustalenie funkcji potrzebnych w konkretnym produkcie.
PWA jest wariantem do sprawdzenia.
Niektóre aplikacje webowe można rozbudować o elementy PWA, na przykład określony zakres pracy bez sieci. To decyzja projektowa, nie automatyczny dodatek do każdej strony. Przede wszystkim trzeba ustalić, które dane wolno pokazać lokalnie i jakie operacje czekają na połączenie.
Praca offline nie oznacza, że kilka urządzeń natychmiast widzi te same zmiany. Dwie osoby mogą zająć ostatnie miejsce albo edytować tę samą sprawę. Projekt wymaga zasad synchronizacji i rozwiązywania konfliktów, a także testów na urządzeniach, z których faktycznie korzysta zespół.
Możliwości zależą od przeglądarki, platformy i wybranej implementacji. Google opisuje rolę service workerów w dokumentacji PWA. Wybór funkcji potwierdzamy w testach; lokalne podglądy ApkaPro nie mają wspólnego zapisu offline.
Klient i firma mogą mieć różne widoki.
Aplikacja dla hotelu może połączyć prosty widok pobytu na telefonie z panelem recepcji w przeglądarce. W firmie transportowej kierowca korzysta z krótkiej listy punktów, a dyspozytor przydziela zadania na komputerze. To jeden produkt z odmiennymi narzędziami dla użytkowników.
Wspólny serwer i uzgodnione dane pozwalają łączyć takie widoki, ale ten zakres trzeba zaprojektować. Każda rola ma własne działania i uprawnienia. Nie wystarczy udostępnić wszystkim ten sam ekran, a później ukrywać fragmenty interfejsu według stanowiska.
Na start można ograniczyć liczbę wariantów, jeśli nadal da się wykonać główne zadanie. Podgląd transportu pokazuje przydział i status; pełne połączenie kierowców oraz dyspozytora wymaga osobnego wdrożenia.
Porównaj cały koszt i drogę do użytkownika.
Oferta powinna wskazywać wykonanie, publikację, zewnętrzne usługi i późniejsze utrzymanie. Liczy się także łatwość dotarcia do odbiorcy. Link sprawdzi się w jednorazowym kontakcie, podczas gdy instalacja może mieć uzasadnienie dla osób często wykonujących to samo zadanie.
Nie obiecujemy, że każdy projekt webowy będzie tańszy albo że każda firma potrzebuje dwóch aplikacji mobilnych. O cenie decydują zakres, reguły, dane i połączenia. Mały zakres internetowy od 7 000 zł netto jest naszą ceną startową, a nie ceną wszystkich wariantów produktu.
Do rozmowy przygotuj częstotliwość używania, typ urządzeń, potrzebę pracy bez sieci i niezbędne funkcje telefonu. Dopisz, kto administruje sprawami. Na tej podstawie można omówić pierwszy zakres i zostawić świadomie określone rozszerzenia na później.
Jaką decyzję podjąć dalej?
Jeżeli rozważasz sposób udostępnienia produktu, przeczytaj PWA czy aplikacja natywna — co wybrać?.
Gdy punktem wyjścia jest działająca strona firmy, zobacz Aplikacja do istniejącej strony internetowej.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Aplikacje mobilne.