s0up4200/mobile-adapt

Mobile Adapt

Ziel

Vorhandene Oberflächen so anpassen, dass sie auf Telefonen gut funktionieren, ohne Kernfunktionen zu entfernen. Priorisieren Sie das iPhone-typische mobile Web, es sei denn, der Benutzer nennt ein anderes Ziel.

Standardziel

Wenn der Benutzer kein Gerät oder keinen Browser angibt, optimieren Sie zuerst für:

• iPhone Pro Max-Klasse im Hoch- und Querformat
• iOS Safari
• Kompakte Touchscreens mit einer Breite von etwa 375-440 CSS px
• Tastatur geöffnet, große Schrift, Safe Areas und reduzierte Bewegung

Wann recherchieren

Dieses Skill ist auf aktuelles Plattformverhalten angewiesen.

• Durchsuchen Sie offizielle Quellen, wenn der Benutzer nach der neuesten/aktuellen Anleitung, iPhone-spezifischem Verhalten, Safari/WebKit-Besonderheiten, Safe-Area-Verhalten, PWA/Home-Screen-Verhalten oder direkten Zitaten fragt.
• Bevorzugen Sie Apple Developer, WebKit, W3C/WCAG, MDN, Android Developers und web.dev.
• Verwenden Sie absolute Daten, wenn Sie auf aktuelle Plattformänderungen verweisen.

Für die aktuellen, signalstarken Regeln und Quellen lesen Sie references/mobile-ui-2026.md.

Kernregeln

• Halten Sie kompakte Telefone einspaltig. Wechseln Sie nicht zur Desktop-IA, nur weil ein Telefon im Querformat einen generischen Breakpoint überschreitet. Ein Telefon im Querformat wird immer noch mit beiden Händen auf Armeslänge gehalten – das mentale Modell des Benutzers ist „Telefon", nicht „Tablet". Ein mehrspaltiges Layout erzeugt eine verwirrende Erfahrung, bei der nichts groß genug ist, um es bequem zu bedienen.

• Verwenden Sie die mobile Navigation am unteren Rand nur für echte Top-Level-Bereiche. Beschränken Sie sich auf 3-5 primäre Ziele; verschieben Sie Überlauf in „Mehr", ein Sheet oder sekundäre Abläufe. Der untere Bildschirmrand ist die natürliche Ruhezone des Daumens – wenn die primäre Navigation dort platziert wird, erfordern die häufigsten Aktionen den geringsten Aufwand. Mehr als 5 Elemente verkleinern die Antastziele unter eine brauchbare Größe und überfordern das Scannen.

• Jedes interaktive Ziel sollte mindestens 44x44 CSS px in beiden Dimensionen groß sein. Dies schließt sekundäre Elemente ein, die leicht übersehen werden: Inline-Aktionsschaltflächen (Bearbeiten, Löschen, Anzeigen), Auf-/Zuklapp-Schalter, Filter-Chips, Symbolschaltflächen in Symbolleisten, Schließen-Schaltflächen auf Sheets und Checkbox/Radio-Zeilen (verwenden Sie das <label> als vollständiges Antastziel, nicht nur das Input-Element allein). Kapazitive Touchscreens registrieren den Mittelpunkt der Kontaktfläche eines Fingers bei etwa 44pt – kleinere Ziele führen zu Fehldruck-Frustration, besonders in Bewegung. Häufige Tailwind-Klassen, die zu klein sind: h-8 (32px), h-9 (36px), p-1 auf einem Icon (~24px), p-1.5 (~28px), p-2 (~32px). Verwenden Sie h-11 (44px), min-h-[44px] oder Äquivalent als Basislinie für jedes antippbare Element. Dies entspricht den Apple HIG und übertrifft das WCAG 2.2-Minimum von 24px.

• Verlassen Sie sich nicht auf Hover, winzige Symboltipps oder versteckte Zeilenaktionen. Es gibt keinen Hover-Zustand auf Touch – alles, was Hover zum Entdecken erfordert, ist unsichtbar. Verwenden Sie sichtbare Steuerelemente, Wischaktionen mit einem visuellen Hinweis oder ein kontextuelles Sheet/Menü.

• Vermeiden Sie horizontales Seiten-Scrollen. Die Einhand-Bedienung eines Telefons ist vertikales Daumen-Scrollen. Horizontales Scrollen bricht das räumliche Modell des Benutzers und verbirgt Inhalte außerhalb des Bildschirms ohne sichtbaren Hinweis. Stattdessen: Umfließen, Stapeln, Paginieren oder lokales Scrollen von Tabellen und Diagrammen anstatt der gesamten Seite.

