Mark Zuckerberg powiedział kiedyś: „Największym błędem, jaki popełniliśmy jako firma, jest zbytnie obstawianie HTML5 w przeciwieństwie do natywnego… ponieważ go tam po prostu nie było. I nie chodzi o to, że HTML5 jest zły. Właściwie, na dłuższą metę, jestem tym naprawdę podekscytowany”. A kto nie byłby podekscytowany perspektywą jednej bazy kodu, która działa na wielu platformach ?

Dalsze czytanie na SmashingMag:

• Przewodnik dla początkujących po progresywnych aplikacjach internetowych
• Bloki konstrukcyjne progresywnych aplikacji internetowych
• Tworzenie kompletnej aplikacji internetowej w bazie aplikacji

Niestety, Facebook uznał, że HTML5 nie oferuje takiego doświadczenia, jakie chciał zbudować, io to tak naprawdę chodzi: doświadczenie. Uważam, że Mark tak naprawdę próbował powiedzieć, że ich największym błędem było podjęcie decyzji opartej na technologii, a nie opartej na doświadczeniu użytkownika. W ostatecznym rozrachunku powinniśmy podejmować decyzje, które przynoszą wartość naszym klientom , a trzymanie się określonej technologii nie jest najlepszym sposobem na osiągnięcie tego.

Dla naszego klienta Beyond the Rack, sprzedawcy e-commerce działającego wyłącznie online, naszym głównym celem było stworzenie aplikacji zapewniającej doskonałe wrażenia użytkownika. Podobnie jak Zuckerberg, chcieliśmy również podążać ścieżką HTML5 — podejście „napisz raz, uruchom wszędzie” do aplikacji napisanych w interfejsach internetowych HTML5 jest niezwykle atrakcyjne. Jednak w dzisiejszym świecie, w którym aplikacje stają się głównym sposobem interakcji użytkowników z Twoim produktem, wydajność jest nie tylko przyjemnością — to przewaga nad konkurencją.

Jednak prawie nigdy nie jest tak, że wszystkie funkcje Twojej aplikacji muszą być budowane z całkowicie natywnymi interfejsami. Na przykład, chociaż może być trudno sprawić, by animacje nawigacji wydawały się natywne w Internecie, strona internetowa, która zawiera niewiele złożonej animacji lub nie zawiera jej wcale, może być z łatwością używana w aplikacji, nadal pozostając natywną . To wszystko, co naprawdę ma znaczenie dla użytkownika. Wymagana jest wtedy strategia „może napisać raz, może uruchomić wszędzie — to naprawdę zależy od funkcji…”.

Krótko mówiąc, nie wybieraj między interfejsem natywnym a internetowym . Użyj obu.

W tym artykule przeprowadzę Cię przez nasze doświadczenie w tworzeniu aplikacji dla Beyond the Rack, w której łączymy zawartość natywną i internetową, aby stworzyć aplikację, która „czuje się” natywna.

Studium przypadku: budowanie aplikacji dla Beyond the Rack

Oczywiście ważne było, aby określić, jakie problemy Beyond the Rack chce rozwiązać dla siebie i swoich klientów za pomocą swojej aplikacji. Naturalnie z tego wynikałby wybór, czy przejść na natywny, czy internetowy dla każdej funkcji.

Zdaliśmy sobie sprawę, że aby stworzyć świetną aplikację, musimy wykonać świetną robotę ze wszystkimi trzema z następujących rzeczy:

• Interfejs zakupów
  Beyond the Rack jest sprzedawcą wyłącznie online; dlatego posiadanie świetnego interfejsu do przeglądania wyprzedaży i robienia zakupów jest kluczowe. Ponieważ tworzyliśmy natywną aplikację, mieliśmy okazję wyjść poza to, co może zaoferować doświadczenie internetowe.
• Udostępnianie
  Ponieważ głównym motorem przychodów Beyond the Rack są klienci, którzy dzielą się różnymi pozycjami sprzedaży ze znajomymi, musieliśmy upewnić się, że udostępnianie między iOS, Androidem i przeglądarką jest tak płynne, jak to tylko możliwe.
