PWA vs Native - czy potrzeba więcej w 2021 roku?

Witam.
Ostatnio zastanawiało mnie jakie mam korzyści z natywnej aplikacji. Lubię Fluttera i przyjemnie się w tym piszę ale... Czy to nie jest tak, że teraz PWA, albo ogólnie web ma sporo możliwości, które w zupełności wystarczą do poprawnej pracy/funkcjonowania?

DANE/KONFIGURACJA

1. W natywnych mamy pełny dostęp do plików i możliwość tworzenia plików konfiguracyjnych, baz danych SQLite itp
2. W webie mamy: cookies, web storage oraz indexedDB

DOSTĘPY

1. W natywnych mamy pełny dostęp do hardware'u ale wykorzystujemy go tylko gdy aplikacja ma taką potrzebę
2. WHAT WEB CAN DO TODAY? oraz What PWA Can Do Today

INTERNET

1. Natywne mogą pracować offline. Facebook tutaj jest dobrym przykładem cache'owania offline.
2. Jest Service Worker do pracy offline ale on działa w określonych przypadkach dobrze.

SKLEP/AKTUALIZACJE

1. W natywnych wiadomo. Największym problemem jest iOS. Google nawet dobrze to znosi. Płacisz za deweloperkę.
2. Omijasz sklep, aktualizuje się "samo", twoim kosztem jest tworzenie oprogramowania i hosting.

UŻYTKOWNICY

1. Tak jak już pisałem wyżej. Ja sobie mogę we Fluterze pisać ale tylko na androida. Dobrze wiemy jakie durne zasady ma iOS.
2. Każdy ma dostęp. Może iOS niekoniecznie dobrze obsługuje PWA ale otworzyć web w safari nie powinno stanowić problemu.

PODSUMOWANIE
Wyszło mi, że PWA przegrywa z native tylko w kwestii pracy offline, chociaż to też bym podciągnął pod wyjątkowe przypadki, tak jak dostęp do hardware'u. Martwi mnie również kwestia zapisywania danych lokalnie. W przypadku natywnych te dane są bardziej trwałe. W przypadku web, wystarczy wyczyścić dane przeglądarki.
Może też moje przypadki powodują, że mam tego typu przemyślenia. Projekty zaczynam od web (.NET Core + Angular). Dlaczego tego tylko nie dostosować do innych urządzeń?

