Oberflächen mit UI Kit gestalten

Oberflächen mit UI Kit gestalten

0:00 Jetzt kommt der Teil, auf den die meisten gewartet haben: die Oberfläche. Und hier passiert etwas Interessantes. Wer aus der Web-Entwicklung kommt, ist es gewohnt, dass Gestaltung Arbeit bedeutet — Layout, Abstände, Farben, Zustände, Barrierefreiheit. Bei UI Kit fällt ein großer Teil davon weg, weil die Bausteine fertig sind und aussehen wie das Produkt.

0:21 Was bleibt, ist die eigentlich schwierigere Arbeit: zu entscheiden, was auf der Fläche überhaupt zu sehen sein soll. Dieses Modul zeigt beides — die Bausteine und die Entscheidungen, die sie Ihnen nicht abnehmen.

Oberflächen mit UI Kit gestalten

0:35 Der zweite Tag hat einen einfachen Bogen. Am Vormittag lernen wir die Bausteine kennen und bauen damit die Oberfläche von Klarpfad. Am Nachmittag geht es darum, was von Ihrer React-Erfahrung hier trägt und was nicht. Am Ende des Tages steht eine bedienbare Oberfläche — noch ohne echte Daten, aber mit allem, was eine ernsthafte Oberfläche ausmacht: Formular, Prüfung, Ladezustand und Fehlerfall.

ForgeReconciler und Komponentenaufbau

0:59 Beginnen wir ganz vorne, beim Einstiegspunkt. Er ist kurz — aber er erklärt, wo UI Kit wie React funktioniert und wo es eigene Regeln hat. Der Name ForgeReconciler klingt sperrig, meint aber etwas Einfaches. In der Web-Entwicklung übersetzt React Ihre Komponenten in DOM-Elemente. Hier übersetzt sie ein anderer Übersetzer — eben der Reconciler — in Bausteine, die die Atlassian-Oberfläche selbst zeichnet.

1:25 Für Sie ändert sich damit weniger, als man denkt: Darunter gilt React wie gewohnt. Sie zerlegen in Komponenten, halten Zustand in useState oder useReducer und reichen Werte über Props weiter. Der Unterschied liegt nicht in der Denkweise, sondern in der Menge der verfügbaren Bausteine. Zehn Zeilen, und darin steckt die halbe Architektur. Beachten Sie die beiden Import-Zeilen: React kommt aus react, die Komponenten aus dem Forge-Paket.

1:52 Diese Trennung werden Sie den ganzen Tag über sehen — Hooks aus React, Bausteine aus Forge. Der Aufruf am Ende ersetzt das, was in einer Web-Anwendung das Einhängen in ein Wurzel-Element wäre. Worauf es ankommt: Es gibt genau einen solchen Aufruf, und er steht in der Datei, die im Manifest als Ressource eingetragen ist. Wenn die Oberfläche leer bleibt, ist diese Verbindung die erste Stelle, an der man nachsieht.

2:18 Auch wenn React gilt — die Komponenten schneidet man hier anders. Der Grund: Es gibt keine Hilfskomponente, die eben mal eigenes HTML kapselt, also entsteht Wiederverwendung ausschließlich über Props. Und weil fast alle Daten asynchron nachkommen, liegt Zustand näher an der Oberfläche als in einer klassischen Anwendung. Kleine Komponenten zahlen sich hier deshalb stärker aus als sonst: Wenn eine Liste nachlädt, während der Rest schon steht, will man nicht die halbe App neu rendern.

2:45 Das klingt nach einem Detail und wird am Ende des Tages ein sichtbarer Unterschied. Der erste Punkt ist der Reflex des ersten Tages: Die Komponentenbibliothek aus dem Webprojekt soll mit — und scheitert, weil sie HTML erzeugt. Der zweite ist der Prototyp, der nie aufgeräumt wurde: die ganze App in einer Datei. Das funktioniert erstaunlich lange und wird genau dann unangenehm, wenn jemand anders etwas ändern soll.

3:10 Und der dritte ist ein Muster aus großen Web-Anwendungen: ein globaler Zustand für etwas, das nur eine einzige Liste betrifft. In einem Panel mit wenigen Komponenten ist das nur Ballast.

Layout und Darstellung

3:21 Jetzt zu den Bausteinen selbst. Die gute Nachricht vorweg: Es sind weniger, als Sie erwarten, und sie reichen weiter, als Sie erwarten. Hier ist der wichtigste Denkwechsel des Tages. Anordnung entsteht nicht mehr über Stylesheets, sondern über Komponenten: Stack setzt untereinander, Inline nebeneinander, Box umschließt und gibt Abstand.

3:42 Abstände geben Sie als Token an, etwa space.100 — also nicht in Pixeln, sondern in Stufen einer Skala, die das Produkt vorgibt. Das fühlt sich zunächst nach Einschränkung an und ist in Wahrheit eine Abkürzung: Ihre App sieht damit automatisch aus wie Jira, auch wenn Atlassian das Design morgen ändert. Lesen Sie diese Tabelle als Ordnung, nicht als Liste zum Auswendiglernen.