• Wykrywalność
  Beyond the Rack zapewnia swoim użytkownikom ograniczoną czasowo sprzedaż; dlatego bardzo ważna jest możliwość szybkiego dotarcia do użytkowników. Wiadomości push to najlepszy sposób na zaangażowanie lojalnych klientów i ostatecznie był to największy czynnik decydujący o stworzeniu aplikacji.

Przyjrzyjmy się, jak zbudowaliśmy niektóre z najważniejszych funkcji naszych aplikacji Beyond the Rack na iOS i Androida: które funkcje aplikacji zostały zbudowane przy użyciu technologii internetowej, które funkcje są w pełni natywne i jak wszystkie współpracują ze sobą.

Interfejs zakupów

Natywne bity

Zbudowaliśmy responsywną stronę internetową dla Beyond the Rack na tablety i urządzenia mobilne — taką, z której byliśmy dumni. Ale nie wystarczyło po prostu wrzucić witrynę do widoku internetowego i nazwać to dniem; sama strona internetowa nie przypomina aplikacji natywnej. Dużym tego powodem jest nawigacja. W przeglądarce masz przyciski wstecz i dalej oraz pasek adresu URL. W aplikacjach na iOS i Androida użytkownicy mają bardzo różne oczekiwania co do nawigacji, a my chcieliśmy spełnić te oczekiwania, aby nasza aplikacja była spójna z każdą platformą.

Stworzyliśmy prototyp, który dynamicznie ładuje zawartość za pośrednictwem AJAX i zarządza nawigacją i przejściami w językach internetowych, ale nie mogliśmy sprawić, by był tak jedwabiście gładki, jak przejścia widoczne w aplikacjach natywnych. Animacje nawigacji na iOS i Androidzie są dość trudne do dopasowania przy użyciu technologii internetowej, a wszelkie nieprawidłowości w nawigacji sprawiłyby, że nasza aplikacja byłaby mniej natywna. Użytkownicy zauważą, że Twoja aplikacja nie działa z szybkością 60 klatek na sekundę.

Wymyśliliśmy podejście, które naszym zdaniem łączy to, co najlepsze z obu światów: ładuj główną treść z sieci, ale używaj natywnych elementów nawigacyjnych:

Na iOS wdrożenie tego było naprawdę proste. Wykorzystaliśmy kontroler nawigacyjny, który zarządza stosem widoków, a także pasek nawigacyjny do sterowania nawigacją między poszczególnymi widokami. W naszym przypadku stos widoków jest tak naprawdę stosem widoków internetowych — za każdym razem, gdy pojawia się nawigacja, zamiast przechodzić do niej w samym widoku internetowym, tworzymy wystąpienie nowego widoku internetowego, przesyłamy go do naszego UINavigationController i przechodzimy do nowy cel. Korzystanie ze stosów widoków internetowych oznacza również, że za każdym razem, gdy użytkownik wraca, nie musi czekać na ponowne załadowanie strony, co jest świetne dla jego doświadczenia. Jeśli w przyszłości zdecydujemy się zastąpić funkcję widokiem natywnym, po prostu wrzucilibyśmy na stos widok natywny, a nie wersję tej funkcji w widoku sieciowym.

W Androidzie odpowiednikiem kontrolera nawigacyjnego byłoby używanie stosów działań. Zdecydowaliśmy się nie korzystać z wielu czynności i fragmentów, ponieważ oba wymagają niezwykle złożonego zarządzania cyklem życia. Skończyło się na zarządzaniu własnym stosem widoków internetowych dla aplikacji i pisaniu niestandardowych animacji natywnych, aby przechodzić między każdym widokiem.

Wiele innych aplikacji wykorzystuje natywne elementy nawigacji w celu dostosowania do wzorców projektowych systemu operacyjnego. Zobacz ten obraz aplikacji Basecamp na Androida, która wykorzystuje natywny pasek nawigacyjny:

Porównaj też aplikację Amazona z jego witryną mobilną:

Dzięki takiemu podejściu znaleźliśmy idealne miejsce na korzystanie z usług, które są znajome dla platformy , a jednocześnie nadal wykorzystujemy doskonałe wrażenia z zakupów w sieci.

Dla wielu może to być niespodzianką, ale twórcy aplikacji Facebook również nieustannie znajdują najlepsze miejsce, wykorzystując natywne lub internetowe, gdy ma to sens dla każdej funkcji. Zgodnie z artykułem napisanym przez inżyniera Facebooka: „W obszarach aplikacji, w których przewidujemy częstsze wprowadzanie zmian, będziemy nadal wykorzystywać kod HTML5, ponieważ możemy przesyłać aktualizacje po stronie serwera bez konieczności pobierania nowej wersji aplikacji. ”. Wygląda na to, że Facebook stosuje to samo podejście, które zaleca tutaj: wybierz technologię dla każdej funkcji w oparciu o wydajność, wymagany wysiłek programistyczny i szybkość, z jaką musisz to zrobić.

W przypadku swojej aplikacji rozważ każdy przypadek z osobna, czy tworzenie funkcji natywnie, czy wykorzystanie treści internetowych ma większy sens. Biorąc pod uwagę trudność w budowaniu nawigacji, która wydaje się natywna, prawdopodobnie ma sens przynajmniej zbudowanie jej przy użyciu natywnych komponentów.

Bity sieciowe

Dzisiaj prawie wszyscy zgadzają się, że dobrym pomysłem jest stopniowe ulepszanie witryn internetowych : używaj jednej bazy znaczników dla najniższego wspólnego mianownika przeglądarek i nakładaj na nią funkcjonalność i ulepszenia za pomocą JavaScript i CSS, w zależności od kontekstu — bez osobnych baz kodu lub szablonów dla różnych wymaganych urządzeń. Podobnie jak nie ma sensu tworzenie oddzielnych szablonów dla sieci mobilnej i komputerowej, chcieliśmy użyć szablonów aktywnych witryn internetowych w samej aplikacji. Aplikacja to tylko kolejny kontekst.

Nazywam to budowaniem responsywnych stron internetowych „świadomych aplikacji” . Tworząc naszą witrynę internetową z myślą o kontekście i wydajności aplikacji, będziemy gotowi do wysyłki do wszystkich naszych użytkowników na różnych platformach prędzej niż później.

Strony internetowe muszą być w stanie wykryć kontekst aplikacji w trzech miejscach: CSS, JavaScript i serwer. Stworzyliśmy klasę app do pisania warunkowego CSS i metodę isRunningInApp do pisania warunkowego kodu JavaScript, a także dołączyliśmy App do agenta użytkownika, aby uzyskać warunkową logikę po stronie serwera.

Przykładem zastosowania progresywnego ulepszania w aplikacji jest strona z informacjami o produkcie. Zoptymalizowaliśmy go, dodając przycisk „Dodaj do koszyka” o stałej pozycji tylko dla aplikacji:

Mogliśmy też dodać w przeglądarce przycisk „Dodaj do torby” o stałej pozycji, ale tego nie zrobiliśmy, ponieważ w Safari, kliknięcie w dół spowoduje otwarcie paska nawigacyjnego Safari. Przypadkowe otwarcie tego paska, gdy użytkownik próbuje dodać produkt do koszyka, byłoby niedopuszczalną wadą użyteczności, pomimo zalet stałego przycisku „Dodaj do koszyka” na dole strony:

Kolejnym obszarem, w którym wprowadziliśmy poprawki dotyczące aplikacji na stronie internetowej, jest koszyk. Logika koszyka jest zwykle jednym z najtrudniejszych aspektów każdej witryny e-commerce, a ponieważ byliśmy bardzo zadowoleni z korzystania z koszyka na urządzeniach mobilnych, postanowiliśmy ponownie wykorzystać go w aplikacji, chociaż z nieco zmodyfikowanym wyglądem i działaniem:

Udostępnianie

Możliwość udostępniania łączy i otwierania udostępnionych łączy to kluczowa funkcja, która musi dobrze działać w Beyond the Rack. Chcieliśmy, aby udostępnianie było płynne. Jeśli ktoś udostępni łącze ze swojego komputera, a jego znajomy otworzy je w aplikacji, łącze musi otworzyć się poprawnie; podobnie, jeśli ktoś udostępnia produkt z aplikacji, musi on poprawnie otworzyć się na pulpicie; a jeśli znajomy jest na urządzeniu mobilnym, ale nie ma zainstalowanej aplikacji, powinien otworzyć się w przeglądarce. Byliśmy zdeterminowani, aby było to niesamowite doświadczenie, ponieważ jest to zazwyczaj coś, w czym aplikacje są słabe.

Udostępnianie treści między siecią a aplikacją może być trudne . Aby to zrobić pomyślnie, musisz zmapować linki aplikacji i linki internetowe. Było to bolesne w czasach przed responsywnością, kiedy otwarcie adresu URL na komputery prowadziło do strony głównej mobilnego adresu URL z powodu przekierowań i tym podobnych. Dokładnie ten sam problem widzimy dzisiaj z aplikacjami — banery w Safari i Chrome proszą o otwarcie linku w aplikacji, tylko po to, aby aplikacja nie pokazywała tego, czego szukałeś, co pozwala na ponowne wyszukiwanie. Na szczęście obsługa łączy internetowych w aplikacji Beyond the Rack jest bardzo prosta, ponieważ wystarczy załadować ten adres URL w widoku sieciowym. Musimy tylko upewnić się, że linki internetowe prowadzą użytkowników do aplikacji, a nie do przeglądarki.

W Androidzie otwieranie adresu URL w aplikacji jest proste. Wystarczy skonfigurować filtr intencji, aby ładować aplikację za każdym razem, gdy użytkownik próbuje załadować określony adres URL (w naszym przypadku www.beyondtherack.com ). Po zainstalowaniu aplikacji użytkownicy będą mieli możliwość otwarcia adresu URL w aplikacji lub w przeglądarce:

iOS ma nieco bardziej wyboistą drogę do umożliwienia otwierania adresów URL bezpośrednio w aplikacjach. Wcześniej system iOS umożliwiał tylko zarejestrowanie schematu aplikacji dla każdej aplikacji (na przykład beyondtherack:// ). Ponieważ nie można było dowiedzieć się, które aplikacje zostały zainstalowane, jedynym wyjściem było otwarcie danego linku w Safari, a następnie próba otwarcia tego linku w aplikacji. Przyniosło to niewielką irytację: jeśli aplikacja nie została zainstalowana, użytkownik otrzymywał irytujący komunikat o błędzie „Safari nie może otworzyć strony, ponieważ adres jest nieprawidłowy”. Na szczęście hack pozwala ukryć ten błąd za pomocą ramek iframe. Jeśli chcesz obsługiwać precyzyjne linki w systemie iOS 8, jest to najlepsza opcja.

Na szczęście w iOS 9 wprowadzono uniwersalne linkowanie, które umożliwia aplikacjom przechwytywanie linków internetowych, zanim linki przejdą przez Safari. ## Wykrywalność Terminowość jest niezwykle ważna dla firmy takiej jak Beyond the Rack. Tradycyjnie głównym sposobem informowania klientów o sprzedaży przez firmę były kampanie e-mailowe. Ale dzięki aplikacjom jest w stanie **komunikować się bezpośrednio ze swoimi klientami na temat sprzedaży**, co jest bardzo potężne. (Oczywiście, powiadomienia push powoli pojawiają się w przeglądarkach, a [Chrome jest liderem opłat](https://gauntface.com/blog/2014/12/15/push-notifications-service-worker). Ale dla starszych urządzeń z Androidem a w przypadku systemu iOS wybór, czy użyć technologii natywnej, czy internetowej, został już dokonany za nas. Podobnie jak w przypadku udostępniania, nasza decyzja o wykorzystaniu treści internetowych bezpośrednio w aplikacji sprawiła, że ​​skonfigurowanie **powiadomień push** stało się dziecinnie proste. Ponieważ każdy produkt i sprzedaż można zidentyfikować za pomocą tego samego adresu URL zarówno na stronie internetowej, jak i w aplikacji, edukowanie marketerów, jak wysyłać powiadomienia do klientów, jest proste — wystarczy, że udostępnią te same adresy URL, do których są przyzwyczajeni. w kampaniach e-mailowych. Interesującą różnicą między iOS a Androidem jest **system uprawnień** dla powiadomień push. W systemie iOS uprawnienia do powiadomień są kontrolowane przez system operacyjny, podczas gdy w systemie Android uprawnienia nie są potrzebne. Mimo to uważaliśmy, że prośba o pozwolenie była właściwą rzeczą z punktu widzenia obsługi klienta. Tak więc, gdy użytkownik loguje się do aplikacji po raz pierwszy, pytamy, czy chce otrzymywać powiadomienia:

Zdecydowaliśmy się również zbudować te **okna dialogowe powiadomień** z interfejsami internetowymi. Nic w nich nie wymagało zaawansowanej wydajności, więc budowanie ich za pomocą internetowych interfejsów użytkownika i ponowne wykorzystywanie ich na różnych platformach miało sens. To kolejny przykład rozpoznawania aplikacji w witrynie: te okna dialogowe są częścią witryny, ale są warunkowo wyświetlane w aplikacji.

Wyniki

Po wydaniu aplikacji chcieliśmy porównać jej działanie z działaniem przeglądarki. Bezpośrednie porównywanie ich analiz nie wystarczyło, ponieważ z naszego doświadczenia wynika, że ​​każdy, kto zainstalował aplikację, był prawdopodobnie bardziej lojalnym klientem, a tym samym prawdopodobnie dokonałby lepszej konwersji. Aby uniknąć błędu selekcji, stworzyliśmy test A/B; połowa użytkowników została zatrzymana w aplikacji, a połowa została przeniesiona do przeglądarki, dzięki czemu jedynymi uczestnikami eksperymentu byli użytkownicy, którzy mieli zainstalowaną aplikację (bardziej lojalni użytkownicy).

• Transakcje na unikalnego użytkownika były o 76% wyższe w przypadku korzystania z aplikacji niż z sieci.
• Unikalni użytkownicy aplikacji dziennie byli o 20% bardziej skłonni do konwersji .
• Użytkownicy aplikacji spędzili 63% więcej czasu na przeglądaniu niż użytkownicy internetu .

Szybkie zwycięstwa wydajności

Tworzenie aplikacji, która ładuje treści internetowe i wydaje się natywna, nie wychodzi z pudełka na iOS lub Androida. Oto kilka wyzwań związanych z wydajnością, z którymi się zmierzyliśmy, którymi warto się podzielić:

• W systemie iOS tempo przewijania w widoku internetowym nie jest zgodne z tempem przewijania w natywnym widoku przewijania. Zostało to odkryte podczas testów użytkowników. Oto jedna linijka, która pomoże rozwiązać ten problem: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• Zachowaj ostrożność podczas zmiany rozmiaru widoków internetowych . Natknęliśmy się na problemy polegające na tym, że zmiana ich rozmiaru powodowała całe przemalowanie, co powodowało spadek wydajności przewijania na starszych urządzeniach.
• Radzenie sobie z setkami różnych implementacji widoków internetowych w systemie Android może być bolesne. Najbardziej bolesnym problemem, na który natknęliśmy się, jest znany błąd przeglądania stron internetowych w Androidzie 4.4.2, który powoduje wystąpienie krytycznego wyjątku w Chromium, który powoduje awarię aplikacji. Usunięcie transform: translate3d w tej wersji Androida wydaje się załatwiać sprawę. Alternatywnie możesz użyć Crosswalk, aby wysłać własne skompilowane internetowe środowisko wykonawcze z aplikacją (nie zrobiliśmy tego, ale planujemy to zrobić w przyszłych projektach).
• Użyj FastClick, nie tylko dlatego, że usuwa 300-milisekundowe opóźnienie kliknięcia, ale także dlatego, że naprawia błąd kliknięcia w widoku sieciowym wprowadzony w iOS 8.4.1. Dla nas błąd polegał na tym, że nie pozwalał na zmianę strony, jeśli kliknięcie było zbyt wolne.
• Zrób wszystko, aby przewijanie było niesamowite. Możesz odrzucić zdarzenia przewijania, uniknąć niepotrzebnych przemalowań i nie tylko. Jeśli przewijanie nie działa z prędkością 60 klatek na sekundę, użytkownicy zauważą, nawet bardziej w aplikacji niż w sieci.
• Zrób wszystko, co w Twojej mocy, aby strony ładowały się w czasie krótszym niż 1000 milisekund.

Narzędzia do tworzenia aplikacji wykorzystującej Twoją witrynę

Masz wiele opcji tworzenia aplikacji, która wykorzystuje istniejącą witrynę. Podejście, które przyjęliśmy, polega na zbudowaniu aplikacji specyficznej dla każdej platformy (przy użyciu Xcode i Android Studio), wykorzystując w razie potrzeby widoki internetowe lub widoki natywne.

Podczas ładowania widoku internetowego dla określonej funkcji zalecamy zintegrowanie widoku internetowego Cordova zamiast bezpośredniego korzystania z bibliotek widoków internetowych udostępnianych przez systemy iOS i Android. Dzięki temu Twoje widoki internetowe będą miały wiele funkcji, które w innym przypadku musiałbyś zbudować samodzielnie, takie jak most web-to-native do komunikacji z JavaScript do kodu natywnego i odwrotnie, możliwość dostępu do zdarzeń cyklu życia, a także dostęp do bogactwa wtyczek Cordova. Alternatywnie, dostępnych jest kilka innych mostów web-to-native dla różnych platform, jeśli chcesz uniknąć zależności od Cordova.

Dostępnych jest kilka platform, które pomagają w tworzeniu aplikacji w ten sposób, takich jak Supersonic i Astro, natywna platforma aplikacji, którą tworzymy, aby ułatwić zarządzanie złożonością tworzenia aplikacji przy użyciu zarówno interfejsów natywnych, jak i internetowych.

Wniosek

Dzięki Beyond the Rack postanowiliśmy zbudować aplikację, w której moglibyśmy łatwo dostarczać użytkownikom wartość bez poświęcania doświadczenia. Wierzymy, że dzięki podejściu, które stawia technologię na tylnym siedzeniu , co pozwala nam wykorzystać odpowiednią technologię do zadania, właśnie to osiągnęliśmy. Przy każdej zmianie lub wprowadzeniu funkcji zawsze zadajemy sobie pytanie: „Jakie doświadczenie chcemy tu zaprojektować, które najlepiej rozwiąże problem użytkownika? Czy to doświadczenie wymaga użycia zaawansowanej wydajności lub animacji?”

Odpowiedź na to pytanie zadecyduje, czy zbudujemy funkcję za pomocą technologii internetowej i ponownie wykorzystamy ją w przeglądarce oraz na Androidzie i iOS, czy też zbudujemy ją indywidualnie dla każdej platformy.

Ostatecznie uważam, że tak należy budować aplikacje. Ale to będzie wymagało zmiany sposobu myślenia. Zamiast próbować ustalić, czy sieć zatriumfuje nad tubylcami, czy stanie się reliktem przeszłości, powinniśmy przyjąć to, co najlepsze z obu. Powinniśmy rozpoznać ich zalety i wady i zastosować technologię, która jest najbardziej sensowna dla danej funkcji.