Unikanie złych praktyk w projektowaniu iOS i Android

Ile przeciętnych osób widziałeś używając jednocześnie urządzeń z systemem iOS i Android? Oficjalne liczby według tego badania wahają się od 10% do 20%, ale liczba ta obejmuje również użytkowników komputerów Mac, a nie tylko użytkowników telefonów komórkowych. W praktyce ludzie mają tendencję do używania tylko jednego telefonu lub tabletu przez określony czas. Jeśli zdarzy im się używać dwóch urządzeń, częściej niż nie, oba będą działały z tym samym systemem operacyjnym.

Oznacza to, że nie ma potrzeby tworzenia idealnych do piksela kopii projektu interfejsu użytkownika aplikacji, próbując dostosować się do obu platform, wraz z dziesiątkami różnych rozmiarów ekranu, współczynników proporcji i rozdzielczości (nie wyświetlajmy nawet wycięć, pasków stanu , paski nawigacyjne, przyciski sprzętowe itp.).

Wręcz przeciwnie, nawet jeśli użytkownik przegląda tę samą aplikację zarówno na iOS, jak i na Androidzie, prawdopodobnie wolałby doświadczyć natywnego odczucia na obu z nich. Dlatego podejście wielu kierowników projektów i właścicieli produktów w zakresie rozwoju mobilnego jest często nieoptymalne i wymaga dopracowania.

Dlaczego to nadal stanowi problem?

Ale dlaczego interesariusze i menedżerowie wciąż podejmują decyzje, które często obniżają komfort użytkowników, a tym samym podważają ich własne produkty? Było to zrozumiałe na początku dekady, kiedy wszyscy wciąż zmagali się z rozwojem iOS i Androida, ale ten irytujący problem utrzymuje się do dziś.

Głównym powodem pojawienia się tej sytuacji może być obawa wyrażana przez kierowników projektów i programistów mobilnych, że ich użytkownicy mogą się pomylić, jeśli zobaczą tę samą aplikację na innej platformie i zdadzą sobie sprawę, że nie zapewnia ona dokładnie tego samego uczucia i interfejsu użytkownika. Można śmiało powiedzieć, że do pewnego stopnia ten tok myślenia ma sens, ponieważ pewien stopień podobieństwa jest konieczny i mile widziany. Jednak posuwanie się za daleko i, w skrajnych przypadkach, tworzenie dokładnych klonów aplikacji dla różnych platform, w rzeczywistości wyrządza o wiele więcej szkody niż pożytku.

Ostatecznym celem powinno być osiągnięcie odpowiedniej równowagi — nie wymuszaj idealnej spójności pikseli, ale trzymaj się wspólnych pomysłów projektowych i utrzymuj mapę nawigacji aplikacji podobną na obu platformach; zapewniają te same funkcje i ten sam przepływ pracy, ale staraj się trzymać natywnego zachowania, gdy tylko jest to możliwe.

Każdy uwielbia niestandardowe przyciski lub fantazyjne animacje tu i tam, ale natywne elementy są tym, do czego ludzie są przyzwyczajeni i są łatwiejsze i bardziej intuicyjne w użyciu.

Skoncentruj się na użytkownikach, a nie na wyglądzie

Aby znaleźć dobre podejście do rozwiązania tego dylematu, powinniśmy zacząć od końca linii — użytkownika końcowego. Badania mówią nam, że użytkownicy Androida i iPhone'a to bardzo różni ludzie i jeśli dążymy do optymalnego UX, powinniśmy spróbować poznać ich wzorce użytkowania.

Zaczynając od średniego budżetu, ludzie decydują się wydać na technologię miesięcznie ( iPhone: 100,88 USD, Android: 50,83 USD ) , przechodząc przez liczbę selfie, które robią dziennie iPhone: 12, Android: 7 i przechodząc do SMS-ów, które wysyłają każdego dnia iPhone : 57, Android: 26 , łatwo zauważyć, że różnice są znaczne, do tego stopnia, że ​​możemy stwierdzić, że istnieje rozbieżność w zachowaniu, które wpływa na sposób, w jaki ludzie korzystają z ich urządzeń.

Na czym zatem powinniśmy się skupić, projektując aplikacje na obie platformy jednocześnie?