• Verwenden Sie viewport-fit=cover, env(safe-area-inset-*) und min-height: 100dvh. Moderne iPhones haben abgerundete Ecken, die Dynamic Island und den Home-Indikator – all dies beeinträchtigt den rechteckigen Viewport. Ohne explizite Safe-Area-Behandlung werden Inhalte hinter der Hardware-Chrome abgeschnitten. dvh berücksichtigt die zusammenklappbare Safari-Symbolleiste, die das alte vh nicht tut.

• Halten Sie primäre Aktionen frei von Browserleisten, dem Home-Indikator, abgerundeten Ecken und der Bildschirmtastatur. Ein „Absenden"-Button, der hinter der Tastatur oder über dem Home-Indikator versteckt ist, ist funktional defekt – der Benutzer kann ihn entweder nicht sehen oder nicht antippen, ohne eine Systemgeste auszulösen.

• Bevorzugen Sie für formular- oder tastaturlastige Abläufe einen Haupt-Scrollcontainer. Verschachtelte Scrollbereiche in iOS Safari erzeugen Scroll-Trapping: Der Daumen des Benutzers scrollt den inneren Container, obwohl er die Seite scrollen wollte, oder umgekehrt. WebKit hat hier anhaltende Fehler (siehe Referenzdatei). Verwenden Sie verschachteltes Scrollen nur, wenn es keine Alternative gibt.

• Verwenden Sie semantische mobile Eingaben. Beschriftungen über den Feldern (nicht daneben – es gibt keinen horizontalen Platz), korrekte type, inputmode, autocomplete und enterkeyhint. Diese Attribute steuern, welche Tastatur erscheint – inputmode="decimal" zeigt den Ziffernblock für Währungen an, enterkeyhint="next" ermöglicht es Benutzern, durch ein Formular zu tabben, ohne die Tastatur zu schließen.

• Behandeln Sie großen Text als echten Layout-Input. iOS-Benutzer können systemweit größeren Text einstellen, und viele tun dies. Umfließen – verstecken Sie keine Kernbedeutung hinter Abschneidungen. Wenn eine abgeschnittene Beschriftung den Benutzer raten lässt, ob er „Sparkonto" oder „Gehaltskonto" sieht, ist das Layout gescheitert.

• Diagramme unterstützen auf Telefonen die Geschichte; sie sind nicht die ganze Geschichte. Ein Telefonbildschirm kann vielleicht 5-6 lesbare Balken oder einen Donut darstellen. Das ist nicht genug Datendichte, damit das Diagramm selbsterklärend ist. Führen Sie mit der Hauptzahl und einer Textzusammenfassung; verwenden Sie das Diagramm als visuelle Verstärkung.

• Bewahren Sie die bestehende Marke und das Designsystem des Produkts, es sei denn, der Benutzer wünscht ein umfassenderes Redesign. Bei der mobilen Anpassung geht es um Layout und Interaktion, nicht um eine Neugestaltung des Erscheinungsbilds.

Beispiele

Bevor Sie eine Navigationshülle, eine Datentabelle oder ein Formular mit einem Absende-Button ändern, lesen Sie references/mobile-examples.md. Es enthält Vorher/Nachher-Code für eine Seitenleiste, die zu einer unteren Tab-Leiste wird, eine Tabelle, die auf Telefonen zu einer Kartenliste wird, und ein Formular, dessen Absende-Button über der Tastatur bleibt.

Arbeitsablauf

1. Zielkontext festlegen.
   • Gerät, Browser, Ausrichtung, Nutzungskontext
   • Standardmäßig iPhone Pro Max + iOS Safari, wenn nicht angegeben
2. Zuerst die Hülle prüfen.
   • Navigationsmodus
   • Safe Areas
   • Klebrige/feste Leisten
   • Querformatverhalten
   • Tastaturverhalten
3. Jeden Bildschirm oder jede Komponente prüfen.
   • Listen und Zeilen
   • Formulare
   • Tabellen
   • Diagramme
   • Leere/Fehler/Ladezustände
4. Den harten Übergang wählen.
   • Was wird einspaltig
   • Was wird zu Karten
   • Was wird in ein Sheet/Drawer verschoben
   • Was wird sekundär unter „Mehr"
