Eines vorweg, ich bin Interactive Developer und daher natürlich von den Vorzügen einer Webanwendung überzeugt. Ich denke dennoch, dass man zur Zeit differenziert auf die Sache schauen muss und teilweise sind meine Vergleiche auch ein bisschen weit hergeholt.
Wie alles begann
Als ich Ende der neunziger Jahre begann Webanwendungen zu bauen, konnte man es immer wieder beobachten: die Flash Intros, die man nur mittels eines gut versteckten Skip Buttons überspringen konnte, oder gezwungen war komplett anzusehen. Oder auch tatsächlich Anbieter die auf Ihren Seiten Anwendungen zum herunterladen anboten, die einmal installiert irgendwo im Betriebssystem hingen und nicht mehr richtig deinstalliert werden konnten, aber eben den Zweck erfüllten eine starre auf Desktoplayout oder auch Markendesign fokussierte App zu präsentieren. Ich benutze hier bewusst den Begriff App, da uns dieser Begriff in Form von Apps derzeit verfolgt. Irgendwie fühlte man sich aber immer gefangen in diesen zur Verfügung gestellten Apps.
Die Webseite als offene einheitliche Schnittstelle
Irgendwann merkte man dann, dass man den Nutzern nicht einfach etwas aufdrängen konnte, was sie auf anderen Seiten offen und frei erhalten konnten und nicht gezwungen waren ein Plugin zu aktualisieren, oder eben irgendetwas herunter zu laden um das vermeintliche Glück zu finden.
Verbreitung von Viren und Malware mittels Installationsdateien führten dann irgendwann dazu, dass man nur noch aus vertrauenswürdigen Quellen installierte und dieser Schrecken hatte ein Ende.
Wir Interactive Developer warteten darauf sehnsüchtig, denn wir hatten früh bemerkt, dass die stärker werdende Standardisierung der Browserwelt die einmalige Gelegenheit bot endlich einheitliche Webangebote zu bauen, die zukunftsicher, einfach zu bedienen und noch dazu halbwegs kostengünstig herzustellen waren.
Die Sache mit dem Standard
Es gab immer wieder Browserhersteller die einem das Leben schwer machten, aber im Grunde konnte man mit einer Anwendung alles abdecken, wenn auch mancher Benutzer eben weniger ausgefeilte Designs, Animationen oder Technik zu sehen bekam als ein anderer. Progressive Enhancement war das Zauberwort. Wenn ein Browser etwas nicht unterstützte, dann war es halt einfach nicht entsprechend implementiert.
Wie kam es dazu?
Wir lernten, dass der Inhalt und nicht das Gerät wichtig ist. Inhalt und die Bedienbarkeit waren das Wichtigste für den Benutzer geworden und nicht die Befindlichkeiten oder Vorstellungen von Kunden oder Designern, die ein bestimmtes Gerät benutzten und sich deren aufgedrängtem Bedienkonzept anpassten. Ob das jetzt angepasste Formelemente waren, oder mittels JavaScript verunstaltete Scrollbalken, irgendwie hatten wir gelernt, dass der Nutzer das benutzen wollte, was er von seiner Hard- und Software gewohnt war.
Was gerade passiert
Gerade jetzt aber passiert etwas, das mich erschreckend an die Anfänge bei der Erstellung für die Desktop Browser erinnert. Entweder erwartet man zu viel von einem Gerät und muss daher auf Krücken zurückgreifen, oder man erstellt eben Software für jedes Gerät. Welcher Benutzer würde es heute akzeptieren, wenn er www.example.com auf dem Desktop Browser aufruft und bekommt zuerst einmal ein Popup präsentiert in dem er aufgefordert wird eine Installationsdatei herunter zu laden, um die Vorzüge des Unternehmens vollständig genießen zu können? Wahrscheinlich würde man wegklicken und nie wieder kommen. Heute sieht man das im mobilen Internet überall. Eingeblendete Texte die auf die neueste Android, iOS, Windows Phone usw. App hinweisen und die, wenn man Cookies nicht dauernd akzeptiert auch noch immer wieder erscheinen.
Das selbe gilt für die unsäglichen Weichen die man früher benutzte. Die Option mit oder ohne Frames ist nur ein Beispiel. Wieso muss man Ähnliches heute wieder auf der neuen App oder mobile Ebene einführen? Die Browserhersteller der modernen Smartphones geben ihre Browser nicht zu Unrecht als „screen“ und nicht „handheld“ aus. Sie können nämlich mittlerweile fast alles was ein Desktop auch kann.
Ich habe das komische Gefühl, dass jetzt, wie Jahre zuvor, inflexibles Denken und zu wenig Kreativität zu dieser Situation führen. Ein fixiertes Pixellayout ist einfach leichter zu „malen“ als sich mit technischen Besonderheiten oder Möglichkeiten wie Flexibilität, Verhalten bei verschiedenen Auflösungen, deaktiviertem Scripting, nicht geladenen Bildern, gelöschten Cookies oder wechselnden Endgeräten zu beschäftigen.
Als Entwickler, wird man plötzlich wieder mit „Cross-Device-Frameworks“ konfrontiert die einem die Arbeit abnehmen sollen um für die verschiedensten Geräte Webseiten zu bauen. Anstatt dass man auf Standards setzt. Oder man erlaubt als Gerätehersteller dem Benutzer mit dem eigenen Gerät zu machen was man will. Jetzt baut man plötzlich wieder verschiedene Templates für verschiedene Endgeräte und Auflösungen, obwohl sie im Grunde nichts anderes sind als Anzeigegeräte mit Browser und daraus resultierenden verschiedenen Fähigkeiten.
Die Kosten für das mobile Internet explodieren, und die Wartungskosten damit. Kein Wunder, dass die mobilen Angebote so dürftig sind.
Die Gerätehersteller sind aber nicht ganz unschuld an dieser Situation, wenn sie meinen, dass bestimmte Techniken keinen Sinn machen, oder man Standards einfach uminterpretiert oder eben am Verkauf einer App mitverdienen will.
Ausnahmen sind erlaubt
Und ja, Ausnahmen sind erlaubt, es gibt Gründe etwas zu installieren und die tiefere Integration in das System zu verlangen. Ein normales Webangebot wird das aber nicht sein. Diese Art Software installiert man sich auch heute noch auf dem Desktop oder Laptop. Aber die Gründe dafür werden immer weniger; Können moderne Browser heute doch schon Lokalisieren, offline funktionieren, Daten zischenspeichern oder auf die Rechenleistung der Grafikkarte zugreifen, man muss halt nur etwas unnachgiebiger sein, wenn es darum geht „State of the Art“ Webanwendungen zu bauen: dies muss nämlich nicht immer heißen: „Die von mir heruntergeladene App sieht aber so aus, also ist das gut“.