Przede wszystkim, tam gdzie to możliwe, wybieraj elementy natywne. Nawet jeśli używasz platformy wieloplatformowej, większość komponentów jest oparta na czystych widokach natywnych; więc jeśli naprawdę nie potrzebujesz czegoś niestandardowego – trzymaj się podstaw. Ludzie lubią używać tego, do czego są przyzwyczajeni, a Ty zaoszczędzisz trochę czasu na opracowywanie ważniejszych funkcji (i przeglądów kodu!).

Niestandardowe widoki zdecydowanie mogą nadać Twojej aplikacji charakter i wyjątkowość, o ile zachowują te same ogólne pomysły i sposób użytkowania, jak te ogólne — za mało i Twoja aplikacja jest nudna, za dużo i jest niepotrzebnie krzykliwa i trudna w użyciu.

Czasami nawet niewielki dotyk z nieco innym niestandardowym widokiem może zmienić grę w Twojej aplikacji, ale jeśli wypełnisz wszystkie ekrany nowymi elementami, które użytkownicy mogą eksplorować, mogą zostać przytłoczeni i zgubić się podczas szukania ważnych informacji. To nie przypadek, że te drobne akcenty nazywają się „polskie!”

Jak podejść do różnych elementów projektu

Zasadniczo zawsze pamiętaj, że każda platforma ma swoje własne wytyczne projektowe. Zestaw podejść Androida wkracza na Material Design, podczas gdy Apple ufa Human Interface Design. Przechodząc do konkretnych elementów, które powinniśmy wziąć pod uwagę planując nasz projekt, należy skupić się na kilku głównych częściach:

1. Ogólny styl: o ile nie mówimy o aplikacji wieloplatformowej, powinniśmy rozważyć przestrzeganie ogólnych wytycznych dotyczących stylu dla każdej platformy. Ogólnie rzecz biorąc, projekty iOS wydają się być bardziej płaskie, podczas gdy Android stosuje bardziej warstwowe podejście.

   Historycznie rzecz biorąc, platformy mobilne wpływały na siebie nawzajem przez dekadę lub dłużej, a niektóre koncepcje Androida można łatwo dostrzec w iOS i na odwrót. Na przykład, gdy czujniki odcisków palców zaczęły pojawiać się w świecie mobilnym, producenci eksperymentowali ( i nadal eksperymentują) z rozmiarem i lokalizacją czujnika, starając się, aby był wygodny dla jak największej liczby użytkowników. W tym samym czasie projektanci i programiści również dostosowywali się do nowej funkcji, więc ostatecznie elementy wizualne i opinie są w większości identyczne na obu platformach (z wyjątkiem niektórych egzotycznych podejść).

2. Specyfika sprzętu i wzorce nawigacji: jest to prawdopodobnie jeden z najbardziej uderzających przykładów negatywów bezpośredniego klonowania Twojej aplikacji. Większość urządzeń z Androidem nadal ma komfort dodatkowego paska nawigacyjnego (niezależnie od tego, czy jest to sprzęt, czy oprogramowanie na różnych urządzeniach), w tym przycisk Wstecz. Ponieważ iOS tego nie zapewnia, aplikacje muszą rozważyć, gdzie i kiedy umieścić przycisk Wstecz, zwykle w lewym górnym rogu każdego ekranu.

   Przycisk menu (w tym przykładzie kwadratowy przycisk) może również zapewniać dodatkowe funkcje dla aplikacji na Androida. Gdzie to ma znaczenie? Na przykład podczas otwierania menu ustawień lub podobnej funkcji nawigacji.

   

   Do niedawna iPhone'y zawierały również tradycyjny przycisk Home firmy Apple, ale od czasu wprowadzenia iPhone'a X został on odsunięty na bok, a przepływ w iOS opiera się teraz na gestach. Jeśli przeciąganie jest ważną częścią Twojej aplikacji, upewnij się, że zapewniasz wystarczającą poduszkę między krawędzią kontenera aplikacji a obszarem przesuwania, na który pozwalasz, aby uniknąć trudnych zbiegów okoliczności.

   Jeśli Twoja aplikacja opiera się na funkcjach specyficznych dla sprzętu, takich jak Bluetooth, NFC lub słuchawki przewodowe, zawsze należy wziąć pod uwagę zakres różnych obsługiwanych specyfikacji sprzętu. Postaraj się przekazać użytkownikowi odpowiednią informację zwrotną, gdy próbuje on wchodzić w interakcję z określoną funkcją. Jeśli z jakiegoś powodu musisz zapewnić funkcję specyficzną dla sprzętu tylko dla jednej z dwóch platform, poinformuj użytkowników o różnicy.