4:05 Die Bausteine sortieren sich nach Aufgabe: anordnen, Text tragen, Status zeigen, Listen darstellen, Aktionen anbieten, etwas überlagern. Wenn Sie vor einer Gestaltungsfrage stehen, fragen Sie zuerst nach der Aufgabe — die passende Komponente finden Sie dann fast von selbst. Die Fußzeile verdient Aufmerksamkeit: Einzelne Bausteine sind als Vorschau oder Frühzugang gekennzeichnet.

4:28 Das ist kein Warnschild, aber ein Hinweis, vor dem Einsatz kurz den Stand zu prüfen — am fünften Tag sprechen wir darüber ausführlicher. Dieses kleine Beispiel zeigt das Prinzip besser als jede Erklärung. Außen ein Stack, der untereinander setzt. Darin ein Inline, das Überschrift und Status nebeneinander stellt und vertikal ausrichtet. Darunter eine Textzeile mit der Zuständigkeit.

4:52 Worauf es ankommt: Nirgends steht, wie viele Pixel Abstand gehalten werden oder welche Schriftgröße gilt. Sie beschreiben die Struktur, das Produkt liefert die Gestaltung. Und genau deshalb sieht diese Zeile in jeder Jira-Instanz richtig aus — auch in der mit dem dunklen Design. Der erste Punkt ist ein alter Bekannter aus der HTML-Zeit: Abstände mit leeren Zeilen erzeugen. Das rächt sich, sobald jemand die Schriftgröße ändert.

5:17 Der zweite betrifft die Wahl des Bausteins — eine Tabellenkomponente für drei Einträge ist wie ein Aktenschrank für drei Zettel. Und der dritte ist eine Frage, die uns später bei der Barrierefreiheit wieder begegnet: Wenn der Status nur in der Farbe steckt, ist er für einen Teil Ihrer Nutzenden schlicht nicht vorhanden.

Formulare und Validierung

5:36 Kommen wir zum Formular — dem Ort, an dem aus einer Anzeige eine Anwendung wird, und zugleich dem Ort, an dem die meisten Fehler entstehen. UI Kit bringt für Formulare eine eigene Mechanik mit. Der Hook useForm übernimmt die Verwaltung: Er meldet Felder an, sammelt Werte, hält fest, welches Feld berührt wurde, und liefert die Fehler.

5:56 Das erspart Ihnen eine Menge Zustand, den man sonst von Hand führt. Was er Ihnen nicht abnimmt, ist die Entscheidung, was überhaupt geprüft wird — und, viel wichtiger, wo verbindlich geprüft wird. Behalten Sie diesen Gedanken im Kopf: Was hier im Formular passiert, ist Komfort. Verbindlich wird es erst im Backend, und darüber sprechen wir morgen.

6:17 Das Muster ist immer dasselbe, und wenn Sie es einmal gesehen haben, wiederholt es sich für jedes Feld. Der Hook liefert drei Dinge: eine Funktion zum Anmelden eines Feldes, eine Funktion, die das Absenden umschließt, und den Zustand mit den Fehlern. Das Feld wird angemeldet und dabei gesagt, dass es Pflicht ist. Und die Fehlermeldung erscheint nur, wenn für dieses Feld tatsächlich ein Fehler vorliegt.

6:41 Worauf es ankommt: Die Meldung gehört zum Feld, nicht an den Rand des Formulars. Wer sucht, wo der Fehler steckt, hat schon verloren. Der rote Faden dieser fünf Schritte ist die Vollständigkeit. Die ersten beiden sind Handwerk — Felder benennen, anmelden, beschriften. Der dritte ist der, den man gerne abkürzt: Fehlermeldungen je Feld formulieren, nicht pauschal.

7:03 Der vierte ist der wichtigste Schritt für den Alltag: Die Schaltfläche sperren, während gesendet wird. Ohne das erzeugt ein ungeduldiger Doppelklick zwei Einträge — ein Fehler, der im Test nie auftritt und im Betrieb ständig. Und der fünfte macht aus einem Formular ein Werkzeug: zurücksetzen und Rückmeldung geben, damit klar ist, dass etwas passiert ist.

7:25 Diese drei stehen in der Reihenfolge, in der sie im Betrieb auffallen. Der Doppelklick erzeugt zwei Einträge — das merkt der erste Nutzer am ersten Tag. Die Fehlermeldung benennt die Regel statt die nötige Korrektur: „Ungültige Eingabe" hilft niemandem, „Bitte ein Datum in der Zukunft wählen" schon. Und das fehlende Label fällt oft nie auf, weil es optisch aussieht wie ein Label — bis jemand mit einem Vorleseprogramm vor dem Formular sitzt.

7:51 Womit wir beim nächsten Kapitel wären.

Zustände und Barrierefreiheit

7:54 Zwei Themen in einem Kapitel, und das ist kein Zufall: Beide entscheiden darüber, ob eine Oberfläche im Alltag hält oder nur in der Vorführung. Eine Forge-App lädt ihre Daten fast immer nach. Damit hat jede Fläche in Ihrer App nicht einen Zustand, sondern vier: sie lädt, sie ist leer, sie hat einen Fehler, oder sie zeigt Inhalt.