No to wszystko zależy co tak naprawdę się potrzebuje. Za natywnymi aplikacjami przemawia też "natywny" wygląd zależny od systemu operacyjnego (nie wiem, czy Flutter to wspiera). Jak nie potrzebujesz trwałego trzymania danych offlinowych to PWA jest jak najbardziej ok. Moim zdaniem świat będzie szedł w PWA ze względu na koszty i wygodę (odejście od konieczności instalowania aplikacji przez sklepy Play i tym podobne). Ale czy to juz jest ten czas to nie wiem. Np od wczoraj Youtube stał się PWA (https://9to5google.com/2021/01/24/youtube-install-pwa/) - ale nie znam aplikacji (co nie znaczy, że nie ma) typu enterprise, która działa offline i jest PWA (np jakiś CRM).

W przypadku natywnych apek to zarówno google jak i apple biorą 30% od sprzedaży, a jak próbujesz to ominąć poprzez własną stronę to banują. To mnie przekonało do sprawdzenia PWA, bo miałem własny sklep.

Dobrze wiemy jakie durne zasady ma iOS.

A które masz na myśli?

Ja przeszedłem na PWA, ale po drodze musiałem rozwiązać więcej problemów. Z perspektywy całej aplikacji były to dla mnie najtrudniejsze zmiany i ogólnie wiele razy było tak, że coś co mobilnie fajnie się wyświetla to webowo było dużo gorsze, a czasem na linux/chrome ok, ale dla odmiany iphone/safari już dawało ciała.

pan_krewetek napisał(a):

W przypadku natywnych apek to zarówno google jak i apple biorą 30% od sprzedaży, a jak próbujesz to ominąć poprzez własną stronę to banują. To mnie przekonało do sprawdzenia PWA, bo miałem własny sklep.

Kwestią nie jest problem kasy a czasu. Masz apkę w sklepie potrzebujesz zrobić szybki fix i ci od zgniłego jabłka potrafią ją weryfikować przez dwa tygodnie.

@pan_krewetek: Mam na myśli właśnie sprawdzanie przez Apple aplikacji, zatwierdzanie. Nie jestem w stanie pisać na iOSa na Windowsie, muszę mieć Maca. Potwierdzenie, że jestem developerem i chce pisać na iOS... Tragedia.

@UglyMan Co do youtube. Przeszkadzało mi na Windowsie, że muszę mieć otwartą przeglądarkę z YouTube Music. Czasem się zapomniałem i zamknąłem muzykę. Teraz jak jest PWA to mam osobno i problem zniknął.

@AdamWox: Jeżeli twoja aplikacja ma zapewniać działanie offline to PWA to jak strzelanie sobie w stopie bo Quota na storage i system w każdym momencie ci może ją wyczyścić.

Nie mam parcia na offline. Użytkownik chyba nie jest głupi i wie, że jak nie ma neta to nie ma pracy. Tak samo tyczy się większych aplikacji natywnych - whatsapp, poczta, youtube (ma opcje pobierania, ale nie masz pobranego całego youtube'a), netflix itp itd. Owszem, fizyczny plik w natywnej jest solidniejszym rozwiązaniem niż jakieś przeglądarkowe rozwiązania. To wiąże się z tym, że w takim miejscu trzeba trzymać mało ważne dane.

AdamWox napisał(a):

Nie mam parcia na offline.

No ja patrze trochę inaczej: jak już zrobię takiego CRM i jakiś sprzedawca pojedzie sprzedać w środku puszczy białowieskiej to chciałbym, żeby potem to się zsynchronizowało do bazy. Oczywiście wszystko zależy od konkretnej potrzeby i wymagania.

@AdamWox: Powiedz to tym na statkach, platformach i leśnikach ze jak nie ma neta to nie ma pracy xD W dobie wszechobecnego IoT często masz companion apps które mają zbierać np dane z zegarka czy innnych czujników i wysyłać je na serwer. Kolejna sprawa aplikacje, które potrzebują wysokiej jakości obrazów i grafik 1 panorama w wysokiej rozdzielczości potrafi mieć wagę ~100-100MB. I nawet jak pójdziesz w cięcie tego na kafelki to i tak jak użytkownik obróci się pare razy to masz paredziesiat mb ruchu sieciowego co chwile a offline to wszystko musi byc w cachu.

@Schadoow: I tutaj wracamy do wymagań. Nie piszę na statki, platformy i dla leśników. To jest bezdyskusyjne, że pisząc takie aplikację poszedłbym w native.

@UglyMan Miałem taką sytuację. I właśnie przez to musiałem pisać natywną apkę dla klienta, którego przedstawiciel handlowy jedzie do bunkra z metalu i nie ma zasięgu, a musi zapisać ofertę.

@AdamWox: To tak zawężając to wychodzi, że PWA nadaje się do social-mediów, niektórych aplikacji do konsumpcji treści.

Gdy przeglądałem przykładu popularnych pwa, to wnioski jakie wyciągłem to:

• typowe apki na pwa mają dużo mniej animacji w porównaniu z natywnym odpowiednikiem
• gdy sklep ma stronę i chcę mieć jeszcze lepszą responsywność wtedy robi pwa to przeglądania treści tak by userom było łatwiej
• gdy apkę typowy user i tak nie będzie chciał zainstalować np. jaki sens jest mieć osobną apkę natywną do kupowania w sklepie; pod każdy sklep z osobna to takie gorzej niż średnie rozwiązanie

Jak zawsze są wady i zalety pewnych rozwiązań. Jakby się człowiek uparł to i by offline dopracował pod swoje wymagania i działałoby to tak jak w natywnej. Nie twierdzę, że to będzie mądre rozwiązanie. Głupie rozwiązania jak działają to nie są głupie. Jeśli się poświęci czas na oprogramowanie globalnego problemu, który się tyczy wielu projektów to ten czas jest tego warty. Tak jak już było wiele razy tutaj wspomniane - pwa czy native jest zależne od projektu i czasu jaki chce się na to poświęcić. Oszczędzimy czas na pisaniu PWA do www zamiast natywnej ale stracimy czas na ogarnianiu tego z czym natywna radzi sobie bez kombinacji.

Pytanie, czy mając takie narzędzia jak .NET Core, Blazor, Angular, React, Vue, WebAssebly będziemy w przyszłości musieli tylko ogarnąć responsywność i gotowe?

No właśnie problem w tym, że jakby się człowiek nie uparł to ograniczeń jakie nakłada dana przeglądarka nie przezwycięży. "Tylko responsywność" to trochę brzmi jak "tylko zaprogramować aplikację".
Ale pomijac kwestie techniczne IMO to jest zła droga. Inaczej powinna aplikacja zachowywać się na telefonie gdzie jest ograniczona przestrzeń i obsługa jest dotykowa a inaczej w przeglądarce pc/laptopie gdzie obsługa jest myszką. Kolejna sprawa każda platforma ma swój style guide i większość użytkowników przyzwyczaja się do pewnych schematów. I mnie osobiście łamanie schematów jako użytkownika mocno denerwuje. I teraz jeśli chcielibyśmy zapewnić prawidłowy UX pod tymi aspektami wyjdzie nam, że potrzebne nam jest N osobnych widoków jeden dla użytkowników Androida drugi dla użytkowników IOS i trzeci dla użytkowników obsługujących naszą aplikacje myszką. Dla każdego z tych widoków także trzeba zapewnić responsywność i tak na prawdę wspólne zostaje wtedy tylko warstwa "serwisowa/kontrolera".

1. Analityka i zbieranie danych
2. Wydane pieniądze z natywnej aplikacji vs z aplikacji PWA (per user)
3. Prestiż z posiadania natywnej wersji

@Schadoow: No to ja mam nieco inne podejście do UX/UI... Chcesz powiedzieć, że wygląd aplikacji powinien być zależny od platformy? Wydaje mi się, że właśnie oryginalny wygląd powinien zostać zachowany. To jest wizytówka mojej aplikacji. Kwestie myszki i dotyku nie są problemem ale owszem, ta "tylko responsywność" była na wyrost, ponieważ robiłem już osobno na mobilkę w angular-material i był to ten sam projekt co web ale kompletnie inny routing, inne, nowe komponenty itp. Czasowo poszło mi to dużo szybciej niż z natywną, ponieważ nie piszę na mobilki jeśli nie jest mi to potrzebne. Wcale nie trzeba się do czegoś ograniczać. Owszem masz ograniczone pole użytkowania i tabelka raczej się nie zmieści ale robi się wtedy różnego rodzaju inne zabiegi, które nie zmniejszają ilości wyświetlanych danych oraz nie ograniczają funkcjonalności.

@loza_wykletych

1. Ja nie Google. Jeszcze mi to nie potrzebne i mam nadzieje, że nigdy nie będzie
2. Nie rozumiem - wydane pieniądze przez kogo na co?
3. Haha "prestiż" :D

A tak swoją drogą to czemu PWA otrzymało wsparcie ze strony przeglądarek? Przecież im więcej pwa tym mniej natywnych i taki apple czy google powinien tu robić wszystko by tego pwa nie było. Co sprawiło, że te korporacje są takie przychylne temu podejściu?

No właśnie, to jest bardzo dobre pytanie. Biorąc pod uwagę, że taki Chrome jest od Google i wcale nie musieli wspierać PWA. Apple i ich Safari w dalszym ciągu się broni i odwleka pełne wsparcie, bo nie ma z tego kasy.

Odnośnie głównego tematu, to moim zdaniem @AdamWox w zasadzie napisałeś w punkt. Główne wady, to dostęp do niskopoziomowego API (nie tylko hardware a ogólnie mechanizmy rządzące systemem jak np. komunikacja pomiędzy aplikacjami), zapis offline i jak ktoś jeszcze wspomniał, natywne zachowanie aplikacji pod względem UX. Przy czym nie uważam, że to takie błahostki jak zaznaczyłeś, bo relatywnie dużo aplikacji potrzebuje swobody, jeśli chodzi o te kwestie i niestety stają się tym ważniejsze im większa staje się aplikacja.

pan_krewetek napisał(a):

A tak swoją drogą to czemu PWA otrzymało wsparcie ze strony przeglądarek? Przecież im więcej pwa tym mniej natywnych i taki apple czy google powinien tu robić wszystko by tego pwa nie było. Co sprawiło, że te korporacje są takie przychylne temu podejściu?

Przecież Google jest jednym z głównych promotorów PWA i inwestują dużo w tę technologię. Dziwne by było, gdyby ubijali technologię, nad którą aktywnie pracują. Inną sprawą jest to, że nie ma sensu doszukiwania się sensu w działaniu Google. Zespoły Androida, PWA i Fluttera można traktować jak praktycznie osobne firmy, które nie mają za specjalnie skoordynowanej pracy i celów, tylko mają swoje własne. Co jest w zasadzie najsmutniejsze, bo Google powinien zainwestować w to, żeby udostępnić platformowe API z poziomu przeglądarki, żeby móc pisać natywne aplikacje zarówno na weba jak i aplikacje mobilne.

Apple to inna bajka. Podejrzewam, że gdyby mogli, to pozbyliby się z urządzeń też Safari, żeby wszystko musiało lecieć przez AppStore. "Niestety" nie mogą sobie na to za bardzo pozwolić.

@AdamWox: Oczywiście, że wygląd aplikacji powinen być zależny od platformy. Chyba podstawową regułą w UX jest aby niekazać użytkownikowi myśleć ot przykład powrotów do poprzedniego ekranu android vs ios (w jednym przypadku masz przycisk w drugim musi/i powinno to byc na ekranie) inaczej wygląda główna nawigacja (bąbelki vs dolna belka). Co do web vs mobile w kontekście UX to jest to szalenie istotne. Zauważ jak pracujesz na komputerze to zazwyczaj operujesz po lewej/górnej stronie ekranu i jeżeli najczęściej wykonywane operacje byłyby wykonywane w prawym dolnym to by cie to drażniło. Natomiast w mobile przy większych ekranach operowania na górnej części ekranu i lewej wymusza aby sięgać bardzo daleko palcem przy mniejszych dłoniach wręcz kładzenie bokiem telefonu(w przypadku uzytkowania jędną ręką). Dlatego wygodniej jest jak wiekszość operacji wykonuje się w środkowej i dolnej częsci ekranu.

Do mnie przemawia argument o konsumpcji treści w PWA. Komunikatory, serwisy informacyjne czy playery, które nie potrzebują natywnego API, mogą jako PWA robić ten sam tracking użytkowników (nawet większy) i ładować im reklamy jak zwykłe strony. Czyli niewielkim kosztem można mieć jeszcze jeden kanał marketingowy, do którego użytkownik dostanie się łatwo, bo tylko kliknie w przypięty skrót.

@Schadoow: a jeśli zrobię to lepiej to też nie mogę i dalej muszę brnąć w UX narzucany przez platformę? Nie mówię o PC, bo to jest inna bajka względem mobilnych. Ale obsługa na iOS i Android może być ta sama i nikt mi nie wmówi, że ma być inaczej. Nie mam iPhone'a, nigdy nie miałem iPhone'a w ręku i nie wiem jakie są nawyki użytkowników urządzeń Apple i raczej nie próbowałbym się dowiedzieć. Jeśli tak się domyślne podchodzi w tworzeniu mobilek to współczuje. Nigdy nie potrafiłem iść za trendem jeśli nie miał on sensu, a w tym przypadku nie ma. Może to jest spowodowane tym, że jak już piszę mobilkę to jest ona pod konkretną grupę ludzi, którym to wsio ryba czy UX jest jabłkowy, czy robocikowy.

AdamWox napisał(a):

@Schadoow: Ale obsługa na iOS i Android może być ta sama i nikt mi nie wmówi, że ma być inaczej.

Albo mylisz UX z UI albo jesteś w błędzie.

Wmówią Ci to urządzenia i system operacyjny same z siebie. iOS nie ma czegoś takiego jak systemowy przycisk wstecz, Android tak. iOS posługuje się pt a Android dp przy projektowaniu UI. Android ma dużo szerszy rozstrzał, jeżeli chodzi o rozdzielczości i wymiary ekranów. Dialogi i alerty wyglądają zupełnie inaczej i użytkownikom będzie dużo łatwiej zrozumieć komunikaty, jeśli będą miały wygląd systemowy. Podobnie z pierdołami w stylu ikona do dzielenia się treścią – wygląda zupełnie inaczej. Możesz ją dostosować pod swój styl, ale gwarantuje Ci, że większość użytkowników będzie czuła się zagubiona, jeśli popłyniesz za daleko i użytkownicy nie zobaczą tego, co jest dla nich tożsame.

@AdamWox: Na temat siły przyzwyczajeń i nawyków masa książek powstała a ty mówisz że to nie ma sensu :). Lepsze jest wrogiem dobrego i na 100% nie przeprowadzisz testów na użytkownikach jak to robią duże firmy tworząc sensowny design system. Powiem to na swoim przykładzie od 2009 jestem użytkownikiem Iphone w ~2015 miałem próbę z androidem i jedynym powodem dla którego wróciłem ponownie do IOS to właśnie tak jak @Michał Sikora stwierdził czułem się zagubiony i za każdym razem musiałem myśleć co musze zrobić zamiast robić to intuicyjnie. Zreszta do tej port jak biorę telefon żony to nie potrafię na nim zrobić podstawowych rzeczy i sie wkurwiam. Jak np znaleźć aplikacje bo ja zawsze uzywam szybkiego wyszukiwania w IOS a na nakładce używanej przez żone nie ma czegoś takiego albo sposob w jaki działa przełączanie rodzaju audio podczas rozmow na ios a androidzie.

Porównanie głównych różnic: https://uxdesign.cc/ios-vs-android-design-630340a73ee6

Ok, niech wam będzie, ale z tego co wiem to teraz wszystkie telefony mają gesty i iOS ma wstecz pociągając palcem na krawędzi ekranu. Obsługa systemu, a aplikacji to są dwie różne rzeczy. Szukanie aplikacji to też kwestia systemu, a nie narzucania norm programowania aplikacji mobilnych. Nie da się napisać aplikacji, która zadowoli każdego, ponieważ zawsze znajdzie się coś co komuś będzie przeszkadzać. Mam na androidzie parę aplikacji, które mnie denerwują w swojej obsłudze i to wcale nie znaczy, że mam się ich pozbyć albo atakować devów tylko się dostosować. Jak bym miał spełniać wszystkich zachcianki to bym sobie szybciej w łeb strzelił.

Porównanie głównych różnic: https://uxdesign.cc/ios-vs-android-design-630340a73ee6

I serio nie ma w was buntu? Ktoś napisał artykuł na temat różnic w designie i nie macie swojego zdania tylko ślepo klepiecie UI tak jak wam każą? I z powodu takich zapisów w necie nie mogę sobie na androidzie dać plusa u góry? A co jeśli w iOS jest coś lepiej rozwiązane i będę chciał to zrobić w Androidzie? Gdzie ta oryginalność? Gdzie ta różnorodność?

AdamWox napisał(a):

Ok, niech wam będzie, ale z tego co wiem to teraz wszystkie telefony mają gesty i iOS ma wstecz pociągając palcem na krawędzi ekranu.

To nie rozbija się o same gesty i nie wszystkie telefony je mają. Na Androidzie możesz mieć gesty, ale nie musisz. Możesz mieć też hybrydę tych rozwiązać. Jak masz gesty, to musisz zadbać o specjalne obszary, żeby nie blokować korzystania z aplikacji. Takie obszary są też na iOS, ale są inne. iOS praktycznie zawsze ma w górnym rogu strzałkę wstecz, bo do tego przyzwyczajeni są użytkownicy. Na Androidzie czym innym jest systemowy przycisk wstecz (albo gest) a strzałka wstecz w górnym rogu i powinny zachowywać się nieco inaczej ze względu na to, że Android ma też jeszcze inne systemowe przyciski.

Nie da się napisać aplikacji, która zadowoli każdego, ponieważ zawsze znajdzie się coś co komuś będzie przeszkadzać. Mam na androidzie parę aplikacji, które mnie denerwują w swojej obsłudze i to wcale nie znaczy, że mam się ich pozbyć albo atakować devów tylko się dostosować. Jak bym miał spełniać wszystkich zachcianki to bym sobie szybciej w łeb strzelił.

Po pierwsze tym argumentem osłabiasz swoje stanowisko. Skoro irytują Cię aplikacje, które się zachowują nietypowo, to znaczy, że nie należy tego robić bez dobrego powodu. Po drugie, to nikt nie pisze o pozbywaniu się aplikacji czy atakowaniu devów, więc nie wiem do czego się odnosisz. Piszemy o tym, że aplikacje, które są lepiej dostosowane pod standardy systemowe mają lepszą adaptację i łatwiej się ich używa. I zadowolić pewnie wszystkich Ci się nie uda, ale nikt Ci nie powie "chciałbym, żeby aplikacja była nieintuicyjna i żebym musiał nauczyć się z niej korzystać od 0".

Porównanie głównych różnic: https://uxdesign.cc/ios-vs-android-design-630340a73ee6

I serio nie ma w was buntu?

Nie, to całkiem naturalne, że aplikacje napisane na dany system powinny zachowywać się zgodnie z jego wytycznymi i przyzwyczajeniami użytkowników na tym systemie. Chciałbyś, żeby kontrola okna na Windowsie była po lewej stronie i miała trzy kolorowe przyciski jak macOS? Albo żeby naciśnięcie "x" nie zamykało tylko minimalizowało aplikację?

Ktoś napisał artykuł na temat różnic w designie i nie macie swojego zdania tylko ślepo klepiecie UI tak jak wam każą? I z powodu takich zapisów w necie nie mogę sobie na androidzie dać plusa u góry?

Mylisz ciąg przyczynowo-skutkowy. Artykuł powstał na bazie wytycznych i tysięcy aplikacji a nie na odwrót.

A co jeśli w iOS jest coś lepiej rozwiązane i będę chciał to zrobić w Androidzie? Gdzie ta oryginalność? Gdzie ta różnorodność?

To skorzystaj z tego rozwiązania. Nie wiem czemu miałbyś nie użyć lepszego rozwiązania. Tylko co znaczy lepsze? To które Ci się bardziej podoba? Musiałbyś zrobić jakieś testy A/B, żeby wiedzieć czy jakiś Twój pomysł na inne zachowanie niż typowe, jest lepszy i przynosi więcej korzyści.

Nie ma w tej dyskusji jednej odpowiedzi. Dla mnie lepsze rozwiązania nie będą lepszymi dla kogoś innego i nawet nie mówię tutaj o różnicach platformowych. To co mnie się może wydawać intuicyjne, dla drugiego może być durne. Spotkałem się z takimi UI/UX w życiu, że to aż już śmieszne było jak bardzo developer poszedł na łatwiznę byle by tylko funkcja była i spełniała swoje zadanie.

Nie dążę do tego, aby na "życzenie" klienta robić nieintuicyjne aplikacje. Owszem, nikt mi tak nie powie. Problem polega na tym, że do wszystkiego idzie się przyzwyczaić jeśli jest to niezbędne do pracy czy życia. W moim przypadku przykładem jest Edge na Androidzie. No za chiny nie potrafię się przestawić na to menu na dole. W ogóle obsługa wydaje się być taka mozolna. I to może być przyzwyczajenie do Chrome. Teraz kto ma "rację" w takim przypadku? Microsoft czy Google? Obie wielkie, programistyczne korporacje i dwie różne wizje w obsłudze przeglądarki. Firefox to już całkiem popłynął, bo ma dwie ale ta druga to taka bardziej "bezpieczna", obsługa jest kompletnie inna. Idźmy dalej - Samsungowy (one ui 2.5) dialer jest jako osobna zakładka na dole, a dialer w Xiaomi albo od Google ma "pływający" guzik i z tego powodu Samsung nie sprzedaje się gorzej, bo nie spełnia "wymogów" w UX/UI na Androidzie. Moim zdaniem pływający guzik jest zdecydowanie lepszy.

Rozumiem o co wam chodzi i szanuje zdanie użytkowników jeśli ktoś mi to zargumentuje dlaczego tak, a nie inaczej ma pracować moja aplikacja. W przypadku iOSa to podejrzewam, że nigdy na niego nie będę programował. Prędzej pójdę w stronę web (niekoniecznie PWA). Co do Androida to definitywnie Flutter i żaden "ketchup" mnie nie przekona do zmiany. Jeśli już web i PWA to Angular Material i nie mam również zamiaru dostosowywać wyglądu względem platformy. Ewentualnie jest plan, aby skorzystać z DevExtreme, a tam to już raczej neutralne jest.

Koniec końców rozbija sie wszystko o to w jaki target celujesz z aplikacją. I jeżeli zrobisz to po androidowemu to nie będziesz wgl konkurencyjny na rynku ios o ile twoja aplikacja nie jest innowacyjna ale nawet jeśli jest to ktoś po prostu podpieprzy ci pomysł i zrobi zgodnie ze sztuką na daną platformę :). Są ludzie którzy tylko czają się na takie okazje ;p. Poza tym sam na przykładzie przeglądarek widzisz na której pracuje się wygodniej a na której nie i taką koniec końców wybierzesz (chyba, że jesteś masochistą) tak samo jest z każdą inna aplikacją czy serwisem. Czym prostsze/łatwiejsze jest wejście w daną aplikacje/serwis tym bardziej będzie ona zdobywać popularność a to że ma jakieś niesamowite feature to zauwazy mały procent użytkowników. Ot przykład tiktoka polecam przeanalizować jak wygląda tam rejestracja (jak nie chcesz samemu sie rejestrowac to na necie są analizy i dla czego to zostało tak zrobione a nie inaczej.)