3. Elementy globalne (paski stanu, nagłówki itp.): elementy, które pojawiają się na wszystkich stronach projektu, takie jak pasek stanu, nagłówek nawigacyjny itp., powinny ściśle dążyć do zapewnienia natywnego odczucia, więc nie powinniśmy się zmieniać wysokość i styl tych barów. Istnieją niewielkie różnice w stylizacji elementów globalnych na obu platformach. Na przykład Android używa tekstu wyrównanego do lewej, podczas gdy iOS wybiera wyśrodkowany tytuł. Pasek stanu jest komponentem natywnym, więc nie musisz się nim martwić, ale podczas planowania górnej części aplikacji pamiętaj o różnych wycięciach i proporcjach ekranu.

   

   

4. Nawigacja: stare dobre wytyczne Google Material Design sugerują korzystanie z nawigacji w menu szuflad w aplikacjach na Androida, z nawigacją dolną w tyle, ale nadal jest to realną opcją. iOS ma tendencję do korzystania wyłącznie z paska kart, który może ograniczać opcje nawigacji na najwyższym poziomie, ale zapewnia wyraźny widok wszystkich naraz. W tym przypadku oba systemy operacyjne zapewniają podobne komponenty, których można używać w zależności od złożoności aplikacji, ale różnica wizualna w obu systemach powinna naturalnie Cię skierować — na przykład globalny pasek nawigacyjny w Androidzie i jego brak w iOS.

   Gwałtowna ewolucja sprzętu mobilnego w ostatnich latach wprowadziła wiele zmiennych i niewiadomych: telefony pełnoekranowe, wycięcia o różnych kształtach i rozmiarach, zwiększone wykorzystanie gestów do nawigacji na całym urządzeniu i tak dalej. Wszystkie te zmiany zapewniają użytkownikowi bezprecedensową moc, ale mogą być uciążliwe, gdy próbujemy rozgryźć wszystkie przypadki użycia danego ekranu w naszej aplikacji. Biorąc pod uwagę te obawy, dobrym sposobem na uniknięcie nieporozumień dla naszych użytkowników byłoby zachowanie prostych i spójnych wzorców nawigacji, bez przeciążania aplikacji zbyt wieloma gestami, paskami i opcjami przesuwania w wielu kierunkach.

   

5. Typografia: obie platformy mają domyślne kroje pisma — San Francisco dla iOS i Roboto dla Androida. O ile nie wybierasz niestandardowej czcionki, ściśle dopasowanej do ogólnego stylu aplikacji, powinieneś trzymać się wartości domyślnych. Pamiętaj, że użytkownicy mogą zmienić domyślną czcionkę systemową i nie wpłynie to na żadne widoki, które dostosowałeś za pomocą określonego kroju pisma.

   Na przykład użytkownicy z dysleksją mogą nie mieć najlepszego czasu w Twojej aplikacji, jeśli zastąpili domyślną czcionkę czcionką, która konkretnie odpowiada ich potrzebom. Jeśli wspierasz użytkowników, którzy mogą używać czcionek innych niż łacińskie (takich jak cyrylica, arabski itp.), upewnij się, że niestandardowe czcionki również zawierają te dodatkowe znaki. Jeśli interesujesz się grami, prawdopodobnie widziałeś tablice wyników z wysokimi wynikami osiągniętymi przez rosyjskich graczy, których nazwiska wyróżniają się inną czcionką. To tylko drobny błąd popełniony w fazie rozwoju, a nie „funkcja” dla konkretnych graczy, i chociaż prawdopodobnie nie sprawi, że użytkownicy porzucą Twoją aplikację, z pewnością może to skutkować pogorszeniem doświadczenia użytkownika lub skutkować skargami lub złymi recenzjami.

   

6. Inne komponenty: przyciski, przejścia między ekranami, animacje, mikrointerakcje, arkusze akcji, alerty i wszystkie inne typy kontroli przepływu wykraczają poza zakres tego artykułu, ale powinny być zgodne z ogólną zasadą, którą zastosowaliśmy do tej pory do innych elementów projektu — obie platformy zniechęcają do nadużywania elementów niestandardowych, ponieważ mogą rozpraszać i dezorientować użytkownika; jeśli chodzi o design, dla wielu użytkowników pierwsze wrażenie jest zwykle ostatnie i dlatego tak ważne jest, aby od samego początku przyciągnąć uwagę użytkowników i sprawić, by poczuli się, że tak powiem, jak w domu.