8:13 Wer nur den letzten baut, baut eine Oberfläche, die genau in der Vorführung funktioniert. UI Kit hält für die anderen drei eigene Bausteine bereit. Und weil diese Bausteine aus dem Design System kommen, bringen sie Beschriftung, Kontrast und Tastaturbedienung gleich mit — Barrierefreiheit ist hier kein zusätzliches Projekt, sondern der Standardweg.

8:34 Achten Sie auf die Reihenfolge — sie ist das eigentliche Muster. Zuerst das Laden, dann der Fehler, dann der Leerstand, und erst danach der Inhalt. Jeder dieser Fälle verlässt die Funktion sofort. Das liest sich fast langweilig, und genau das ist die Absicht: Diese vier Zeilen stehen in jeder Komponente, die Daten holt, immer gleich.

8:54 Wenn Sie in einem Review eine Komponente sehen, die direkt mit dem Inhalt beginnt, wissen Sie sofort, welche Fragen zu stellen sind. Das ist eine der angenehmsten Eigenschaften dieser Plattform, und sie wird selten ausgesprochen. In einer freien Web-Anwendung ist Barrierefreiheit ein eigener Arbeitsstrang: Rollen, Beschriftungen, Kontraste, Fokusreihenfolge.

9:15 Hier bringen die Komponenten das mit, solange Sie bei ihnen bleiben. Der entscheidende Halbsatz steht im letzten Punkt: Eigene Konstruktionen verlieren genau diese Eigenschaften wieder. Eine anklickbare Textzeile statt eines Buttons ist optisch dasselbe und für die Tastatur ein Loch. Bequemlichkeit an dieser Stelle kostet später am meisten.

9:35 Der erste Punkt ist ein Wahrnehmungsproblem: Ohne Ladezustand wirkt das Panel beim Öffnen einfach leer, und Nutzende schließen es wieder, bevor die Daten da sind. Der zweite ist der häufigste Fehler überhaupt — leer und Fehler zeigen dieselbe Meldung, und niemand weiß, ob nichts da ist oder etwas kaputt. Der dritte ist der, über den wir eben gesprochen haben: der Button, der keiner ist. Er sieht richtig aus, verhält sich aber falsch, sobald jemand die Maus weglegt.

Übung

10:02 Jetzt bauen Sie das alles zusammen — und zwar so, dass die Oberfläche auch ohne Maus und ohne Daten eine gute Figur macht. Klarpfad bekommt in dieser Übung seine Oberfläche: eine Liste der offenen Entscheidungen und ein Formular, um eine neue zu erfassen. Ein Eintrag hat Titel, Begründung, Status und eine zuständige Rolle. Gespeichert wird bewusst noch nichts — die Daten leben im Zustand der Komponente.

10:26 Das ist keine Faulheit, sondern Methode: Solange kein Backend dranhängt, lässt sich die Oberfläche in Ruhe durchdenken. Morgen kommt die Verbindung nach hinten, und dann sind Sie froh, wenn vorne schon alles sitzt. Lesen Sie das Erfolgskriterium genau, denn es enthält zwei Anforderungen, die gerne untergehen. Erstens: Liste und Formular sind allein per Tastatur bedienbar.

10:49 Legen Sie die Maus für zwei Minuten weg und probieren Sie es — das ist der schnellste Test, den es gibt. Zweitens: Laden, Leerstand und Fehler sind je eigens dargestellt, also drei verschiedene Anblicke. Wer früh fertig ist, ergänzt einen Filter über den Status. Der ist nicht nur Beiwerk — er kommt am vierten Tag noch einmal vor, wenn wir generierten Code prüfen.

11:12 Die Reihenfolge ist bewusst so gewählt: erst die Liste, dann das Formular, dann die Zustände, dann der Schutz vor der doppelten Absendung. Wer mit dem Formular beginnt, hat nichts, worin der neue Eintrag erscheinen könnte. Der letzte Schritt ist der lehrreichste und wird am häufigsten übersprungen: Tauschen Sie die Plätze und bedienen Sie eine fremde Oberfläche nur mit der Tastatur.

11:33 Sie werden in zwei Minuten mehr finden als in zwanzig Minuten Selbstprüfung — weil Sie eben nicht wissen, wo die Schaltflächen sind. Drei Muster, die in fast jeder ersten Fassung auftauchen. Das Formular steht dauerhaft offen und drängt die eigentliche Liste an den Rand — obwohl Erfassen der seltenere Fall ist. Die Statusangabe steckt nur in der Farbe. Und der Leerzustand blitzt kurz auf, während die Daten noch laden, weil die Reihenfolge der Zustände nicht stimmt.

12:00 Der letzte Punkt ist die schöne Überleitung auf morgen: Sobald echte Daten und echte Antwortzeiten ins Spiel kommen, ist diese Reihenfolge kein Detail mehr.