Mark Zuckerberg hat einmal gesagt: „Der größte Fehler, den wir als Unternehmen gemacht haben, war, zu sehr auf HTML5 zu setzen, im Gegensatz zu nativem … weil es einfach nicht da war. Und es ist nicht so, dass HTML5 schlecht ist. Ich bin tatsächlich, langfristig gesehen, wirklich aufgeregt darüber.“ Und wer wäre nicht begeistert von der Aussicht auf eine einzige Codebasis, die auf mehreren Plattformen funktioniert ?

Weiterführende Literatur zu SmashingMag:

• Ein Anfängerleitfaden für progressive Web-Apps
• Die Bausteine ​​von Progressive Web Apps
• Erstellen einer vollständigen Web-App in Foundation for Apps

Leider hatte Facebook das Gefühl, dass HTML5 nicht die Erfahrung bot, die es aufbauen wollte, und darum geht es wirklich: die Erfahrung. Ich glaube, was Mark wirklich sagen wollte, war, dass ihr größter Fehler darin bestand, eine technologiegesteuerte Entscheidung statt einer benutzererfahrungsgesteuerten Entscheidung zu treffen. Letztendlich sollten wir Entscheidungen treffen, die unseren Kunden einen Mehrwert bieten , und das Festhalten an einer bestimmten Technologie ist im Allgemeinen nicht der beste Weg, dies zu erreichen.

Für unseren Kunden Beyond the Rack, einen reinen Online-E-Commerce-Händler, war es unser primäres Ziel, eine App mit einer großartigen Benutzererfahrung zu entwickeln. Wie Zuckerberg wollten auch wir den HTML5-Weg einschlagen – der Ansatz „Einmal schreiben, überall ausführen“ für Apps, die in HTML5-Weboberflächen geschrieben sind, ist äußerst attraktiv. Aber in der heutigen Welt, in der Apps zur primären Art und Weise werden, wie Benutzer mit Ihrem Produkt interagieren, ist Leistung nicht nur ein nettes Extra – sie ist ein Wettbewerbsvorteil.

Es ist jedoch fast nie der Fall, dass alle Funktionen Ihrer App mit vollständig nativen Schnittstellen erstellt werden müssen. Während es beispielsweise schwierig sein kann, Navigationsanimationen im Web nativ erscheinen zu lassen, könnte eine Webseite, die wenig bis gar keine komplexen Animationen enthält, problemlos in der App verwendet werden und sich dennoch nativ anfühlen. Das ist alles, was für den Benutzer wirklich wichtig ist. Was dann erforderlich ist, ist eine „Vielleicht einmal schreiben, vielleicht überall ausführen – es hängt wirklich von der Funktion ab …“-Strategie.

Kurz gesagt, wählen Sie nicht zwischen nativen und Webschnittstellen . Verwende beide.

In diesem Artikel führe ich Sie durch unsere Erfahrung beim Erstellen einer App für Beyond the Rack, in der wir native und Webinhalte mischen, um eine App zu erstellen, die sich „nativ“ anfühlt.

Fallstudie: Erstellen einer App für Beyond The Rack

Offensichtlich war es wichtig herauszufinden, welche Probleme Beyond the Rack mit seiner App für sich und seine Kunden lösen wollte. Die Wahl, ob für jede Funktion nativ oder webbasiert werden soll, würde sich daraus natürlich ergeben.

Wir haben erkannt, dass wir alle drei der folgenden Dinge gut machen müssen, um eine großartige App zu entwickeln:

• Einkaufsschnittstelle
  Beyond the Rack ist ein reiner Online-Händler; Daher ist es entscheidend, eine großartige Benutzeroberfläche zum Durchsuchen von Verkäufen und zum Tätigen von Einkäufen zu haben. Da wir eine native App erstellten, hatten wir die Möglichkeit, über das hinauszugehen, was das Web-Erlebnis bieten kann.
• Teilbarkeit
  Da ein großer Umsatztreiber für Beyond the Rack darin besteht, dass Kunden verschiedene Verkaufsartikel mit Freunden teilen, mussten wir sicherstellen, dass das Teilen zwischen iOS, Android und dem Browser so nahtlos wie möglich ist.
