Flutter – szybko, tanio, ale czy użytecznie?
Rozwiązania cross platformowe, czyli takie które przy użyciu odpowiedniego frameworka powstają jednocześnie na systemy Android i iOS, stają się coraz popularniejsze. Popularność najnowszego z nich, przebojem zdobywającego rynek rozwoju aplikacji mobilnych, Fluttera, rośnie z roku na rok – w 2019 roku używało go 30% programistów korzystających z podobnych rozwiązań. Wtedy było to niewiele więcej niż zapomnianej już dziś Cordovy czy Xamarina. Dziś natomiast przegonił on już królujący dotąd React Native.1 Dart, język programowania używany we Flutterze, świetnie radzi sobie również w rankingach popularności na tle innych rozwiązań mobilnych. Nadal wyprzedza go Kotlin (natywny język na platformę Android), jednak jest on przed Swiftem (dedykowany dla iOS).2
W jaki sposób ten narastający trend wpływa na rozwój i jakość dostarczanych aplikacji mobilnych?
źródło: https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
Dlaczego Flutter wymaga dużo większej opieki badawczej wytworzonych w nim produktów niż choćby jego główny konkurent, React Native? W końcu ten drugi istnieje na rynku od 9 lat, od 7 można go używać powszechnie i kwestia większej potrzeby badań się nie pojawiała.
Głównym problemem jest podejście do i możliwość rozróżnienia natywnych rozwiązań w przypadku obydwu framworków. Dużo korzystniej wypada tu React Native, którego filozofia zakłada adaptację pod platformę. W praktyce oznacza to, że każdy dodany komponent jest rozpoznawany automatycznie dla każdej platform, na której będzie renderowany, nie ma tu więc zagrożenia o brak spójności z platformą. Ten sam problem wygląda już gorzej w przypadku Fluttera. W nim, aby rozróżnić np. switche, potrzebne jest użycie dedykowanych paczek i tu odpowiedzialność za to, czy finalny produkt będzie spójny z platformą, spada już w dużej mierze na zespół. I tu może pojawić się problem.
Flutter jest szczególnie polecany jako narzędzie idealne dla rozwiązań startupowych, którym zależy na szybkim wydaniu MVP i dzięki temu pozyskiwaniu grup innowatorów i wczesnych naśladowców, co z kolei (miejmy nadzieję) pozwoli na pozyskanie inwestorów i dalszy rozwój produktu. Jest to zrozumiałe, jeśli weźmiemy pod uwagę koszt zbudowania aplikacji mobilnej i utrzymywania dwóch środowisk w przypadku korzystania z narzędzi natywnych i porównamy go z możliwościami, jakie na tym polu daje Flutter. Dzięki niemu ten sam produkt możemy zbudować dużo mniejszym zespołem, który będzie miał jednakowe wymagania, a więc i dużo taniej i sprawniej. Jednak jednocześnie, tam, gdzie pośpiech, tam pojawiają się kłopoty. Jak wiemy, przepaść, która znajduje się pomiędzy grupami wczesnych naśladowców i wczesnej większości jest miejscem, w które łatwo wpaść, i mimo że pierwsze dwie grupy są raczej wyrozumiałe na niedoskonałości pierwszych wersji produktu, to ich opinia jest dla każdego twórcy kluczowa i wymaga troski — jeśli oczywiście nie chcemy skończyć na dnie przepaści. To właśnie w tym miejscu rynek mówi — “sprawdzam!“ i weryfikuje dotychczasową wizję produktu i jego propozycję wartości.
Jednak czy rzeczywiście zachowanie spójności na systemach jest takie ważne, aby przeskoczyć nad przepaścią? Przyjrzyjmy się bliżej cechom obydwu platform oraz ich użytkownikom.
Już w 2016 roku badanie przeprowadzone przez brytyjskie uniwersytety w Lincoln, Lancaster oraz Hertfordshire wykazało, że użytkownik korzystający z iPhone’a, oraz dowolnego smartfona Androidowego to dwie bardzo odrębne persony. Użytkownikami, a raczej użytkowniczkami iPhonów są raczej młode kobiety, uznają swój smartfon za symbol statusu, ekstrawertyczki, osoby raczej nieskromne. Z kolei posiadacz Androida to mężczyzna w średnim wieku, nieskoncentrowany na swoim statusie społecznym, bardziej szczery i ugodowy od użytkownika produktu Apple.3 Podobne badanie przeprowadzone przez OnePoll w 2018 roku w Stanach Zjednoczonych pokazało, że posiadacz Androida zarabia mniej, wydaje mniej na technologię czy odzież, posiada średnio mniej bliskich przyjaciół, wysyła mniej wiadomości, robi mniejszą ilość selfie i spędza o ponad godzinę mniej czasu ze swoim telefonem od posiadacza iPhone’a. Jedyną cechą, która wydaje się łączyć obie grupy, jest fakt, że tak jedni jak i drudzy wybraliby psa zamiast kota jako swoje zwierzątko domowe.4
| iOS | Android |
|
|
źródło: OnePoll 2018 (https://www.studyfinds.org/survey-iphone-owners-happier-more-money-friends-android/)
Wszystko to powoduje, że nawet jeśli projektujemy produkt mający cel dla jednej persony, nadal powinniśmy pamiętać, że faktycznie persony są dwie, niepodyktowane przez cel produktu, a przez rynek.
Przejdźmy teraz do samej interakcji z aplikacją i tego, do czego użytkownicy są przyzwyczajeni, a więc użyteczności. Nie bez powodów na grupy zwolenników produktów Apple, czy określonych marek związanych z Androidem mówi się w kategoriach fandomów. Obydwa systemy rozwiązują ten sam problem, oferując zupełnie inną wartość i zapewniając odrębne doświadczenie użytkownika.
Pierwszą przeszkodą dla obydwu grup będzie na pewno różny sposób nawigacji w obydwu systemach — a więc finalnie i w aplikacjach. Weźmy np. naturalny gest dla właścicieli iPhone’ów — swipe to dismiss — używany, kiedy chcemy usunąć element z listy. Jest on kompletnie nieznany posiadaczom telefonów z Androidem, przyzwyczajonych raczej do komponentów wysuwanych przy użyciu gestu longpress, który to z kolei dla użytkowników iPhone’ów jest zarezerwowany dla nieobecnego na Androidzie haptic touch, pozwalającego na szybki podgląd np. wiadomości e-mail czy zawartości linka.
To nie wszystko. Podstawowa i najbardziej kluczowa dla aplikacji nawigacja, według wytycznych Apple, powinna być zawarta w tab barze na dole ekranu. W przypadku Androida mamy tu, oprócz bottom navigation bar również hamburger menu, floating action button z możliwością dodatkowego rozwijania, umieszczenie wyszukiwarki w prawym górnym rogu ekranu itp.
Przy tym wszystkim różne zachowania przy scrollowaniu stron, wskazywania hierarchii kolejnych widoków, wpisywaniu tekstu, dwa diametralnie od siebie różne komponenty wyboru daty, konieczność pogodzenia ze sobą materiałowych backdrop, chipsów czy snackbarów z typowymi dla Human Interface page controllerami, toolbarami, stepperami czy obecnymi jedynie na tabletach popoverami brzmią już niczym błahostka. Przynajmniej dopóki nie przyjdzie nam faktycznie się za to zabrać, bo wtedy robi się z tego realny kłopot.
To wszystko powoduje, że tak użytkownik iOS jak i Android, korzystając z tej samej aplikacji na nieznanym dotąd dla siebie systemie, będzie czuł się zagubiony a tym samym jego doświadczenie i szansa na satysfakcjonujące korzystanie z produktu znacząco spadnie.
W aplikacji Spotify (natywnej) aby polubić utwór użytkownik iOS (lewy ekran) wykonuje gest swipe na utworze, natomiast użytkownik Android potrzebuje dedykowanego przycisku na playerze
Dodajmy do tego, aby nie było zbyt spokojnie, perspektywę projektanta mierzącego się z fragmentacją urządzeń Androidowych a przy tym niezliczoną ilością rozmiarów ekranów, różnymi wymaganiami bazowymi platform (różna minimalna wielkość touchpointa, typografię, różne jednostki miar i wychodzi na to, że pogodzenie tak potrzeb użytkowników jak i wymagań platform staje się zadaniem dość karkołomnym. Oczywistym jest, że każdy szanujący się UI designer uwzględni wszystkie te wyzwania przy tworzeniu design systemu dla produktu oraz szukaniu rozwiązań dla funkcji i ścieżek przewidzianych w produkcie, jednak bez choćby podstawowych badań grupy docelowej będzie to wybranie rozwiązań optymalnych pod kątem reużywalności, szybkości implementacji, czy też ogólnoprzyjętych dobrych praktyk.
Aby nie był gołosłownym, postanowiłem sprawdzić, w jaki sposób designerzy pracujący z aplikacjami Flutterowymi podchodzą do tworzenia ich UI.
W badaniu ilościowym przeprowadzonym w grupach zrzeszających designerów zadałem pytania o sposób tworzenia layoutów aplikacji Flutterowych. Odpowiedzi nie dają jasnego obrazu działań środowiska designerskiego na ten problem.
- 10% respondentów odpowiedziało, że projektuje aplikacje na obie platformy dla aplikacji Flutterowych
- 20% tworzy jeden design, ale daje podgląd elementów natywnych
- 20% tworzy jeden design a w miejscach spornych pozostawia notatkę ze wskazówkami
- 20% tworzy jeden design i nie zwraca uwagi na rozwiązania w elementach natywnych
- 30% stara się projektować UI w sposób możliwie jak najbardziej uniwersalny.
Widać tu, że większości respondentów przyświeca idea tworzenia interfejsu z myślą o użytkowniku końcowym i stara się o albo rozwiązania zadowalające obie strony, albo o to, aby implementacja odbyła się bezproblemowo. Tworzenie całkowicie customowego UI jest czasochłonne, wymaga od designera doskonałej znajomości dobrych praktyk i wymagań platform, ale również komunikacji z programistami o tym, czy dane rozwiązanie jest wygodne, szybkie i możliwe w implementacji.
W grupie badanych, w 25% przypadków design aplikacji, z którymi pracowali, był od początku do końca customowy, 75% ankietowanych przyznało, że był to customowy design z elementami natywnymi takimi jak buttony czy date pickery. Nikt z ankietowanych nie zaprojektował dotąd w 100% natywnej aplikacji Flutterowej, a jednocześnie jedynie 13% badanych stwierdziło, że zdarzyło im się aby aplikacja Flutterowa, którą tworzyli, posiadała nietypowe dla platform rozwiązań jak np. Materiałowy date picker zaimplementowany na iOS, czy nawigacja iOS wdrożona w aplikacji Androidowej.
I te wyniki są dość budujące, wychodzi na to, że z perspektywy projektantów produkty Flutterowe nie posiadają rozwiązań, które użytkownik końcowy odebrałby jako obce.
Niestety, to perspektywa i doświadczenie jedynie jednej strony, po drugiej jest nieco mniej optymistycznie.
Dla posiadania lepszego oglądu, podobne badanie ilościowe przeprowadziłem w grupach zrzeszających programistów Flutter.
Zapytani, o jakiego to typu design posiadały dotąd aplikacje Flutterowe, z którymi pracowali, odpowiadali:
- 27% – w pełni customowy
- 20% – w pełni natywny
- 53% – customowy z elementami natywnymi, takimi jak nawigacja, przyciski itp.
I to pokrywa się z odpowiedziami designerów o tym, w jaki sposób projektują te aplikacje.
Kolejnym pytaniem było to, w jaki sposób programiści implementują design, jeśli jest on stworzony wyłącznie na jedną z platform.
- 69,2% odpowiedziało, że tworzy go zgodnie z designami
- 30,8% przyznało, że w takim wypadku rozróżnia natywne elementy tam, gdzie to konieczne na własną rękę.
W tym samym momencie, z doświadczenia programistów, aż 66% aplikacji, które rozwijają, są projektowane na wyłącznie jedną z platform i nie ma wskazówek dotyczących rozwiązań w miejscach, gdzie występują elementy natywne, takie informacje otrzymuje jedynie 23% programistów. 8% respondentów ma ten komfort, że otrzymuje designy zrobione na obydwie platformy. I tu pojawia się duża rozbieżność z danymi pozyskanymi od projektantów.
Porównując więc odpowiedzi designerów i programistów otrzymujemy obraz, w którym ogromna ilość projektów Flutterowych może nie uwzględniać potrzeb użytkowników danej platformy i jest jednak tworzona według uznania programisty.
Odpowiedzi designerów (górny wykres) oraz programistów różnią się w kwestii tworzonych i otrzymywanych designów aplikacji Flutterowych
Już na samym początku przytoczyłem główne cechy Fluttera. Dobry dla MVP, przyspieszający development. W takich wypadkach nie może dziwić, że chcący jak najszybciej działać programista, nie mając wskazówek dotyczących UI i widząc, że jest on zaprojektowany na jedną z platform (tu zaryzykuję tezę, że będzie to design iOSowy jako pod wieloma względami szybszy do wykonania) uzna, że tak zwyczajnie ma być i skończymy z aplikacją, która dla użytkownika Androidowego będzie niewygodna w użyciu. Tu dla zobrazowania skali problemu warto przytoczyć, że obecnie ponad 70% użytkowników smartfonów to użytkownicy właśnie systemu stworzonego przez Google.5 Przyjmując więc, że produkt, który tworzymy, nie trafia do jakiejś hermetycznie zdefiniowanej grupy docelowej gdzie 90% użytkowników aplikacji to posiadacze iOS, dochodzimy do miejsca, gdzie blisko trzy czwarte osób korzystających z produktu ma szansę na otrzymanie czegoś, co nawet jeśli rozwiąże ich problem, będzie niewygodne w użyciu i może przez to przynieść dużo mniejszą niż oczekiwana wartość.
Czy da się tego uniknąć? Oczywiście, że tak. Jednym ze sposobów jest tworzenie w całości customowego layoutu spełniającego wymagania platform. Tak, jak wynika z badania, radzi sobie 30% designerów. Jednak stworzenie dobrego customowego designu, który będzie nie tylko ładny, ale też po implementacji funkcjonalny to skomplikowany proces. W środowisku, w którym zależy nam na szybkim rozwoju produktu, nie zawsze może być na to czas i „mieć” może wygrać z „być”. Do tego należy przyznać, że nie każdy produkt wymaga tworzenia customowego designu i może to być zwyczajnie przesada. W takich wypadkach nawet okrojony proces badawczy określający już na samym początku rozkład grupy docelowej pomiędzy użytkowników platform pozwoli zbliżyć nas do odpowiedzi, na jakich to rozwiązań oczekują nasi odbiorcy. To pozwoli zaprojektować aplikację z uwzględnieniem tych potrzeb i stworzenie jej w taki sposób aby finalnie tych zaskoczeń nie było, czy to w aplikacji customowej, czy zbliżonej do doświadczenia natywnego. Jeśli badania wskazały nam grupę, w której rozkład użytkowników nie przeważa wyraźnie na żadną ze stron lub zwyczajnie chcemy zaopiekować się każdym, jak należy, czy może z takich, czy innych powodów nie było czasu na badania (znów wchodzimy w „mieć” czy „być”, Erich Fromm nie wiedział, jak bardzo pisał o developmencie), wtedy testy użyteczności na prototypach hi-fi są tym, co potwierdzi nam kierunek obrany przez designera i zweryfikuje jego propozycje rozwiązań. Obie te rzeczy (lub w przypadku braku czasu choćby jedna!) zapobiegną zrzucaniu na karb programisty podjęcia decyzji o tym, co finalnie ma dostać użytkownik i w jaki sposób będzie on korzystał z aplikacji.
Wielu powątpiewa w rozwój Fluttera w momencie wydania jego pierwszej stabilnej wersji. Pojawiały się głosy, że jest to napompowany marketingiem balonik i prędzej czy później pęknie z hukiem. Obecnie framework ma już trzecią wersję, jego społeczność rośnie z dnia na dzień. Flutter kusi świetnymi wynikami w metrykach czasowych i wydajnościowych. O ile na początku brakowało w nim wielu paczek pozwalających na swobodny rozwój dowolnych aplikacji mobilnych, tak dziś ta granica się przesuwa i dzięki Flutterowi można coraz więcej. Nie mniej jednak marketing zbudowany wokół odmian słowa „szybko” we wszystkich przypadkach i trybach spowodował, że do rozwoju aplikacji przy pomocy Fluttera wkradła się makdonaldyzacja, stawiająca za cel szybki i ładny efekt. Jednak czy aplikacja mobilna, której usunięcie zajmuje przecież kilkakrotnie mniej czasu niż zainstalowanie, której rozwój i promocja pochłaniają spore pieniądze, da wartość jedynie z tego, że pojawi się na rynku szybko i będzie ładna i czy dzięki temu unikniemy wylądowania na dnie przepaści?