AdamWox napisał(a):

Dla mnie lepsze rozwiązania nie będą lepszymi dla kogoś innego i nawet nie mówię tutaj o różnicach platformowych.

To o czym my przez całą stronę rozmawiamy? :P

To co mnie się może wydawać intuicyjne, dla drugiego może być durne.

Ja się z tym zgadzam. Dlatego nie korzystam z iOS'a. Jest dla mnie nieintuicyjny w przeciwieństwie do Androida. Dlatego korzystam z macOS'a, bo nie ma dla mnie wygodniejszego systemu operacyjnego. BitBucket jest dla mnie okropny. GitHub jest niesamowicie wygodny. To jest normalne, że woli się jedno nad drugie. Natomiast lepszym rozwiązaniem dla danego produktu będzie to, które ułatwia osiągnięcie celu.

Jeżeli komuś zależy na stworzeniu unikalnej platformy, która będzie się wyróżniać swoim zachowaniem, to faktycznie możne być nierozsądne dostosowywanie się do platformowych konwenansów. Jednak celem większości firm jest zarabiać pieniądze i wtedy jest bardzo łatwo zmierzyć, które rozwiązanie jest bardziej dochodowe poprzez retencję użytkowników, klikalność, ilość ściągnięć recenzje, itp.

Problem polega na tym, że do wszystkiego idzie się przyzwyczaić jeśli jest to niezbędne do pracy czy życia.

