Cross Plattform UI - Ein Trauerspiel

Veröffentlicht am

Einführung

Zuerst einmal zum Begriff "Cross Plattform UI". Ich verstehe darunter grundsätzlich "Eine UI für alle gängigen Plattformen". Im nativen Bereich meint man hier so gut wie immer ein Betriebssystem (Windows, Linux, Mac, Android ...) oder eine Laufzeitumgebung (Java Runtime Environment, .NET Runtime, Python, ....). Oder im Web von einem Browser (Chrom[ium]/Firefox, Safari, ...). Soweit so gut, also viele Plattformen, selbe Benutzeroberfläche.

Wo liegen jetzt Probleme?

Nativ und doch plattformunabhängig

Klingt doch toll oder? - Ich designe eine Oberfläche genau einmal und verwende sie auf allen meinen Zielplattformen. Doch nicht immer will der Nutzer auf jeder Platftorm die gleiche UI sehen, vielleicht will er nicht mal merken das er gerade eine Systemanwendung verlässt. Es soll sich heimisch anfühlen aber trotzdem ohne große Einarbeitungszeit funktionieren. Das lässt sich natürlich nicht auf jede Software anwenden und ist nicht immer eine explizite Anforderung aber doch ein indirektes Bedürfnis vieler Nutzer.

Size matters

Und dann wär da noch das Problem mit der Plattform. Die Anwendung soll ja relativ klein sein, wenn wir von der Dateigröße reden und natürlich möglichst wenig Abhängigkeiten haben und am besten auch auf einer neuen aufstrebendenen Plattform funktionieren. Doch natürlich hat jede Anwendung Anforderungen die sehr speziell sind oder eine Laufzeitumgebung benötigen oder zumindest für eine bestimmte Umgebung kompiliert werden müssen. Genau hier liegt das Problem. Wir sind plattformübergreifend, aber nicht unabhängig.

HTML5 - die Endlösung?

Natürlich bin ich ja nicht der Erste, der sich Gedanken über das ganze macht, dafür haben wir ja HTML5, CSS3 und schöne native APIs die in unserer Sandbox in einem Browser laufen, weil den gibt es ja für jede Plattform. Jede? - Nein, nur für die die der Hersteller des Browser für sinnvoll erachtet. Also ist ein Browser ja wie schon erwähnt nur eine weitere Plattform, man hat eine breitere Basis als nur eine Laufzeitumgebung oder ein Betriebssystem. Und heute hat natürlich jeder auf seinen PC einen Browser. Ob den Standardbrowser der mitgeliefert wird oder seine eigene Software. Grundsätzlich sollten alle Browser die gleichen Features unterstützen was die Technologien betrifft. Als Webentwickler weiß man, dass das nicht immer ganz zutreffend ist. Gerade bei exotischen Features tuen sich doch sehr schnell große Unterschiede auf. Dann heißt es, arbeiten wir mal für jeden Browser einzeln eine Lösung aus. An dieser Stelle sei zum Beispiel auf unseren Liebling Internet Explorer verwiesen. Das liegt oft daran das nicht jeder Hersteller gleich schnell Features implementiert. So hängt jeder zu Beginn erstmal seinen Präfix davor, entweder mangels Standardisierung oder zur Bereitstellung experimenteller Schnittstellen.
Hier ein kleines Beispiel:

-webkit-box-shadow: 10px 10px 5px 0px rgba(0,0,0,0.75);
-moz-box-shadow: 10px 10px 5px 0px rgba(0,0,0,0.75);
box-shadow: 10px 10px 5px 0px rgba(0,0,0,0.75);

Hierbei handelt es sich um einen Schlagschatten für Elemente, einmal für Webkit-basierende Browser, Mozilla Firefox und dann für alle die es jetzt komplett unterstützen. Die ersten zwei sind für die aktuellen Versionen mittlerweile lange überfällig. Aber aus Gründen der Rückwärtskompatibilität wird natürlich auch noch für die alten Versionen mit gearbeitet und so alles dopellt angegeben. Natürlich kann man das ganze durch SASS/LESS sauber und unkompliziert nicht redundant lösen. Grundsätzlich müsste man aber bei einer Änderung des Schlagschatten sich um die anderen Browser auch kümmern.
Das sind jetzt aber nur Unterschiede der Präfixe, nicht einer ganzen Funktionalität die nachträglich durch Polyfills nachgeschoben werden muss. So kommt man bei Internet Explorer gerne mal auf dutzende Polyfills um die Anwendung mit einem modernen Framework überhaupt laden zu können.