5. Mobile-First-Anpassungen implementieren.
   • Bevorzugen Sie Container Queries für Komponenteninterna
   • Bevorzugen Sie Viewport Queries für Shell/Layout-Modus-Änderungen
   • Behalten Sie kein altes halb-Desktop/halb-Mobile-Verhalten bei, es sei denn, es wird ausdrücklich verlangt
6. Auf kompaktem Hoch- und Querformat verifizieren.
   • Safari/WebKit zuerst
   • dann Chromium
7. Berichten Sie die risikoreichsten Probleme zuerst, dann die konkreten Änderungen und eventuelle verbleibende Lücken.

Bildschirm-Checkliste

Hülle und Navigation

• Telefone im Querformat in der Telefonhülle belassen.
• Harte md => Desktop-Seitenleiste-Wechsel für Geräte vermeiden, die noch Telefone sind.
• Untere UI mit env(safe-area-inset-bottom) polstern.
• Klebrige Aktionen über der unteren Navigation platzieren.
• Mobile Beschriftungen kurz halten.

Listen und Zeilen

• Titel, Metadaten und Beträge bei Bedarf in zwei Zeilen umbrechen lassen.
• Stablen Platz für Preise, Kontostände und Summen reservieren.
• Gestapelte Metadaten gegenüber gequetschten Inline-Metadaten bevorzugen.
• Aktionen mit sichtbaren Steuerelementen oder einem Sheet/Menü bereitstellen, nicht mit Hover.
• Zeilenaktionsschaltflächen (Bearbeiten, Löschen, Anzeigen, Erweitern) auf mindestens 44x44 CSS px dimensionieren – nicht nur primäre Navigations- und Symbolleistenschaltflächen.

Formulare

• Eine Spalte auf kompakten Telefonen verwenden.
• Absenden-Button über der Tastatur sichtbar halten.
• Eine klare, vollbreite primäre CTA verwenden.
• Lange Abläufe in Schritte oder progressive Offenlegung aufteilen.
• type="number" für Währungen vermeiden, wenn Formatierung oder Genauigkeit wichtig ist.

Tabellen und Import-/Prüfungsabläufe

• Dichte bearbeitbare Tabellen auf Telefonen in Karten/Listen umwandeln.
• Wenn eine echte Tabelle bleiben muss, horizontales Scrollen auf die Tabelle isolieren.
• Klebrige Kopfzeilen und Symbolleisten davon abhalten, fokussierte Eingaben zu verdecken.

Diagramme und Statistiken

• Mit der Schlüsselzahl und einer kurzen Erzählung führen.
• Kompakte Legenden und Text-Fallback hinzufügen.
• Horizontales Scrollen oder seitenweise Vergleiche gegenüber unlesbaren dichten Balken bevorzugen.
• Winzige Kuchen/Donuts auf kompakten Bildschirmen vermeiden.

Verifikation

Überprüfen Sie für jeden der folgenden Punkte die spezifische Bestehensbedingung und verwenden Sie die empfohlenen Werkzeuge. Das Testen auf echten Geräten ist der Goldstandard – Simulatoren sind nützlich für Iterationen, können aber Tastatur-Timing, Scroll-Trägheit oder Touch-Präzision nicht vollständig reproduzieren.

• Hoch- und Querformat – Telefon bleibt in beiden Ausrichtungen in der mobilen Hülle. Kein Layout-Bruch, kein Inhaltsüberlauf, kein plötzlicher Wechsel zu einer Desktop-Seitenleiste oder mehrspaltigen Ansicht. Testen Sie bei 375px (iPhone SE/mini-Klasse), 390px (iPhone Pro) und 430px (iPhone Pro Max) im Hochformat und deren Querformat-Äquivalenten. Verwenden Sie die Chrome DevTools-Geräte-Symbolleiste oder den Xcode-Simulator.

• iOS Safari Safe Areas – Inhalte werden nicht von der Dynamic Island, abgerundeten Ecken oder dem Home-Indikator abgeschnitten. Unten fixierte Elemente haben sichtbaren env(safe-area-inset-bottom)-Abstand (~34px auf Face ID iPhones). Stellen Sie sicher, dass viewport-fit=cover im Viewport-Meta-Tag gesetzt ist – ohne dieses geben alle env(safe-area-inset-*)-Werte 0 zurück. Am besten im Xcode-Simulator testen (genaue, gerätespezifische Insets) oder Polypane 26+ (Desktop-Browser mit echten Safe-Area-Inset-Voreinstellungen). Chrome DevTools 135+ unterstützt Emulation.setSafeAreaInsetsOverride, erfordert jedoch manuelle Konfiguration.

