Jak zrobić kiepską aplikację mobilną?
Nikt nie ma wątpliwości, że dzisiejszy świat technologii nastawiony jest w głównej mierze na urządzenia mobilne. Chcąc dotrzeć ze swoim oprogramowaniem do szerszej grupy odbiorców, musimy rozważyć aplikację mobilną. W tym artykule przedstawię, jak zrobić najgorszą na świecie apkę. Jest to swego rodzaju zbiór antywzorców, których należy się wystrzegać już na etapie projektowania naszego oprogramowania. Kolejność błędów jest losowa i każdy z nich jest w podobnym stopniu irytujący dla użytkownika.
Brak synchronizacji danych
Chcąc stworzyć beznadziejną aplikację, musimy zapomnieć o czymś takim jak synchronizacja danych — jest to zbędny wydatek, który ani trochę nie wpływa na odbiór naszego produktu przez użytkowników.
To zupełnie normalne, gdy tracimy wszystkie swoje zasoby po przesiadce na nowy telefon, nie ma również potrzeby, aby dane pomiędzy aplikacją mobilną a wersją przeglądarkową naszego produktu były spójne. Oprogramowanie mobilne powinno działać w głównej mierze offline, bo przecież użytkownik może w każdej chwili stracić dostęp do sieci.
Jednak synchronizacja to nie tylko zapis danych na zewnętrznym serwerze. UX możemy zepsuć też, bazując na zapisie lokalnym. Wyobraźmy sobie, że jesteśmy w połowie wypełniania jakiegoś skomplikowanego formularza i nagle dostajemy telefon. To oczywiste, że po zakończeniu rozmowy i powrocie do aplikacji powinniśmy zobaczyć główny ekran naszego oprogramowania, a nie formularz z informacjami, które zdążyliśmy uzupełnić już wcześniej.
Brak trybu offline
Wróćmy na chwilę do przykładu z formularzem z poprzedniego akapitu. Gdy wypełnimy
już wszystkie jego pola, zobaczymy przycisk „wyślij”, który wysyła nasze dane na serwer.
Co jednak w sytuacji, gdy akurat jesteśmy poza zasięgiem sieci? W dobrej aplikacji formularz zostałyby, zapisany w lokalnej bazie danych, gdzie czekałby do czasu, aż odzyskamy dostęp do sieci i tuż po tym automatycznie wysłany. My natomiast moglibyśmy kontynuować korzystanie z programu.
Natomiast w naszej kiepskiej apce powinniśmy dostać komunikat o błędzie, który oczywiście nie ma opcji ponowienia zapytania. Jedynym wyjściem z tej sytuacji jest wypełnienie formularza od nowa — użytkownicy na pewno to pokochają.
Ciągłe loadery
Gdy nasza aplikacja w dużym stopniu polega na informacjach otrzymanych z zewnętrznego serwera, musimy to pokazać użytkownikom. Jaki element najlepiej pokazuje, że czekamy na informacje z sieci? Bez wątpienia loader. Jeśli dane z API są potrzebne na trzech występujących po sobie ekranach, nie możemy ich tak po prostu załadować na pierwszym z nich. Koniecznie należy wyświetlić loader przy wejściu na każdy ekran i kazać użytkownikowi czekać po kilka sekund. Chyba nie muszę też dodawać, że loader powinien się pojawiać również, gdy powrócimy do appki po tym, jak wcześniej ją zminimalizowaliśmy? Nie ważne, że dane zostały załadowane kilka sekund temu, obowiązkowo musimy je pobrać jeszcze raz.
Większość dobrych aplikacji zapisuje raz pobrane dane w pamięci lokalnej, dzięki temu użytkownik widzi treści natychmiast po wejściu na ekran, podczas gdy aktualizacja danych następuje w tle i nie blokuje interfejsu. Oczywiście jest to niepotrzebne marnowanie zasobów, przecież ciągłe czekanie ani trochę nie frustruje użytkowników.
Zmiana położenia elementów interfejsu
Czasami sytuacja może zmusić nas do implementacji funkcjonalności przyjaznych użytkownikowi takich jak lokalne cachowanie, o którym wspominałem w poprzednim akapicie. Nie ma jednak co się martwić, bowiem to też można zepsuć.
Załóżmy, że mamy ekran składający się z treści tekstowej oraz przycisku. Po wejściu na ten ekran widzimy treść wczytaną z pamięci lokalnej, a w tle aplikacja sprawdza, czy lokalnie zapisany tekst jest zgodny z tym na serwerze. Jeśli zawartość na serwerze została zaktualizowana, zmieniamy tekst na ekranie.
Jeśli chcemy, aby nasza aplikacja była beznadziejna, koniecznie musimy umieścić przycisk w taki sposób, aby w przypadku zmiany tekstu zmieniło się również położenie tego elementu. Z perspektywy użytkownika nie ma nic fajniejszego, niż sytuacja, w której element interfejsu zmienia położenie w czasie gdy próbuje go wcisnąć.
Wymaganie mnóstwa uprawnień
Nowoczesne systemy operacyjne, a w szczególności te mobilne, chronią naszą prywatność przed twórcami aplikacji. Jednym z narzędzi, które to umożliwiają, jest system uprawnień. Użytkownik musi wyrazić zgodę na dostęp do kamery, plików na urządzeniu, wykonywania połączeń itd.
Nie wszystkie uprawnienia są oczywiste, każdy zrozumie, dlaczego program do robienia zdjęć wymaga dostępu do aparatu. Czemu jednak aplikacja androidowa łącząca się przez bluetooth z innymi urządzeniami wymaga dostępu do lokalizacji? Takie przypadki musimy odpowiednio uzasadnić — oczywiście nas to nie dotyczy, bo chcemy, aby nasza aplikacja była kiepska.
Kolejnym ważnym elementem jest moment pytania o pozwolenia. Wyobraźmy sobie program do przeglądania koncertów w naszej okolicy, w której jedną z funkcji jest dodawanie informacji o koncercie do kalendarza. W naszej słabej aplikacji nie możemy prosić o dostęp do kalendarza dopiero w sytuacji, gdy użytkownik będzie chciał dodać tam informacje o koncercie w jego mieście. Musimy wymagać tego uprawnienia tuż po tym, jak użytkownik otworzy naszą appkę po raz pierwszy, tak żeby nie był w stanie wiedzieć, po co nam dostęp do jego kalendarza.
Obowiązkowo należy rozważyć również przypadek, w którym korzystający z naszego oprogramowania nie zgodzi się na wymagane przez nas pozwolenie. Co w takiej sytuacji robić? Dobre aplikacje w takiej sytuacji informują użytkownika, jakie funkcjonalności przestaną działać, jednak nadal może on korzystać z pozostałej części. Złe natomiast, blokują działanie całego programu jeśli chociaż jedno uprawnienie nie zostanie przyznane. Często jest to wynikiem pójścia na skróty przez twórców, ponieważ łatwiej jest raz zapytać o uprawnienia, niż pamiętać na każdym kroku, że może nam brakować jakiegoś pozwolenia.
W androidzie 13 została wprowadzona fajna funkcjonalność pozwalająca zwiększyć zaufanie do naszej aplikacji przez użytkowników. Z poziomu kodu możemy odwoływać wcześniej przyznane uprawnienie. Na przykład aplikacja bankowa wymagająca selfie do wzięcia kredytu może odwołać przyznane uprawnienie do aparatu, gdy proces uzyskiwania kredytu zostanie zakończony. Co zrozumiałe, żadna słaba aplikacja nie powinna z tego korzystać.
Przesadzone uspójnianie interfejsu pomiędzy platformami.
W dzisiejszych czasach każde liczące się oprogramowanie powinno wspierać co najmniej dwie platformy mobilne: Android oraz iOS, dobrze też, aby wersja przeglądarkowa była dostosowana na wersje mobilne.
W tym kontekście niepodważalnym antywzorcem jest zaprojektowanie jednego interfejsu na wszystkie platformy. Każdy z systemów ma swoje unikalne cechy, również użytkownicy korzystają z tych urządzeń w nieco inny sposób. Na przykład urządzenia z Androidem mają fizyczny przycisk (lub systemowy gest) „wstecz”, natomiast aplikacje iOS muszą zapewnić ten element w swoim interfejsie.
Aby nasza aplikacja była beznadziejna, musimy koniecznie implementować wzorce, które nie są znane na danej platformie. Na przykład w aplikacji androidowej usuwanie elementu z listy powinno następować po przesunięciu go na bok, zamiast kliknięcia opcji w menu kontekstowym, które otwiera się po dłuższym naciśnięciu na ten element. Podobne rzeczy musimy robić również w drugą stronę, aby użytkownicy korzystający z wersji na platformę iOS mieli podobne problemy.
Brak ciemnego motywu
Będąc w temacie UI nie możemy zapomnieć o kolejnej ważnej kwestii, jaką bez wątpienia jest ciemny motyw. Obecnie każda licząca się aplikacja ma dwa warianty interfejsu: jasny oraz ciemny. My jednak wyłamiemy się z tego trendu. Nie ma znaczenia, że ciemny motyw jest bardziej przyjazny dla naszego wzroku gdy korzystamy z telefonu po zmroku, zignorujmy też fakt, że wyświetlacze OLED zużywają mniej energii, gdy wyświetlają czerń (w ekranach OLED, piksele, które mają wyświetlić kolor czarny, są „wyłączane”). Zarówno Android jak i iOS oferują systemowe wsparcie dla różnych motywów, jednak nawet to nie zmusi nas do implementacji tak zbędnej funkcjonalności.
Kilka słów na koniec
Mam nadzieję, że te porady pozwolą wam unikać błędów podczas projektowania aplikacji mobilnej. Na pewno nie jest to zamknięta lista, jest jeszcze sporo rzeczy, które mogą sprawić, że użytkownicy nie polubią waszego oprogramowania.
Na szczęście w Mindbox, mamy wielu specjalistów, którzy doskonale wiedzą, jak stworzyć oprogramowanie przyjazne użytkownikom i jakich błędów należy unikać.
Paweł Dedio
Android Tech Lead
Porozmawiajmy!
a my pomożemy Ci wdrożyć najnowsze rozwiązania!
Podobne wpisy:
Bootcamp programistyczny – czym tak właściwie jest oraz kto powinien się nim zainteresować?
Sprawdź jakich informacji nie zamieszczać w CV
Jakie języki programowania będą poszukiwane w 2023 roku?
Ile trwa okres „juniorski” na różnych stanowiskach?