2. Warum überhaupt Fullscreen, wenn es doch Inline gibt?
In der vorherigen Vorlesung zu inline haben wir bereits festgehalten: Wenn die Aufgabe klein ist und in 5–7 Elemente oder einen Bildschirm passt, ist die Inline‑Karte ideal. Eine Liste mit einigen Geschenken, ein paar Filtern, ein oder zwei Schaltflächen – all das lebt prima direkt im Nachrichtenstrom.
Aber bei jeder App kommt der Moment, in dem „noch eine Karte“ nicht mehr hilft:
- es müssen viele Parameter erfasst werden (Profil des Empfängers, Lieferbeschränkungen, Zahlungsarten);
- es wird ein Assistent mit mehreren Schritten benötigt;
- es gibt große Tabellen, Diagramme, Karten, lange Beschreibungen.
Inline gerät hier ins Zittern: Die Breite ist durch die Chat‑Spalte begrenzt, die Höhe ebenso, es gibt keine Navigation und der Chat hat nur einen Scroll. Genau für solche Szenarien gibt es im Apps SDK den Fullscreen‑Modus – ein „eintauchendes“ Interface, in dem Ihr Widget den Großteil des Bildschirms einnimmt und komplexe Layouts anzeigen kann.
Der zweite Held des Tages ist PiP, ein kleines schwebendes Fenster, das über dem Chat liegt. Typische Rollen: Status eines Hintergrundjobs, Mini‑Player, Timer, Fortschrittsanzeige. PiP ist ideal, wenn etwas Längeres „im Hintergrund“ läuft und der Nutzer mit GPT weiter chatten möchte.
Wichtig: Fullscreen und PiP sind kein Ersatz für Inline, sondern eine Aufsatzschicht. Man beginnt mit Inline, wechselt zu Fullscreen, wenn Inline zu eng wird; und geht in PiP, wenn alles Wichtige bereits gestartet wurde und man nur den Status „im Blick behalten“ will.
3. Technische Grundlage: displayMode und Moduswechsel
Aus Sicht des Apps SDK hat Ihr Widget einen aktuellen Anzeigestatus – displayMode. Zum Zeitpunkt des Schreibens gibt es drei Hauptmodi: "inline", "fullscreen" und "pip" (picture‑in‑picture).
Der Host (ChatGPT) teilt Ihrem Widget den aktuellen Modus über globale Daten in window.openai und spezielle Hooks aus dem SDK mit. In einem typischen React‑Template gibt es etwa so etwas:
// Alias aus dem Apps-SDK-Template
const mode = useDisplayMode(); // 'inline' | 'fullscreen' | 'pip'
if (mode === "fullscreen") {
// wir rendern unseren Assistenten
} else {
// wir rendern das kompakte Inline-UI
}
Das SDK bietet außerdem die Methode window.openai.requestDisplayMode({ mode }) und/oder den Hook useRequestDisplayMode, um den Host um einen Moduswechsel zu bitten. Diese Methode liefert einen Promise mit dem tatsächlich gesetzten Modus zurück, weil die Plattform Ihren Wunsch ablehnen oder anpassen kann (zum Beispiel wird PiP auf Mobilgeräten fast immer in Fullscreen verwandelt).
Schematisch lässt sich der Lebenszyklus der Modi so darstellen:
stateDiagram-v2
[*] --> Inline
Inline --> Fullscreen: requestDisplayMode('fullscreen')
Fullscreen --> Inline: requestDisplayMode('inline') / Schaltfläche "Zurück"
Fullscreen --> PiP: requestDisplayMode('pip')
PiP --> Fullscreen: "Maximieren"
PiP --> Inline: Abschluss der Aufgabe
Reale Bezeichnungen und der genaue Satz der Modi können sich mit den SDK‑Versionen ändern, daher sollten Sie in der Produktion immer die Dokumentation prüfen und sich nicht auf „wie es im Kurs war“ verlassen.
4. Erste Umschaltung: Schaltfläche „In den Vollbildmodus erweitern“ bauen
Fangen wir klein an: Nehmen wir unser bestehendes Inline‑Widget GiftGenius – die Lern‑App aus den vorherigen Modulen, die aktuell 3–5 Geschenk‑Karten anzeigt – und fügen eine Schaltfläche „Detaillierte Auswahl öffnen“ zum Wechsel in den Fullscreen hinzu.
Nehmen wir an, dass es im Template zwei Hooks gibt:
import { useDisplayMode, useRequestDisplayMode } from "@/sdk/display";
export const GiftGeniusWidget: React.FC = () => {
const mode = useDisplayMode();
const requestDisplayMode = useRequestDisplayMode();
if (mode === "fullscreen") {
return <GiftFullscreenWizard />;
}
return (
<InlineGiftPreview
onExpand={async () => {
await requestDisplayMode({ mode: "fullscreen" });
}}
/>
);
};
Hier ist InlineGiftPreview unser aktuelles Inline‑UI, und GiftFullscreenWizard ist die neue Assistent‑Komponente, die wir gleich entwerfen. Im onExpand‑Handler rufen wir nicht nur requestDisplayMode auf, sondern warten auch auf den Promise – so können wir später auf eine Ablehnung reagieren (z. B. eine Meldung zeigen, falls Fullscreen aus irgendeinem Grund nicht verfügbar ist).
InlineGiftPreview ist recht einfach:
type InlineGiftPreviewProps = {
onExpand: () => void;
};
const InlineGiftPreview: React.FC<InlineGiftPreviewProps> = ({ onExpand }) => {
return (
<div>
<h3>Geschenk-Auswahl</h3>
{/* ...Geschenk-Karten... */}
<button onClick={onExpand}>Detaillierte Auswahl öffnen</button>
</div>
);
};
Momentan ähnelt das sehr dem „Modal öffnen“, aber der Unterschied ist, dass dies nicht Ihr React steuert, sondern die Host‑App ChatGPT, die eventuell einen Titel, systemische „Zurück“‑Schaltflächen usw. anzeigen kann.
5. Fullscreen‑Assistent für GiftGenius entwerfen
Entwerfen wir nun den Fullscreen‑Assistenten zur Geschenk‑Auswahl. Aus UX‑Sicht ist es sinnvoll, den Prozess in mehrere logische Schritte zu unterteilen. Zum Beispiel:
- Wer ist der Empfänger und zu welchem Anlass?
- Budget und Geschenktyp (physisch, Erlebnis, digital).
- Prüfen und Auswahl bestätigen.
Im Code kann man das mit einer einfachen Zustandsmaschine nach Schritten abbilden:
type WizardStep = "recipient" | "preferences" | "review";
type WizardState = {
step: WizardStep;
recipient?: { ageRange: string; relation: string };
preferences?: { budget: number; categories: string[] };
};
Erstellen wir die Komponente GiftFullscreenWizard, die diesen Zustand in React hält und den passenden Bildschirm rendert.
const GiftFullscreenWizard: React.FC = () => {
const [state, setState] = useState<WizardState>({ step: "recipient" });
const goNext = (partial: Partial<WizardState>) => {
setState((prev) => ({ ...prev, ...partial }));
};
if (state.step === "recipient") {
return <RecipientStep state={state} onNext={goNext} />;
}
if (state.step === "preferences") {
return <PreferencesStep state={state} onNext={goNext} />;
}
return <ReviewStep state={state} />;
};
Jeder Schritt ist eine kleine Komponente mit einem Formular. Zum Beispiel der erste Schritt:
type StepProps = {
state: WizardState;
onNext: (partial: Partial<WizardState>) => void;
};
const RecipientStep: React.FC<StepProps> = ({ state, onNext }) => {
const [relation, setRelation] = useState(state.recipient?.relation ?? "");
const [ageRange, setAgeRange] = useState(state.recipient?.ageRange ?? "");
return (
<div>
<h2>Für wen wählen wir ein Geschenk?</h2>
<input
placeholder="Wer ist die Person für Sie?"
value={relation}
onChange={(e) => setRelation(e.target.value)}
/>
<input
placeholder="Alter (z. B. 25–34)"
value={ageRange}
onChange={(e) => setAgeRange(e.target.value)}
/>
<button
onClick={() =>
onNext({
recipient: { relation, ageRange },
step: "preferences",
})
}
>
Weiter
</button>
</div>
);
};
Im zweiten Schritt sammeln wir Budget und Kategorien, im dritten rufen wir ein callTool / ein MCP‑Werkzeug auf, das bereits in der Lage ist, anhand dieser Parameter Geschenke zu finden, und zeigen die Ergebnisse.
Wichtig ist, dass wir im Fullscreen‑Bildschirm Platz haben für:
- eine Progressbar oder einen Stepper;
- ausführlichere Felder und Hilfetexte;
- Fehlerzustände („Etwas ist schiefgelaufen, bitte versuchen Sie es erneut“).
Empfehlung aus UX‑Guidelines: Jeder Schritt sollte so einfach wie möglich bleiben, ohne Feld‑Überfrachtung; lieber 3–4 klare Schritte als ein monströses Formular.
6. UX des Fullscreen‑Assistenten: Fortschritt, Fehler, Zurück
Ein Formular bildschirmfüllend darzustellen ist nur die halbe Miete. Nutzer müssen:
- verstehen, an welchem Schritt sie sich befinden;
- die Möglichkeit haben, zurückzugehen;
- sehen, was während längerer Operationen passiert.
Einen einfachen Stepper kann man rein visuell umsetzen:
const Stepper: React.FC<{ step: WizardStep }> = ({ step }) => {
const index = step === "recipient" ? 1 : step === "preferences" ? 2 : 3;
return <p>Schritt {index} von 3</p>;
};
Und Stepper einfach in jeden Bildschirm einfügen. Fortgeschritten wäre eine horizontale „Treppe“ der Schritte, aber im Rahmen des Kurses machen wir keine Layout‑Schule.
Wichtig ist die Fehlerbehandlung. Angenommen, im letzten Schritt rufen wir das Tool search_gifts auf:
const ReviewStep: React.FC<StepProps> = ({ state }) => {
const [loading, setLoading] = useState(false);
const [error, setError] = useState<string | null>(null);
const handleConfirm = async () => {
setLoading(true);
setError(null);
try {
await callTool("search_gifts", {
recipient: state.recipient,
preferences: state.preferences,
});
// Die Ergebnisse erscheinen später im Chat / Widget
} catch (e) {
setError("Geschenke konnten nicht ermittelt werden, bitte versuchen Sie es erneut.");
} finally {
setLoading(false);
}
};
return (
<div>
{/* Zusammenfassung der Parameter anzeigen */}
{error && <p style={{ color: "red" }}>{error}</p>}
<button disabled={loading} onClick={handleConfirm}>
{loading ? "Wir wählen aus…" : "Bestätigen und auswählen"}
</button>
</div>
);
};
Hinsichtlich Barrierefreiheit sollten Sie darauf achten, dass:
- im Fullscreen die großen Schaltflächen „Weiter“, „Zurück“ und „Abbrechen“ gut klickbar sind;
- der Text ausreichenden Kontrast hat;
- man mit Tab alle interaktiven Elemente der Reihe nach erreichen kann.
Wenn möglich, fügen Sie für nicht standardmäßige Controls (z. B. benutzerdefinierte Kategorie‑Schalter) ein aria-label hinzu. Auch wenn dieser Kurs kein WCAG‑Examen ist, hilft grundlegende a11y‑Sorgfalt, später das Store‑Review ohne Schmerzen zu bestehen.
Am Ende löst der Fullscreen‑Assistent komplexe mehrstufige Szenarien: Er bietet Platz für Formulare, Fortschritt und Fehler. Aber das App‑Leben endet hier nicht – viele Aufgaben laufen „im Hintergrund“ weiter. Dafür gibt es den zweiten Modus: PiP, über den wir als Nächstes sprechen.
7. Was ist PiP in der ChatGPT‑Welt und warum es „zickig“ ist
Wir wissen nun, wie man Fullscreen für komplexe Szenarien nutzt. Schauen wir uns das Gegenteil an – wenn alles Wichtige bereits gestartet ist und man nur den Fortschritt „unter Kontrolle“ halten möchte. Hier kommt PiP ins Spiel.
In der Web‑Welt wird „picture‑in‑picture“ meist mit einem Video assoziiert, das in einer Ecke über dem Inhalt hängt. In ChatGPT ist PiP ein kleines schwebendes Widget‑Fenster, das beim Scrollen des Chats sichtbar bleibt und Status, Fortschritt oder ein kompaktes UI anzeigen kann.
Einige wichtige Besonderheiten aus Doku und Erfahrungen von Early‑Adoptern:
- PiP hat sehr wenig Platz. Es ist keine Fläche für Formulare und komplexe Layouts, sondern eher für zwei, drei Kennzahlen und ein bis zwei Schaltflächen.
- Auf dem Desktop „klebt“ PiP oben und bleibt beim Scrollen sichtbar; auf Mobilgeräten verwandelt es sich häufig automatisch in Fullscreen.
- Ein requestDisplayMode mit mode "pip" garantiert kein echtes PiP. Die Plattform kann einen anderen Modus zurückgeben (z. B. Fullscreen) oder sich auf alten SDK‑Versionen merkwürdig verhalten – prüfen Sie daher immer das Promise‑Ergebnis und haben Sie einen Fallback.
Daraus folgt ein einfacher UX‑Schluss: Im PiP nur das Wichtigste. Timer, Lieferindikator, Job‑Status, Schaltfläche „Maximieren“. Keine 12 Checkboxen, keine Tabellen mit 10 Spalten und kein „mach mir noch einen Kaffee“.
8. GiftGenius + PiP: lange Suche und Hintergrund‑Fortschritt
Zurück zu GiftGenius. Szenario: Der Nutzer hat den Fullscreen‑Assistenten durchlaufen, auf „Bestätigen“ geklickt und Ihr Backend startet nun eine recht schwere Auswahl – vielleicht ruft Ihr MCP‑Server mehrere externe APIs auf, berechnet Preise neu, wendet viele Filter an. Das kann, sagen wir, 10–20 Sekunden dauern.
Aus UX‑Sicht möchte man den Nutzer nicht 20 Sekunden im Fullscreen mit einem Spinner festhalten. Besser:
- die Auswahl starten,
- das Interface in PiP verkleinern und den Fortschritt anzeigen,
- den Nutzer weiter chatten lassen (z. B. Rückfragen stellen),
- nach Abschluss – das Ergebnis inline zurückgeben oder einen neuen Fullscreen mit Geschenken öffnen.
Erstellen wir einen einfachen Hook, der dieses Verhalten steuert:
const useLongGiftJob = () => {
const [status, setStatus] = useState<"idle" | "running" | "done">("idle");
const requestDisplayMode = useRequestDisplayMode();
const startJob = async (payload: any) => {
setStatus("running");
const resultMode = await requestDisplayMode({ mode: "pip" });
console.log("Tatsächlicher Modus:", resultMode.mode);
await callTool("run_gift_job", payload);
setStatus("done");
await requestDisplayMode({ mode: "inline" });
};
return { status, startJob };
};
Nun verwenden wir in ReviewStep statt des direkten callTool diesen Hook:
const ReviewStep: React.FC<StepProps> = ({ state }) => {
const { status, startJob } = useLongGiftJob();
return (
<div>
{/* ...Zusammenfassung... */}
<button
disabled={status === "running"}
onClick={() => startJob(state)}
>
{status === "running" ? "Wir wählen Geschenke aus…" : "Auswahl starten"}
</button>
</div>
);
};
Damit der Status des Hintergrundjobs sowohl für den Fullscreen‑Assistenten als auch für das PiP‑Fenster verfügbar ist, lohnt es sich im realen Code, useLongGiftJob in einen Kontext auszulagern und über useLongGiftJobContext zu lesen. Die Details der Kontext‑Implementierung (Provider, createContext) sparen wir uns: Wichtig ist, dass der Job‑State an einer Stelle lebt und die verschiedenen UI‑Schichten ihn nur abonnieren.
Und eine separate Komponente für die PiP‑Anzeige:
const GiftPipView: React.FC<{ status: string }> = ({ status }) => {
return (
<div>
<p>GiftGenius arbeitet…</p>
<p>Status: {status === "running" ? "läuft" : "fertig"}</p>
<button
onClick={() => window.openai.requestDisplayMode({ mode: "fullscreen" })}
>
Maximieren
</button>
</div>
);
};
Im Haupt‑Widget passen wir das Rendering so an, dass PiP ebenfalls berücksichtigt wird:
const GiftGeniusWidget: React.FC = () => {
const mode = useDisplayMode();
const { status } = useLongGiftJobContext(); // über den Kontext, wie oben besprochen
if (mode === "pip") {
return <GiftPipView status={status} />;
}
if (mode === "fullscreen") {
return <GiftFullscreenWizard />;
}
return <InlineGiftPreview onExpand={/* wie zuvor */} />;
};
Ein solcher Ablauf passt hervorragend zu Sprachmodi (darüber sprechen wir in der Voice‑Vorlesung): Per Sprache starten wir die Auswahl, PiP zeigt den Fortschritt, der Chat bleibt darunter und lebt weiter.
9. Video + Chat: wenn Fullscreen und PiP zum Media‑Player werden
Historisch wird PiP am häufigsten mit einem Video assoziiert, das in einer Ecke über dem Inhalt hängt. Daher ist es naheliegend, das Szenario „Video + Chat“ separat zu betrachten. Auch hier gibt es keine Magie: In den meisten Fällen zeigen Sie das Video einfach im Fullscreen oder im PiP‑Fenster an. Die OpenAI‑Dokumentation führt Media‑Szenarien ausdrücklich als typisches Beispiel für die Nutzung von Fullscreen und PiP an.
Was könnte das für GiftGenius bedeuten? Zum Beispiel:
- Sie zeigen ein Promo‑Video zum Geschenk,
- ein kurzes Tutorial „wie man ein Geschenk schön verpackt“,
- ein Video‑Review mehrerer Produkte.
Im Fullscreen kann man ein vollwertiges <video> mit Beschreibung und Empfehlungen rendern; im PiP bleibt nur der Player und vielleicht eine kleine Überschrift.
Eine einfache Wrapper‑Komponente:
const GiftVideoPlayer: React.FC<{ src: string; title: string }> = ({
src,
title,
}) => (
<div>
<h3>{title}</h3>
<video
src={src}
controls
style={{ width: "100%", borderRadius: 8 }}
/>
</div>
);
Im Fullscreen‑Assistenten können wir dem Nutzer vorschlagen: „Video‑Review dieses Geschenks ansehen“ und es anschließend in PiP verkleinern:
const WatchVideoStep: React.FC = () => {
const requestDisplayMode = useRequestDisplayMode();
return (
<div>
<GiftVideoPlayer src="/videos/gift-wrap.mp4" title="Wie man ein Geschenk verpackt" />
<button
onClick={() => requestDisplayMode({ mode: "pip" })}
>
Video in der Ecke lassen und zum Chat zurückkehren
</button>
</div>
);
};
Ein paar praktische Tipps für Media‑Szenarien:
- kein Autoplay mit Ton – das ist ein universelles UX‑Anti‑Pattern;
- achten Sie auf Untertitel und die Möglichkeit, per Tastatur zu pausieren (Leertaste, Pfeile);
- im PiP‑Fenster nicht den gesamten Begleittext anzeigen, beschränken Sie sich auf das Video selbst.
10. Zustand, Remounting des Widgets und mobile Besonderheiten
Die unangenehmste Frage an dieser Stelle lautet meist: „Bleibt der React‑State erhalten, wenn ich zwischen Inline und Fullscreen wechsle?“
Kurze Antwort: Verlassen Sie sich nicht darauf.
Technisch hängt das Verhalten von der SDK‑Version und der Host‑Implementierung ab: In manchen Fällen erfolgt der Wechsel zwischen den Modi ohne Neuanlage des iframes, in anderen wird das Widget beim Wechsel unmountet und neu gemountet. In der Dokumentation wird ausdrücklich betont, dass die Kontexterhaltung beim Moduswechsel von der jeweiligen SDK‑Implementierung und ‑Version abhängt und für Entwickler keine Garantie ist.
Praktisches Vorgehen:
- Speichern Sie jeden kritischen Zustand (Assistent‑Schritt, eingegebene Daten, ID des Hintergrundjobs) entweder:
- im Backend (über Ihren MCP‑Server und Session‑Tokens),
- oder im ChatGPT‑Kontext (z. B. über Tools, die den „aktuellen Workflow‑Zustand“ zurückgeben),
- oder in URL‑Parametern/Local Storage, sofern es eine sichere Grundlage dafür gibt.
- Verwenden Sie React‑State als Cache/UI‑Schicht, seien Sie aber darauf vorbereitet, dass er beim Moduswechsel verloren gehen kann – dann stellen Sie ihn aus der zuverlässigeren Quelle wieder her.
Die zweite Feinheit betrifft das Ergebnis von requestDisplayMode. Wie bereits erwähnt, kann eine Anfrage mit mode "pip" als "fullscreen" zurückkommen, insbesondere auf Mobilgeräten, wo echtes PiP nicht unterstützt wird oder automatisch in den Vollbildmodus wechselt.
Typisches Muster:
const requestDisplayMode = useRequestDisplayMode();
const openPipSafe = async () => {
const result = await requestDisplayMode({ mode: "pip" });
if (result.mode !== "pip") {
// Fallback: z. B. eine Meldung anzeigen oder das UI an Fullscreen anpassen
console.log("PiP ist nicht verfügbar, wir arbeiten im Modus:", result.mode);
}
};
So geraten Sie nicht in die Situation, dass Sie mit einem kleinen Fenster rechnen, aber einen Vollbild‑UI mit „PiP‑spezifischen“ Schaltflächen erhalten – so ein Interface wirkt in diesem Modus merkwürdig.
Denken Sie außerdem an maxHeight und internen Scroll: Selbst im Fullscreen kann der Host die Höhe des Containers begrenzen, und Ihre Aufgabe ist es, den Scroll so zu organisieren, dass nicht drei verschachtelte Scrollleisten entstehen.
11. Typische Fehler bei der Arbeit mit Fullscreen und PiP
Fehler Nr. 1: Fullscreen als Standardmodus.
Manche Entwickler sehen „Fullscreen“ und versuchen sofort, ihre App in ein separates SPA innerhalb des Chats zu verwandeln. Ergebnis: Jede Geschenkerwähnung – und der Nutzer landet sofort im Vollbild‑Assistenten, obwohl er nur ein paar Ideen wollte. Die OpenAI‑Richtlinien empfehlen nachdrücklich, mit Inline zu beginnen und nur bei objektiver Notwendigkeit auf Fullscreen zu erweitern.
Fehler Nr. 2: PiP als kleiner Fullscreen.
PiP hat eine sehr begrenzte Fläche, aber manchmal versucht man, alles hineinzuquetschen: Tabs, Formulare, Filter. Der Nutzer bekommt ein mikroskopisches Interface, das kaum klickbar ist. Der richtige Ansatz: Im PiP nur Status und ein bis zwei Schlüssel‑Buttons (z. B. „Maximieren“ und „Abbrechen“) anzeigen.
Fehler Nr. 3: Unerklärte Übergänge zwischen den Modi.
Wenn ein Widget plötzlich ohne GPT‑Text oder ohne expliziten Nutzerklick in Fullscreen aufklappt, ist das desorientierend. Gleiches gilt für Auto‑Einklappen in PiP oder Rückkehr zu Inline. Jeder Übergang sollte mit einer kurzen Erklärung in einer Modell‑Nachricht begleitet werden: „Ich öffne jetzt den detaillierten Assistenten“ vor Fullscreen, „Ich verkleinere die Auswahl in ein kleines Fenster, während sie berechnet wird“ vor PiP.
Fehler Nr. 4: Ignorieren von Mobilgeräten und Plattform‑Unterschieden.
Der Entwickler testet nur auf dem Desktop, wo sich PiP erwartbar verhält, und auf dem Smartphone wird plötzlich alles Fullscreen, das Layout verschiebt sich und Schaltflächen landen außerhalb der Safe‑Area. Die Dokumentation warnt ausdrücklich, dass PiP auf Mobilgeräten als Fullscreen implementiert sein kann und sich das Verhalten zwischen SDK‑Versionen ändern kann – Testen auf Zielgeräten und sorgfältiger Umgang mit requestDisplayMode sind Pflicht.
Fehler Nr. 5: Vollstes Vertrauen in die State‑Erhaltung beim Moduswechsel.
Nur auf React‑State zu setzen, ohne server‑/persistenten Rückhalt, führt zu lustigen Situationen: Der Nutzer hat zwei Schritte im Assistenten erledigt, auf „In PiP verkleinern“ geklickt, und nach der Rückkehr landet er auf Schritt 1 mit leeren Feldern. Gehen Sie besser davon aus, dass Ihre Komponente beim Moduswechsel unmounted werden kann, und entwerfen Sie das State‑Management mit diesem Risiko im Hinterkopf.
Fehler Nr. 6: Vergessene Barrierefreiheit im Fullscreen‑Assistenten.
Ein hübsches Formular auf großem Bildschirm ist nicht automatisch bequem für Menschen mit eingeschränktem Sehvermögen oder diejenigen, die nur die Tastatur nutzen. Zu kleiner Text, geringer Kontrast, unklare „Weiter“/„Zurück“‑Buttons sind häufige Gründe nicht nur für schlechtes UX, sondern auch für Probleme im Store‑Review. Prüfen Sie zumindest die Basics: Textkontrast, Schriftgröße, Tab‑Navigation und verständliche Textlabels für Schaltflächen.
GO TO FULL VERSION