Zusammenfassung der Probleme

Eine wirklich plattformunabhängige Lösung gibt es also nicht. Wir können nur die "Big Player" abdecken. Wir können auf eine Abstraktionsebene wie einen Browser und deren Sandbox zurückgreifen. Müssen dafür aber mit Unterschieden leben und versuchen alle Platformen zu bedienen, hierbei natürlich wieder auf Verdacht und hauptsächlich die Großen.

Mögliche Lösungen?

Einheitliche Basis

Im Web sind wir mittlerweile schon recht weit, was Standards angeht, sie werden gemeinsam von großen führenden Unternehmen aber auch Hobbyisten gemeinsam entwickelt und relativ schnell implementiert. Aber das reicht noch nicht. Für manche Anwendung braucht man oft nativen Zugriff auf z. B. das Dateisystem und vieles mehr. Hier ist gerade bei Chrom(e/ium) schon viel möglich, aber eben noch nicht genug. Man ist immer darauf angewiesen das der Browserhersteller die Änderungen unterstützt.

Wünschenswert, aber sehr unwahrscheinlich wäre schon auf OS-Ebene eine einheitliche API für den Zugriff auf native Funktionen oder etwa sogar direkt eine klare Schnittstelle für das Rendering mittels einer Markup-Sprache, nicht zwingend HTML5. So hat man die Vorteile der entsprechenden Plattform, geringe Größe von Programmen und gleichzeitig eine wirkliche Unabhängigkeit. Logischerweise würden sich dann alle Hersteller einigen müssen was aber mit Willen des Nutzers zu realisieren sein sollte. Doch leider ist vielen Anwendern das Problem nie real bewusst da wir Entwickler dafür sorgen das der User eben nicht mit solchen Problemen konfrontiert wird. Was ja grundsätzlich auch nichts schlechtes ist, wobei hier auch nicht wirklich erwartet werden kann das jeder so technisch versiert ist. Viele kommen hier z. B. über die klassichen Office-Tools und Mailprogramme nie hinaus.

So ist diese Lösung doch leider relativ unrealisistich.

Der Browser

Die Tendenz neigt sich immer mehr in Richtung Browser. Er ist eine mächtige Platform, so gut wie jeder unterstütz heute JavaScript, moderne APIs und schon teilweise native Zugriffe sowie Aufzeichung von Audio- und Bildmaterial. Wir verlagern dadurch die Probleme auf die Hersteller von Browsern bzw. auf die Standardisierung des Web. Und damit auch den großen Konzernen, ob dies nun so gut ist, muss jeder für sich selbst entscheiden.

Ich blicke dem ganzen kritisch aber auch gespannt entgegen. Gerade nach der Ankündigung von Web Authentication für die "Big Three" der Browser. Das Web wird so wieder ein Stück nativer. Aber auch WebAssembly ermöglichen heute schon eine fast native Ausführungsgeschwindigkeit für Apps mit extremen Anforderungen an die Performance.

Fazit

Als einzelner Entwickler haben wir vielleicht nicht immer einen direkten Einfluss auf die zukünftige Entwicklung der genannten Technologien. Aber doch können wir mitwirken und mitentwicklen um in Zukunft Cross Platform UI standardmäßig zu unterstützen. Ohne sage zu müssen: "Unsere Software ist leider nur für Windows verfügbar".

Ich freue mich schon auf die zukunüftigen Entwicklungen und wer weiß, vielleicht arbeiten wir in wenigen Jahren schon mit einer einheitlichen Markup-Sprache und entwickeln tolle Oberflächen für alle Plattformen über eine standardisierte Zwischensprache, die nativ und doch unabhängig für den Nutzer präsentiert wird.

Natürlich freue ich mich über Feedback zum Post oder auch Diskussionen sowie Anregeungen rund um das Thema Cross Plattform UI.