→ Live in der Galerie: /design#schreibweise (BF-232).
Deutsch, förmliches „Sie", durchgängig. Auch in Fehlermeldungen und Knopfbeschriftungen.
Das Produkt heißt Bauwerksbuchhaltung, kurz BWBH. Ausgeschrieben beim ersten Auftreten in einem Text, danach BWBH. Nicht „die App", nicht „das Tool", nicht „BWB".
Keine Geviertstriche. Wo ein Gedanke abgesetzt gehört, tun es Komma, Doppelpunkt,
Klammer oder ein neuer Satz. Ein — mitten im Satz liest sich wie diktiert und nicht wie
geschrieben.
Die Regel stand hier seit jeher und wurde trotzdem 69-mal gebrochen (BF-396). Zwei Gründe, beide lehrreich:
- Der Wächter sah nur ein Viertel der Anwendung.
e2e/typografie-und-verlauf.spec.tsprüfte vier Routen und nurmain— Anmeldung, Registrierung und der Posteingang des Fachpartners standen nicht darin, Seitenleiste und Bänder lagen ausserhalb vonmain. Er meldete Ruhe für Bildschirme, die er nie angesehen hatte. Jetzt: mehr Routen,bodystattmain, und ein eigener anonymer Block für die öffentlichen Seiten (mit gespeicherter Sitzung sieht man/loginnie so wie ein Neuer — die Lehre aus BF-389). - Der naheliegende Ersatz ist falsch. „ — " durch „, " zu tauschen erzeugt im Deutschen einen Kommafehler, sobald ein Hauptsatz folgt („Bitte wenden Sie sich an uns, wir klären das gemeinsam"). Richtig ist Punkt und Grossbuchstabe als Vorgabe — das ist immer grammatisch, auch wenn ein kurzes Satzfragment entsteht — und Komma, Doppelpunkt oder Semikolon nur dort, wo wirklich eine Apposition folgt. Wer das automatisiert, liest danach jede geänderte Zeile.
Das alleinstehende — als Platzhalter für „kein Wert" bleibt: das ist Typografie, keine
Prosa. Der Test unterscheidet die beiden über die Leerzeichen ringsum.
Pflicht- und Wahlfelder sind BEIDE gekennzeichnet (BF-396). Ein Stern in --danger am
Pflichtfeld, ein graues „(optional)" am freiwilligen, und einmal darunter die Legende „Mit *
gekennzeichnete Felder sind erforderlich". Drei Werte, EINE Quelle
(registrierung.pflichtStern / .pflichtLegende / .optionalSuffix) — dieselbe
Kennzeichnung taucht in Anmelde-, Kunden- und Fachpartnerformular auf, und dreimal getippt
sähe sie irgendwann verschieden aus. Genau das war der Fall: ein Feld trug „(optional)" fest
im deutschen Text und damit in Schwarz, alle anderen den grauen Zusatz. Dasselbe Wort in zwei
Farben liest sich als Bedeutungsunterschied.
Der Stern ist aria-hidden: das Feld trägt sein required bereits, ein Screenreader sagt
„erforderlich" ohnehin, und ein vorgelesenes „Stern" wäre die zweite, schlechtere Ansage.
Bedienhöhen kommen aus dem System, nicht aus dem Gefühl. Button (Vorgabe), Input und
Select stehen auf h-10 (40 px); Button size="sm" auf h-9. Ein neues Bedienelement,
das über oder zwischen solchen Feldern sitzt, nimmt dieselbe Höhe. Ein Zwischenschritt mit
44 px (Apples Untergrenze für Tippziele) sass beim Reiterschalter der Anmeldung sichtbar zu
hoch — an dieser Stelle wiegt die Einheitlichkeit schwerer, und 40 px sind bei rund 200 px
Breite ein bequemes Ziel. Wo ein Ziel wirklich klein wäre (ein reiner Textlink), hilft
Polster statt einer Sondergrösse.
Aller sichtbare Text lebt in content/de.ts, nicht im JSX. Das ist keine Formalie: es
lässt Copy ändern, ohne Komponenten anzufassen, und macht sichtbar, wie das Produkt
eigentlich klingt.
Ein Bedienelement sagt, was passiert. „Auftrag zurückziehen", nicht „Absenden". Danach bestätigt die Rückmeldung in derselben Sprache: „Auftrag zurückgezogen."
Fehlermeldungen erklären zwei Dinge: was schiefging und wie man es behebt. Keine Entschuldigungen, keine Vagheit, keine technischen Innereien.
„Das Passwort muss mindestens 12 Zeichen lang sein." nicht „Validierungsfehler."
Fachbegriffe in der Sprache der Branche. Objekt, Frist, Mangel, Prüfbericht, Sachverständiger, Hausverwaltung. Nicht Entity, Deadline, Issue.
