Stay Humble

Aber wartet kurz, dieser hier ist anders. Wir haben die Beiträge über Lesbarkeit und Geschmack gelesen, über die Windows-Vista-Witze gelacht und uns längst eine Meinung gebildet.

Dieser Text bringt Design und Technik zusammen. Es geht um Standards und Spezifikationen. Und am Ende liefere ich Ihnen eine Pointe, neben der selbst die Vista-Witze alt aussehen. Wir befinden uns in IE6 Terrain.

Exkurs: Was wisst ihr über Viewports?

Ein Viewport ist der Teil des Bildschirms, den eine Website tatsächlich nutzen kann.
Die entscheidende Frage lautet: Was ist die Funktion eines Viewports?

Im Web bezeichnet er den Bereich, den der Browser einer Seite zur Verfügung stellt. Dieser Bereich ist durch Standards definiert und interaktiv. Alles außerhalb gehört zum Betriebssystem.

Im Laufe der Zeit wurden neue CSS-Einheiten eingeführt, um dynamische Viewports abzubilden:

• vh (viewport height): die klassische Einheit, die volle Höhe des Browserfensters

• svh (small viewport height): Höhe bei sichtbarer Browser-UI

• lvh (large viewport height): Höhe bei ausgeblendeter UI

• dvh (dynamic viewport height): passt sich dynamisch an, wenn UI ein- oder ausgeblendet wird. Sie hat es Entwicklern ermöglicht, Overlays – insbesondere auf mobilen Geräten – besser zu optimieren

• Safe Areas: später eingeführt für Notches und abgerundete Ecken, vor allem unter iOS

All diese Einheiten existieren, um die Antwort auf das Was verlässlich zu machen: Was gilt als sichtbarer, interaktiver Bereich einer Website? Apple hat diese Definitionen maßgeblich mitgeprägt.

Aus gestalterischer Sicht ist der Viewport der Rahmen, den der Browser an Designer und Entwickler übergibt. Alles innerhalb gehört zur Seite und kann gestaltet werden. Alles außerhalb gehört zum System.

Diese klare Trennung ist essenziell. Und sie wäre die richtige Antwort auf die Frage gewesen, die sich Apples Designteam hätte stellen müssen:

„Was gestalten wir hier eigentlich?“

Das Problem: Es hätte mit dem „Was?“ beginnen müssen

Hier hätten die Alarmglocken läuten müssen.

Apples Designteam hat nicht damit begonnen zu klären, was sie eigentlich gestalten. Der Fokus lag auf dem Wie. Diese Verschiebung – von Definition hin zu Darstellung – ist die Wurzel des Problems. Und sie zeigt sich inzwischen quer durch Apples gesamte Betriebssystemlinie, mit hoher Wahrscheinlichkeit auch in zukünftigen Versionen.

Die Browser-UI wurde als transparente Schicht neu gedacht.
Visuell schwebt sie über der Seite und lässt Inhalte durchscheinen.

Technisch gehört sie jedoch nicht zum Viewport. Es entsteht ein Pseudo-Viewport.

Das Ergebnis ist ein Widerspruch: Nutzer sehen Inhalte in Bereichen, auf die Entwickler keinen Zugriff haben und die sie nicht kontrollieren können.

Aus gestalterischer Sicht bricht das den grundlegenden Vertrag.
Der Browser liefert keinen neutralen Rahmen mehr. Die Grenze zwischen System und Website verschwimmt – zwischen dem, was zum Inhalt gehört, und dem, was Teil des Betriebssystems ist.

Es werden Elemente sichtbar, die aussehen, als gehörten sie zur Seite, es aber nicht tun.

Millionen von Websites, die für mobile Nutzung optimiert wurden, laufen plötzlich in Darstellungs- und Interaktionsprobleme. Selbst Apples eigene Seite kämpft mit der GUI des eigenen Browsers. Dialoge auf Produktseiten ändern die Theme-Farbe, nur um sich dem Hintergrund des Overlays anzupassen.

Das Ergebnis: eine grellweiße Lücke am unteren Rand einer eigentlich schwarzen Seite – und ein Layoutfehler im Overlay selbst.

Was mit einem fehlenden „Was?“ begann, endet in einem ziemlich lauten WTF.

Stay humble

Design und Entwicklung teilen eine gemeinsame Bürde:
Ihre Arbeit wird erst sichtbar, wenn sie scheitert.

Ein gut funktionierendes UI fällt kaum auf.
Aber es fällt auf, wenn sich ein scrollbares Overlay nicht schließen lässt oder Text schwer lesbar ist.

Deshalb ist es entscheidend, die richtigen Fragen zur richtigen Zeit zu stellen.
Nicht nur, wie etwas aussieht – sondern was es ist, was es tut und für wen es gemacht ist.

Es ist leicht zu vergessen, dass die Aufgabe von UI darin besteht zu dienen, nicht zu glänzen. Vor allem in einer Zeit, in der soziale Medien voller Screenshots von „coolen“ Launch-Screen-Konfigurationen sind.

Im Fall von Liquid Glass hat der visuelle Effekt seine Funktion überlagert. Ein Darstellungsstil hat genau die Regeln außer Kraft gesetzt, auf die Designer und Entwickler angewiesen sind.

Das ist kein mutiges Design.
Das ist Nachlässigkeit.

Es macht den Anschein, dass die Glasbausteine auf der Keynote nicht nur eine Metapher waren.
Sie haben gebaut, was sie gezeigt haben. Und genau dort haben sie den Faden verloren.

Demut ist keine ästhetische Zurückhaltung.
Sie ist Respekt vor dem Kontext, in dem die eigene Arbeit erscheint. Vor Standards. Vor Nutzern. Und vor der Grenze zwischen Sichtbarkeit und Kontrolle.

Das kann am Anfang der eigenen Laufbahn frustrierend sein, wenn man seine gestalterischen Fähigkeiten zeigen möchte. Aber mit der Zeit wird klar: Die eigentliche Leistung besteht darin, Design verschwinden zu lassen – weil es einfach funktioniert.

Und ja, das lässt Raum für starke visuelle Ideen.
Es setzt nur zuerst die richtigen Grenzen.

Lösung: Und jetzt?

Das ist nicht nur eine Designkritik. Es ist ein Appell an die Verantwortung aller Beteiligten.

Nutzer
Wenn Websites, die man regelmäßig nutzt, unter Safaris neuer UI anfangen zu brechen, zu glitchten oder sich seltsam verhalten, wechselt den Browser.

Das ist die einzige Botschaft, die bei Apple ankommt.

Entwickler
Ihr habt drei Optionen: Workarounds bauen. Die Probleme ignorieren und Layoutfehler in Kauf nehmen. Oder das tun, was wir früher gemacht haben, als Kunden auf Support für IE6 bestanden haben: extra berechnen.

Keine dieser Optionen ist gut.
Aber sie bilden die Realität ab.

Apple
Nehmt euch einen Moment. Tretet einen Schritt zurück.
Schaut euch an, was ihr ausgeliefert habt.

Dann geht zurück an eure Schreibtische.
Stellt zuerst die richtige Frage. Und fixt es.

Still und heimlich ist okay.
Aber, bitte richtig.

Und: Stay humble.