• Tastatur-geöffneter Formularablauf – Fokussieren Sie jede Eingabe nacheinander und überprüfen Sie: (1) Das fokussierte Feld scrollt in den sichtbaren Bereich, (2) die Absendeaktion ist sichtbar und antippbar, (3) klebrige Kopfzeilen verdecken das fokussierte Feld nicht. Beachten Sie, dass Elemente mit position: fixed; bottom: 0 hinter der iOS-Tastatur verschwinden (der Layout-Viewport schrumpft nicht), und position: sticky; bottom: 0 versagt ebenfalls beim Anheften während der Tastaturanzeige (WebKit-Fehler #202120). Playwright und Cypress können keine echten Bildschirmtastaturen auslösen – dies erfordert Tests auf echten Geräten oder den Xcode-Simulator mit Safari Web Inspector.

• Großer Text / Display Zoom – WCAG 1.4.4 (AA) erfordert, dass Text auf 200% ohne Inhaltsverlust vergrößert werden kann. WCAG 1.4.10 (AA) erfordert einen Zeilenumbruch bei 400% Zoom (entspricht einem 320px breiten Viewport) ohne horizontales Scrollen. Testen Sie durch: (1) Setzen des Browserzooms auf 200% und Überprüfen, dass keine Abschneidung oder Überlappung auftritt, (2) Setzen des Viewports auf 1280px und Zoomen auf 400%, um die 320px-Umbruchanforderung zu simulieren, (3) Aktivieren von iOS Einstellungen > Bedienungshilfen > Display & Textgröße > Größerer Text auf Maximum. Überprüfen Sie, dass das Viewport-Meta-Tag kein user-scalable=no oder maximum-scale unter 2.0 setzt.

• Reduzierte Bewegung – Animationen respektieren prefers-reduced-motion: reduce. Übergänge kommunizieren weiterhin Zustandsänderungen, verwenden aber Überblendungen oder Deckkraft anstelle von Bewegung. iOS Safari unterdrückt Web-Animationen nicht automatisch, wenn „Bewegung reduzieren" eingeschaltet ist – der Entwickler muss dies handhaben. Testen Sie via: Chrome DevTools Rendering-Tab > „Emulate prefers-reduced-motion", Safari Web Inspector Präferenz-Overrides (verfügbar seit Ende 2022) oder Playwrights page.emulateMedia({ reducedMotion: 'reduce' }).

• Leere/Fehler/Ladezustände – Diese Zustände werden auf dem kompakten Bildschirm korrekt dargestellt. Lade-Skelette entsprechen dem mobilen Layout, nicht dem Desktop-Layout. Fehlermeldungen sind ohne Scrollen lesbar.

• Standalone/PWA-Modus (wenn relevant) – Wenn die App display: standalone unterstützt, überprüfen Sie, ob der Statusleistenbereich, der Home-Indikator und die Gestenregionen behandelt werden. svh und dvh lösen im Standalone-Modus auf denselben Wert auf, da es keine zusammenklappbare Symbolleiste gibt (WebKit-Fehler #261185). WebKit-Fehler #254868 kann falsche Höhenwerte verursachen. WebKit-Fehler #265578 führt dazu, dass die Höhe des visuellen Viewports verzögert aktualisiert wird, wenn die Safari-UI wieder eingeblendet wird.

• Kein horizontales Dokument-Scrollen – Wischen Sie nach links/rechts auf dem Seitenkörper erzeugt keine Bewegung. Jegliches horizontales Scrollen ist auf einen bestimmten Container (Tabelle, Karussell) mit sichtbarem Überlauf-Hinweis und overscroll-behavior: contain beschränkt, um Safari-UI-Verschiebungen zu verhindern (WebKit-Fehler #240861). Für automatisierte Verifikation in Playwright:

  const hasOverflow = await page.evaluate(() =>
    document.documentElement.scrollWidth > document.documentElement.clientWidth
  );
  expect(hasOverflow).toBe(false);
  

Liefergegenstand

Wenn Sie dieses Skill verwenden, liefern Sie:

• einen kurzen Mobil-Anpassungsplan
• die risikoreichsten Probleme zuerst
• konkrete Änderungen pro Bildschirm
• durchgeführte Verifikation
• verbleibende Geräte-/Browser-Unsicherheiten