Tylko co to za argument? Można też przyzwyczaić się do ekstremalnie złych rzeczy. Nie znaczy, że należy je naśladować. Przecież nigdzie nie piszę, że produkt musi być idealny, żeby był użyteczny. Ale można nie wychodzić z pozycji "zrobię źle". To "źle" może wyjść gdzieś po drodze ze względy na terminy itp.

W moim przypadku przykładem jest Edge na Androidzie. No za chiny nie potrafię się przestawić na to menu na dole. W ogóle obsługa wydaje się być taka mozolna. I to może być przyzwyczajenie do Chrome. Teraz kto ma "rację" w takim przypadku? Microsoft czy Google?

W tym konkretnym przypadku nikt. Ale porównujesz ze sobą dwa gotowe produkty. Czym innym jest mieć już brand i UX, do którego są przyzwyczajeni użytkownicy i dostosować swój do platformy, a czym innym jest wchodzenie na rynek z aplikacją mobilną.

Mam wrażenie, że myślisz, że staram się przekazać, żeby na Androidzie zawsze był Material Design a na iOS Human Interface, gdzie ja tego w ogóle nie piszę.

Idźmy dalej - Samsungowy (one ui 2.5) dialer jest jako osobna zakładka na dole, a dialer w Xiaomi albo od Google ma "pływający" guzik i z tego powodu Samsung nie sprzedaje się gorzej, bo nie spełnia "wymogów" w UX/UI na Androidzie.

To jeszcze inna kwestia. OEM ma cały swój ekosystem. Coś jak mini dystrybucja Linuxa i mini środowisko graficzne. Użytkownicy Samsunga są przyzwyczajeni do bajerów Samsunga. I nigdzie nie piszę o wymogach tylko o wytycznych. Gdyby Samsung nie spełniał wymogów Androida (również pod względem UI/UX), to by nie mógł brandować się jako Android.

Jeśli już web i PWA to Angular Material i nie mam również zamiaru dostosowywać wyglądu względem platformy.

I nie ma w tym niczego dziwnego. Często jest tak wygodniej, bo nie ma pieniędzy, czasu, możliwości, chęci, wartości albo umiejętności, żeby robić wszystko naraz. Ale jeśli motywacją jest "mojsze jest lepsze", to jest przeciwieństwo UX.