Inhalt
- 1. Eine eingebettete Webansicht ist kein Webbrowser
- 2. Die resultierende Navigation ist ein Kompromiss
- 3. Plattformübergreifend ist nicht einmal ein "nobles Ziel"
- 4. Du musst mit der Plattform kämpfen
- 5. Zu schön um wahr zu sein
Eine kürzere Version dieses Artikels erschien erstmals in Ausgabe 238 des .net-Magazins - dem weltweit meistverkauften Magazin für Webdesigner und -entwickler.
XVT, wxWindows, Gtk, AWT, SWT. Diese läuten irgendwelche Glocken? Dies sind nur einige der versprochenen Toolkits, mit denen Code auf einer Plattform geschrieben und Anwendungen erstellt werden können, die nahtlos unter Windows, Mac und X Windows ausgeführt werden können.
Einige waren besser als andere; aber eines hatten alle gemeinsam:
In ihnen geschriebene Bewerbungen saugten.
Zu ihrer Ehre ist dies der einzige Ort, an dem das plattformübergreifende Versprechen tatsächlich funktioniert hat - Anwendungen, die in ihnen geschrieben wurden, saugten konsequent plattformübergreifend.
Bevor Sie auf eine obskure Anwendung hinweisen, die halbwegs anständig war, spreche ich über großartige Anwendungen. Es gab noch nie eine einzige, kommerziell erfolgreiche und großartige Anwendung, die mit einem plattformübergreifenden Toolkit geschrieben wurde.
Und jetzt werden uns diese Versprechen angeboten, Apps für iOS, Android und Windows Mobile zu entwickeln, mit denen Sie einmal überall schreiben können. Sicher, es ist eine kostengünstige Möglichkeit, überall präsent zu sein, aber hier ist der Grund, warum Sie im Stich gelassen werden.
1. Eine eingebettete Webansicht ist kein Webbrowser
Die meisten mobilen plattformübergreifenden Toolkits basieren auf HTML5, um die Knochen Ihrer App bereitzustellen, wobei die App im Wesentlichen in einem eingebetteten Webcontainer gerendert wird. Dies ignoriert einen wichtigen Punkt: Ja, das Web ist eine plattformunabhängige Plattform, aber bei der Verwendung von Web-Apps verwenden wir in der Regel das Chrome des Browsers für die Navigation. Deshalb ist es uns vertraut.
Wenn jedoch eine plattformübergreifende mobile App in einen Webcontainer eingebettet ist, ist der HTML-Code der App für die Navigation verantwortlich. Vorbei sind unsere vertrauten Steuerelemente. Stattdessen erhalten wir ein Navigationssystem, das in der Regel dem Erscheinungsbild der dominanten Plattform nachempfunden ist.
2. Die resultierende Navigation ist ein Kompromiss
Sie verwenden also HTML und haben beschlossen, die Navigation manuell zu codieren. So geht das normalerweise. Die Mehrheit der Benutzer sind (sagen wir) iOS-Benutzer. Daher entwickeln wir es mit einer schwarzen Registerkartenleiste am unteren Rand und ahmen den Stil der iOS-Registerkartenleiste nach.
Der iOS-Benutzer hasst es; Sie haben die subtile Farbänderung beim Tippen auf die Registerkarte oder den Sprung zum obersten Bildschirm beim zweimaligen Tippen nicht geschafft.
Der Android-Benutzer hasst es, weil er es entweder noch nie gesehen hat, es ist also unbekannt, oder schlimmer noch, er weiß, dass es sich um eine "iPhone-ähnliche" Benutzeroberfläche handelt, und ist nicht glücklich darüber, dass es Android-Benutzern aufgezwungen wird.
3. Plattformübergreifend ist nicht einmal ein "nobles Ziel"
In früheren Tagen hatten wir vielleicht einen PC bei der Arbeit und einen Mac zu Hause. Möglicherweise mussten wir in beiden Fällen bestimmte Tools verwenden. Dies war der Reiz, eine Anwendung auf beiden ausführen zu lassen. Aber mit unseren Smartphones ist das Leben anders. Die überwiegende Mehrheit der Benutzer hat ein einziges Telefon. Benutzer möchten Konsistenz mit anderen Apps auf ihrem Gerät und keine Konsistenz mit einer anderen Version Ihrer App auf einer anderen Plattform, die sie nicht verwenden möchten.
4. Du musst mit der Plattform kämpfen
Wenn ein Toolkit für die Arbeit auf mehreren Plattformen freigegeben wird, muss der Toolkit-Anbieter sicherstellen, dass auf allen Plattformen etwas funktioniert. Dies bedeutet tatsächlich, dass sie bestenfalls die Funktionalität des kleinsten gemeinsamen Nenners implementieren können. Wenn Feature X unter Android gut funktioniert, unter iOS jedoch nicht elegant ausgeführt werden kann, wird es nicht aktiviert.
Dies ist in Ordnung, wenn Ihre App-Funktionalität grundlegend ist. Aber was passiert, wenn Sie etwas brauchen, das innerhalb dieser Grenzen nicht einfach zu erledigen ist? Nun, dies ist der Zeitpunkt, an dem das Toolkit beginnt, Ihren Fortschritt zu behindern, und nicht hilft.
Möglicherweise finden Sie einige nette "Erweiterungen" für das Toolkit, mit denen die Funktion Y unter iOS einfach ausgeführt werden kann. Aber jetzt fangen Sie gerade erst an, plattformspezifischen Code zu schreiben, und alle versprochenen Vorteile sind weg.
5. Zu schön um wahr zu sein
Apple, Microsoft, Google: Die größten Softwareunternehmen der Welt, die die besten Köpfe beschäftigen und große Anstrengungen unternommen haben, um ihre Plattformerfahrung für ihre Endbenutzer erstaunlich zu machen. Und Sie denken, ein Toolkit und ein ausgefallenes JavaScript können einen besseren Job machen?
Die Verlockung, mit einem Mausklick auf jeder Plattform zu sein, wird für CEOs und CFOs Musik sein. Die Einfachheit dieser Aussage verbirgt die Realität. Die daraus resultierende minderwertige App wird nicht zugelassen. Schlechte Bewertungen werden das Blut des CEO zum Kochen bringen, und der CFO wird nicht glücklich sein, dass er für ein von Grund auf neu geschriebenes Schreiben bezahlen muss. Tun Sie sich selbst einen Gefallen und bewaffnen Sie sie mit den Fakten.
Durch die native Entwicklung auf jeder Plattform erhalten Sie die schnellstmögliche App, vollen Zugriff auf die Funktionen des Geräts und Frameworks, um die Entwicklung zu vereinfachen. Native SDKs sind die einzige Möglichkeit, die beste Benutzererfahrung zu gewährleisten.
Besuchen Sie Creative Bloq, um 25 Tipps für das Design mobiler Websites zu erhalten!