• Auffindbarkeit
  Beyond the Rack bietet seinen Benutzern zeitlich begrenzte Verkäufe; Daher ist es sehr wichtig, Benutzer schnell erreichen zu können. Push-Messaging bietet die beste Möglichkeit, diese treuen Kunden zu binden, und war letztendlich der größte Grund für die Entscheidung, die App zu entwickeln.

Lassen Sie uns direkt darauf eingehen, wie wir einige der wichtigsten Funktionen unserer Beyond the Rack iOS- und Android-Apps erstellt haben: welche Funktionen der App mithilfe von Webtechnologie erstellt wurden, welche Funktionen vollständig nativ sind und wie sie alle zusammenarbeiten.

Das Shopping-Interface

Die nativen Bits

Wir hatten eine responsive Website für Beyond the Rack auf Tablets und Mobilgeräten erstellt – eine, auf die wir stolz waren. Aber es reichte nicht aus, die Website einfach in eine Webansicht zu werfen und Feierabend zu machen; Die Website an sich fühlt sich nicht wie eine native App an. Ein wichtiger Grund dafür ist die Navigation. In einem Browser haben Sie Zurück- und Vorwärts-Schaltflächen und eine URL-Leiste. In iOS- und Android-Apps haben Benutzer sehr unterschiedliche Erwartungen an die Navigation, und wir wollten diese Erwartungen erfüllen, damit sich unsere App mit jeder Plattform konsistent anfühlt.

Wir haben einen Prototyp erstellt, der Inhalte dynamisch über AJAX lädt und die Navigation und Übergänge in Websprachen verwaltet, aber wir konnten nicht erreichen, dass er sich so seidenweich anfühlt wie die Übergänge, die Sie in nativen Apps sehen. Die Navigationsanimationen auf iOS und Android sind mit Webtechnologie ziemlich schwierig abzugleichen, und jeder Ruck in der Navigation würde dazu führen, dass sich unsere App weniger nativ anfühlt. Wenn Ihre App nicht mit 60 Bildern pro Sekunde läuft, werden die Benutzer dies bemerken.

Wir haben einen Ansatz entwickelt, der unserer Meinung nach das Beste aus beiden Welten kombiniert: Laden Sie den Hauptinhalt aus dem Web, verwenden Sie jedoch native Navigationselemente:

Unter iOS war die Implementierung wirklich ganz einfach. Wir haben den Navigationscontroller, der einen Stapel von Ansichten verwaltet, sowie eine Navigationsleiste zur Steuerung der Navigation zwischen den einzelnen Ansichten genutzt. In unserem Fall ist der Stapel von Ansichten wirklich nur ein Stapel von Webansichten – jedes Mal, wenn eine Navigation auftritt, anstatt in der Webansicht selbst dorthin zu navigieren, instanziieren wir eine neue Webansicht, verschieben sie an unseren UINavigationController und navigieren zu neues Ziel. Die Verwendung von Stapeln von Webansichten bedeutet auch, dass der Benutzer, wenn er zurückkehrt, nicht warten muss, bis die Seite neu geladen wird, was für seine Erfahrung großartig ist. Wenn wir uns in Zukunft entscheiden, eine Funktion durch eine native Ansicht zu ersetzen, würden wir einfach eine native Ansicht auf den Stack verschieben, anstatt die Webansichtsversion dieser Funktion.

Unter Android würde das Äquivalent zum Navigationscontroller darin bestehen, Stapel von Aktivitäten zu verwenden. Wir haben uns entschieden, nicht mehrere Aktivitäten und Fragmente zu verwenden, da beide ein äußerst komplexes Lifecycle-Management erfordern. Am Ende verwalteten wir unseren eigenen Stapel von Webansichten für die App und schrieben benutzerdefinierte native Animationen für den Übergang zwischen den einzelnen Ansichten.

Eine Reihe anderer Apps nutzen native Navigationselemente, um den Designmustern des Betriebssystems zu entsprechen. Sehen Sie sich dieses Bild der Android-App von Basecamp an, die eine native Navigationsleiste nutzt:

Vergleichen Sie auch die App von Amazon mit der mobilen Website:

Mit diesem Ansatz haben wir unseren optimalen Punkt gefunden, ein Erlebnis zu haben, das sich der Plattform vertraut anfühlt , während wir dennoch ein großartiges Kern-Einkaufserlebnis aus dem Internet nutzen.

Das mag für viele eine Überraschung sein, aber die Entwickler der Facebook-App finden auch ständig den idealen Punkt, indem sie nativ oder web nutzen, wenn es für jede Funktion sinnvoll ist. Laut einem Artikel eines Facebook-Ingenieurs: „Für Bereiche innerhalb der App, in denen wir voraussichtlich häufiger Änderungen vornehmen werden, werden wir weiterhin HTML5-Code verwenden, da wir Updates serverseitig pushen können, ohne dass die Leute eine neue Version der App herunterladen müssen .“ Es scheint, als ob Facebook den gleichen Ansatz verfolgt, für den hier plädiert wird: Wählen Sie die Technologie für jedes Feature basierend auf der Leistung, dem erforderlichen Entwicklungsaufwand und der Geschwindigkeit, die Sie benötigen, um es auf den Markt zu bringen.

Überlegen Sie für Ihre App von Fall zu Fall, ob es sinnvoller ist, eine Funktion nativ zu erstellen oder Webinhalte zu nutzen. Angesichts der Schwierigkeit, eine Navigation zu erstellen, die sich nativ anfühlt, ist es wahrscheinlich sinnvoll, diese zumindest mit nativen Komponenten zu erstellen.

Die Webbits

Heutzutage sind sich fast alle einig, dass es eine gute Idee ist, Websites schrittweise zu verbessern : Verwenden Sie eine Markup-Basis für den kleinsten gemeinsamen Nenner von Browsern und schichten Sie diese je nach Kontext mit Funktionen und Verbesserungen mit JavaScript und CSS auf – keine separaten Codebasen oder Vorlagen für unterschiedliche Geräte erforderlich. Genauso wie es keinen Sinn macht, separate Vorlagen für das mobile und das Desktop-Web zu erstellen, wollten wir die Live-Website-Vorlagen in der App selbst verwenden. Die App ist nur ein weiterer Kontext.

Ich nenne diesen Aufbau „app-bewusster“ responsiver Websites . Indem wir unsere Website unter Berücksichtigung des Kontexts und der Leistung der App erstellen, können wir sie früher oder später an alle unsere Benutzer auf verschiedenen Plattformen versenden.

Websites müssen in der Lage sein, den App-Kontext an drei Stellen zu erkennen: CSS, JavaScript und der Server. Wir haben eine app -Klasse erstellt, um bedingtes CSS zu schreiben, und eine isRunningInApp -Methode, um bedingtes JavaScript zu schreiben, und wir haben App an den Benutzeragenten für bedingte serverseitige Logik angehängt.

Ein Beispiel dafür, wo wir die progressive Verbesserung innerhalb der App verwendet haben, finden Sie auf unserer Produktanzeigeseite. Wir haben es optimiert, indem wir eine Schaltfläche „In den Warenkorb“ mit fester Position nur für Apps hinzugefügt haben:

Wir hätten auch eine fest positionierte Schaltfläche „Zum Warenkorb hinzufügen“ im Browser hinzufügen können, aber wir haben es nicht getan, da in Safari durch Klicken in die Nähe des unteren Rands tatsächlich die Navigationsleiste von Safari geöffnet wird. Wenn diese Leiste versehentlich geöffnet wird, wenn der Benutzer versucht, ein Produkt in seinen Warenkorb zu legen, wäre dies ein inakzeptabler Usability-Fehler, trotz der Vorteile einer dauerhaften Schaltfläche „Zum Warenkorb hinzufügen“ unten auf der Seite:

Ein weiterer Bereich, in dem wir App-spezifische Anpassungen an der Website vorgenommen haben, ist der Warenkorb. Die Warenkorblogik ist in der Regel einer der kniffligsten Aspekte jeder E-Commerce-Website, und da wir mit der Warenkorberfahrung auf Mobilgeräten sehr zufrieden waren, haben wir uns entschieden, sie in der App wiederzuverwenden, wenn auch mit einem leicht veränderten Erscheinungsbild:

Teilbarkeit

Die Möglichkeit, Links zu teilen und freigegebene Links zu öffnen, ist eine wichtige Funktion, die für Beyond the Rack gut funktionieren muss. Wir wollten ein nahtloses Teilen. Wenn jemand einen Link von seinem Desktop aus teilt und sein Freund ihn in der App öffnet, muss der Link korrekt geöffnet werden; Ebenso muss, wenn jemand ein Produkt aus der App teilt, es korrekt auf dem Desktop geöffnet werden; und wenn der Freund auf dem Handy ist, aber die App nicht installiert hat, sollte sie im Browser geöffnet werden. Wir waren fest entschlossen, dies zu einem großartigen Erlebnis zu machen, da dies normalerweise etwas ist, in dem Apps schwach sind.

Es kann schwierig sein, Inhalte zwischen Web und App gemeinsam zu nutzen . Um dies erfolgreich zu tun, müssen Sie Ihre App-Links und Weblinks zuordnen. Dies war in den Pre-Responsive-Tagen schmerzhaft, als das Öffnen einer Desktop-URL Sie aufgrund von Weiterleitungen und dergleichen zur Startseite einer mobilen URL führte. Wir sehen heute genau das gleiche Problem mit Apps – Banner in Safari und Chrome fordern Sie auf, einen Link in einer App zu öffnen, nur damit die App nicht anzeigt, wonach Sie gesucht haben, sodass Sie noch einmal danach suchen müssen. Glücklicherweise ist die Handhabung von Weblinks in der Beyond the Rack-App ein Kinderspiel, da wir lediglich diese URL in einer Webansicht laden müssen. Wir müssen nur sicherstellen, dass Weblinks die Benutzer zur App statt zum Browser führen.

Unter Android ist das Öffnen einer URL in einer App einfach. Sie müssen lediglich einen Absichtsfilter einrichten, um die App zu laden, wenn ein Benutzer versucht, die angegebene URL (in unserem Fall www.beyondtherack.com ) zu laden. Sobald die App installiert ist, haben Benutzer die Möglichkeit, die URL in der App oder im Browser zu öffnen:

iOS hatte einen etwas steinigeren Weg, um Web-URLs direkt in Apps öffnen zu können. Bisher erlaubte Ihnen iOS nur, ein App-Schema für jede App zu registrieren (z. B. beyondtherack:// ). Da es unmöglich war zu wissen, welche Apps installiert waren, bestand die einzige Möglichkeit darin, einen bestimmten Link in Safari zu öffnen und von dort aus zu versuchen, diesen Link in der App zu öffnen. Das war mit einem kleinen Ärgernis verbunden: Wenn die App nicht installiert war, bekam der Benutzer eine ärgerliche Fehlermeldung: „Safari kann die Seite nicht öffnen, weil die Adresse ungültig ist.“ Glücklicherweise können Sie diesen Fehler mithilfe eines Hacks mithilfe von Iframes unterdrücken. Wenn Sie Deep Linking auf iOS 8 unterstützen möchten, ist dies die beste Option.

Glücklicherweise hat iOS 9 die universelle Verknüpfung eingeführt, die es Apps ermöglicht, Weblinks abzufangen, bevor die Links durch Safari gehen. ## Auffindbarkeit Aktualität ist für ein Unternehmen wie Beyond the Rack extrem wichtig. Traditionell war der primäre Weg des Unternehmens, Kunden über Verkäufe zu informieren, E-Mail-Kampagnen. Aber mit Apps ist es in der Lage, **direkt mit seinen Kunden über Verkäufe zu kommunizieren**, was sehr leistungsfähig ist. (Natürlich kommen Push-Benachrichtigungen langsam in Browsern an, wobei [Chrome an der Spitze steht](https://gauntface.com/blog/2014/12/15/push-notifications-service-worker). Aber für ältere Android-Geräte und für iOS war die Wahl, ob wir native oder Web-Technologie verwenden, bereits für uns getroffen.) Genau wie beim Teilen hat unsere Entscheidung, Webinhalte direkt in der App zu nutzen, das Einrichten von **Push-Benachrichtigungen** zu einem Kinderspiel gemacht. Da jedes Produkt und jeder Verkauf sowohl auf der Website als auch in der App durch dieselbe URL identifiziert werden kann, ist es einfach, Vermarkter darin zu schulen, wie sie Benachrichtigungen an ihre Kunden senden können – alles, was sie tun müssen, ist, dieselben URLs zu teilen, die sie zu teilen gewohnt sind bei E-Mail-Kampagnen. Ein interessanter Unterschied zwischen iOS und Android ist das **Berechtigungssystem** für Push-Benachrichtigungen. Unter iOS wird die Berechtigung für Benachrichtigungen vom Betriebssystem gesteuert, während auf Android keine Berechtigung erforderlich ist. Dennoch waren wir der Meinung, dass es aus Sicht des Kundendienstes richtig war, um Erlaubnis zu bitten. Wenn sich der Benutzer also zum ersten Mal bei der App anmeldet, fragen wir, ob er Benachrichtigungen möchte:

Wir haben uns auch entschieden, diese **Benachrichtigungsdialogfelder** mit Webschnittstellen zu erstellen. Nichts an ihnen erforderte eine erweiterte Leistung, daher war es sinnvoll, sie mit Web-UIs zu erstellen und sie plattformübergreifend wiederzuverwenden. Dies ist ein weiteres Beispiel dafür, die Website App-fähig zu machen: Diese Dialogfelder sind Teil der Website, werden aber bedingt in der App angezeigt.

Ergebnisse

Nach der Veröffentlichung der App wollten wir ihre Leistung mit der Browsererfahrung vergleichen. Der direkte Vergleich ihrer Analysen war nicht genug, denn unserer Erfahrung nach war jeder, der die App installiert hatte, wahrscheinlich ein treuerer Kunde und würde daher wahrscheinlich besser konvertieren. Um Selektionsverzerrungen zu vermeiden, haben wir einen A/B-Test entwickelt; Die Hälfte der Benutzer blieb in der App und die andere Hälfte wurde in den Browser umgeleitet, wodurch sichergestellt wurde, dass die einzigen Teilnehmer am Experiment Benutzer waren, die die App installiert hatten (die treueren Benutzer).

• Die Transaktionen pro einzelnem Besucher waren mit der App-Erfahrung um 76 % höher als mit dem Web.
• Einmalige tägliche Nutzer der App führten mit 20 % höherer Wahrscheinlichkeit zu einer Conversion .
• App-Nutzer verbrachten 63 % mehr Zeit mit dem Surfen als Webnutzer .

Schnelle Leistung gewinnt

Eine App zu erstellen, die Webinhalte lädt und sich nativ anfühlt, ist auf iOS oder Android nicht sofort einsatzbereit. Hier sind ein paar Leistungsherausforderungen, mit denen wir konfrontiert waren und die es wert sind, geteilt zu werden:

• Unter iOS stimmt die Bildlaufdynamik in einer Webansicht nicht mit der Bildlaufdynamik in einer nativen Bildlaufansicht überein. Dies wurde in Benutzertests aufgedeckt. Hier ist ein Einzeiler, um das zu lösen: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• Seien Sie vorsichtig, wenn Sie die Größe von Webansichten ändern . Wir sind auf Probleme gestoßen, bei denen die Größenänderung ganze Repaints verursachte, was die Bildlaufleistung auf älteren Geräten beeinträchtigte.
• Der Umgang mit Hunderten verschiedener Implementierungen von Webansichten auf Android kann schmerzhaft sein. Das schmerzhafteste Problem, auf das wir gestoßen sind, ist ein bekannter Webansichtsfehler in Android 4.4.2, der eine schwerwiegende Ausnahme in Chromium auslöst, die zum Absturz der App führt. transform: translate3d in dieser Android-Version scheint den Zweck zu erfüllen. Alternativ können Sie Crosswalk verwenden, um Ihre eigene kompilierte Web-Runtime mit Ihrer App bereitzustellen (wir haben dies nicht getan, aber wir planen dies für zukünftige Projekte).
• Verwenden Sie FastClick, nicht nur, weil es die 300-Millisekunden-Klickverzögerung entfernt, sondern auch, weil es einen in iOS 8.4.1 eingeführten Klick-Fehler in der Webansicht behebt. Für uns manifestierte sich der Fehler darin, dass die Seite nicht geändert werden konnte, wenn der Klick zu langsam war.
• Tun Sie alles, damit sich das Scrollen fantastisch anfühlt. Sie können Scroll-Ereignisse entprellen, unnötige Repaints vermeiden und vieles mehr. Wenn das Scrollen nicht mit 60 Bildern pro Sekunde läuft, werden die Benutzer es bemerken, in einer App noch mehr als im Web.
• Tun Sie alles, damit Seiten in weniger als 1000 Millisekunden geladen werden.

Tools zum Erstellen einer App, die Ihre Website nutzt

Sie haben eine Reihe von Optionen zum Erstellen einer App, die Ihre vorhandene Website nutzt. Der Ansatz, den wir gewählt haben, besteht darin, die App spezifisch für jede Plattform zu erstellen (unter Verwendung von Xcode und Android Studio) und bei Bedarf Webansichten oder native Ansichten zu nutzen.

Wenn Sie eine Webansicht für eine bestimmte Funktion laden, empfehlen wir, die Cordova-Webansicht zu integrieren, anstatt direkt die von iOS und Android bereitgestellten Webansichtsbibliotheken zu verwenden. Dadurch erhalten Ihre Webansichten eine Reihe von Funktionen, die Sie sonst selbst erstellen müssten, z. B. eine Web-zu-native-Brücke, um von JavaScript zu nativem Code und umgekehrt zu kommunizieren, die Möglichkeit, auf Lebenszyklusereignisse zuzugreifen, sowie den Zugriff zu einer Fülle von Cordova-Plugins. Alternativ stehen einige andere Web-to-Native-Bridges für die verschiedenen Plattformen zur Verfügung, wenn Sie die Abhängigkeit von Cordova vermeiden möchten.

Es gibt einige Frameworks, die Ihnen dabei helfen, Apps auf diese Weise zu erstellen, z. B. Supersonic und Astro, ein natives App-Framework, das wir erstellen, um es einfacher zu machen, die Komplexität der Erstellung von Apps sowohl mit nativen als auch mit Webschnittstellen zu verwalten.

Fazit

Mit Beyond the Rack haben wir uns zum Ziel gesetzt, eine App zu entwickeln, in der wir den Benutzern einfach einen Mehrwert liefern können, ohne die Erfahrung zu opfern. Wir glauben, dass wir genau das erreicht haben, indem wir einem Ansatz folgen, der die Technologie in den Hintergrund rückt und es uns ermöglicht, die richtige Technologie für die Aufgabe zu verwenden. Bei jeder Änderung oder Einführung eines Features werden wir uns immer fragen: „Welche Erfahrung wollen wir hier gestalten, die das Problem des Benutzers am besten löst? Erfordert diese Erfahrung den Einsatz von fortschrittlicher Leistung oder Animationen?“

Die Antwort auf diese Frage hängt davon ab, ob wir die Funktion mit Webtechnologie erstellen und im Browser sowie auf Android und iOS wiederverwenden oder für jede Plattform individuell erstellen.

Letztendlich glaube ich, dass Apps so gebaut werden sollten. Aber es wird ein Umdenken erfordern. Anstatt zu versuchen festzustellen, ob das Web über die native Technologie triumphieren oder zu einem Relikt der Vergangenheit werden wird, sollten wir das Beste von beidem annehmen. Wir sollten die jeweiligen Vor- und Nachteile erkennen und die Technologie einsetzen, die für das jeweilige Feature am sinnvollsten ist.