W prawdziwym świecie można zobaczyć kilka bardzo popularnych wyjątków od omówionych przez nas zasad — aplikacje na iOS, które są zgodne z wytycznymi Material Design i niektóre produkty na Androida, korzystające z wytycznych Apple Human Interface, ale te aplikacje mają swój własny, sprawdzony styl. Użytkownicy są zaznajomieni z aplikacjami i ich wyglądem, więc dla nich sensowne jest zapewnienie nieco bardziej niestandardowego odczucia.

Podejście wieloplatformowe wykonane prawidłowo

Z drugiej strony, jeśli Twój projekt opiera się na rozwiązaniu wieloplatformowym (takim jak React Native, Flutter, Xamarin itp.), powinieneś zastanowić się, jaka byłaby główna platforma, na której chcesz się skoncentrować i od tego zacząć.

W ostatnich latach te nowe struktury zapewniły ogromną poprawę produktywności w tworzeniu aplikacji wieloplatformowych. Coraz więcej firm przechodzi na ten paradygmat rozwoju, ponieważ zapewnia on krótszy czas wprowadzania na rynek, lepszą opłacalność i mniej barier technicznych, a kluczowymi wadami są ograniczone wsparcie funkcji i nieoptymalny UX w niektórych przypadkach.

Podczas gdy praktycznie wszystkie starsze rozwiązania do rozwoju wieloplatformowego były oparte na widokach internetowych i dlatego doświadczały poważnych problemów z responsywnością na wielu urządzeniach, obecnie możemy używać komponentów natywnych nawet w podejściach wieloplatformowych. Ta znacząca poprawa wpłynęła na rynek na wiele sposobów i zbliżyła wszystkie platformy mobilne o jeden krok do ujednolicenia wizualnego doświadczenia użytkownika na różnych urządzeniach i platformach.

Jeśli zdecydujesz się na rozwiązanie wieloplatformowe, możesz zacząć jak w standardowej aplikacji natywnej, budując szkielet swojej aplikacji. Po skonfigurowaniu głównych priorytetów (ustawienie podstawowych zależności, budowanie MVP, osiągnięcie kamieni milowych specyficznych dla projektu, wydanie pierwszej wersji itp.), możesz łatwo oddzielić główne projekty dla dwóch aplikacji, korzystając z platformy- konkretne narzędzia udostępniane przez poszczególne ramy. W zależności od wielkości zespołu i dostępnych ram czasowych możesz nawet rozważyć włączenie tych poprawek w wersji 1, aby uniknąć zamieszania w przyszłości, gdy rzeczy nie będą już wyglądać tak samo w danej wersji platformy.

Po wszystkim, co zostało powiedziane i zrobione, powinieneś ocenić, które z tych zasad będą obowiązywać w Twojej aplikacji. Jak w prawie każdym przedsięwzięciu w naszej branży, powinieneś starać się postępować zgodnie z wytycznymi, jednocześnie nieznacznie dostosowując je do swoich konkretnych potrzeb. Na przykład, jeśli nawigacja szufladowa jest tym, co naprawdę ma sens w przypadku prostej aplikacji z pięcioma ekranami, nie musisz wymyślać skomplikowanych rozwiązań dla każdej platformy. Spraw, aby użytkownik był oczywisty i łatwy w rozpoznawaniu niestandardowych przycisków i narzędzi, niezależnie od tego, czy są to kluczowe elementy, czy tylko drobne dostosowania.

Dobry projekt szanuje nawyki użytkownika

Podsumowując, możemy powtórzyć coś, co już wiemy — dobry projekt to projekt, który szanuje przyzwyczajenia użytkowników w każdym systemie operacyjnym. Tylko odrobina dopracowania na końcu może zrobić różnicę między przeciętną a świetną aplikacją.

Często Twoja aplikacja nie zapewnia wystarczającej liczby unikalnych funkcji, aby przekonać użytkowników samą treścią. Większość ludzi opisze swoją decyzję o wyborze jednego produktu zamiast drugiego „intuicyjnie”. Ta kategoria użytkowników opiera swoje wybory przede wszystkim na tym, jak się czują podczas korzystania z aplikacji, pośrednio oceniając responsywność, ogólny wybór stylu, paletę kolorów i poszczególne elementy wizualne, które widzą na ekranie.

Dlatego postaraj się, aby Twój produkt wyróżniał się nie tylko niesamowitymi cechami, ale także wysokiej jakości opakowaniem, które odpowiada jakości świadczonych usług.