Pytanie „czy aplikacja ma być mobilna?” często pojawia się, zanim ktokolwiek ustali, gdzie będzie używana. Tymczasem innego narzędzia potrzebuje osoba przy biurku, innego technik w terenie, a jeszcze innego klient korzystający raz na kilka miesięcy. Telefon jest urządzeniem, nie argumentem za konkretną technologią. Najpierw opisz warunki pracy, potem wybierz sposób dostarczenia aplikacji. To pozwala uniknąć płacenia za funkcje, których użytkownik nigdy nie otworzy.
Aplikacja webowa działa przez przeglądarkę. PWA to aplikacja korzystająca z technologii sieciowych, która może dodawać wybrane możliwości kojarzone z programem instalowanym. Aplikacja mobilna jest przygotowana dla określonego środowiska urządzeń i może być dystrybuowana przez odpowiednie kanały. Dokumentacja MDN opisuje możliwości PWA, ale dostępność szczegółowych funkcji trzeba zawsze sprawdzić dla docelowych przeglądarek i systemów. Sama nazwa nie gwarantuje pełnego zestawu możliwości.
Zacznij od częstotliwości i miejsca użycia
Jeżeli pracownik obsługuje panel codziennie na komputerze, przeglądarka może zapewnić wygodny dostęp bez osobnej instalacji. Jeśli klient ma jednorazowo zatwierdzić dokument, wymaganie pobrania aplikacji może stać się niepotrzebną przeszkodą. W obu sytuacjach ważne są logowanie, czytelność i szybkie dotarcie do zadania. Ikona na ekranie telefonu nie naprawi długiego formularza. Czasem tylko ułatwi odnalezienie miejsca, w którym człowiek ponownie utknie.
Warunki dobrze sprawdza test prototypu na docelowym urządzeniu. Nie ograniczaj go do wielkości ekranu. Zwróć uwagę na obsługę jedną ręką, światło, rękawice, częstotliwość przerw i powrót do rozpoczętej sprawy. Potrzeba szybkiego zrobienia zdjęcia na budowie ma inny charakter niż potrzeba wypełnienia obszernej tabeli w biurze. Projekt interfejsu powinien odpowiadać na tę różnicę, niezależnie od wybranej technologii.
Offline oznacza reguły synchronizacji, nie sam brak internetu
Zapisanie danych na urządzeniu jest dopiero częścią pracy offline. Trzeba ustalić, co dzieje się po odzyskaniu połączenia, jak użytkownik rozpozna dane niewysłane i jak rozwiązać sprzeczne zmiany. Jeżeli dwie osoby poprawią tę samą sprawę, aplikacja potrzebuje uzgodnionej odpowiedzi. Takie wymaganie wpływa na zakres, testy oraz utrzymanie. Nie powinno pozostawać małą adnotacją na końcu listy funkcji.
Dobrze widać to w aplikacji do dokumentów przewozowych i w narzędziu dla ekip terenowych. Użytkownik może wykonać zadanie daleko od stabilnego połączenia, ale biuro musi później wiedzieć, czy otrzymało komplet informacji. Dlatego projektuje się widoczny status synchronizacji oraz sposób ponowienia, zamiast zakładać, że telefon na pewno wyśle wszystko w dogodnym momencie.
Funkcje urządzenia weryfikuj na początku
Aparat, lokalizacja, skanowanie kodów czy powiadomienia mogą mieć różne ograniczenia zależnie od środowiska. Przed zamknięciem architektury warto wykonać niewielką próbę z urządzeniami używanymi w firmie. Jest to szczególnie ważne, gdy zespół korzysta ze starszego sprzętu lub kilku modeli. Działający pokaz na telefonie projektanta nie potwierdza jeszcze zgodności z całą flotą. Sprawdzenie tej zależności wcześnie jest zwykle prostsze niż późniejsza zmiana drogi dystrybucji.
Nie wszystkie takie wymagania muszą wejść do pierwszego wydania. Można zacząć od formularza dostępnego w przeglądarce i dopiero po sprawdzeniu pracy zdecydować o dalszej rozbudowie. Ważne, aby podział miał sens dla użytkownika i został uwzględniony w wycenie aplikacji. Jeśli funkcja urządzenia stanowi warunek wykonania zadania, jej odłożenie wymaga innego, jasno opisanego sposobu działania.
Uwzględnij publikację i późniejsze zmiany
W rozmowie uwzględnij także sytuację utraty urządzenia albo zmiany pracownika. Ustal, jak odebrać dostęp i które informacje mogą pozostawać zapisane lokalnie. Nie każda aplikacja potrzebuje tych samych zabezpieczeń, ale każda powinna mieć opisane założenia. Dzięki temu przy wyborze technologii można ocenić wygodę instalacji razem z warunkami używania danych. Takie pytania można rozstrzygnąć wcześnie, zanim gotowy produkt zacznie krążyć po prywatnych i firmowych telefonach.
Wybór technologii wpływa również na dostarczanie aktualizacji, testowanie nowych wersji i zakres wsparcia. Warto ustalić, kto zarządza kontami, certyfikatami oraz wydaniami, jeśli będą potrzebne. Nie jest to powód, żeby unikać aplikacji mobilnych. To powód, żeby uwzględnić cały cykl produktu. Zasady przekazania i utrzymania powinny pasować do sposobu, w jaki aplikacja trafia do odbiorców.
W Archifutura dobieramy aplikacje webowe i mobilne do konkretnych zadań, zamiast zaczynać od etykiety technologii. Na pierwszą rozmowę przygotuj listę urządzeń, miejsca pracy i czynności, które muszą być możliwe bez pomocy biura. Jeżeli kilka rozwiązań spełnia te warunki, porównamy ich konsekwencje dla wdrożenia oraz późniejszego rozwoju. To bardziej użyteczne niż wybór według tego, która nazwa lepiej wygląda w prezentacji.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
