Inline‑Pattern: Karten, Listen, Karussells und CTA

1. Was ist der inline‑Modus und warum ist er der „Default“

Die offiziellen OpenAI‑Guidelines betonen: inline‑Darstellung ist der Standardmodus für ChatGPT Apps. Der Inline‑Widget wird direkt im Chat‑Verlauf über der Modellantwort gerendert und umfasst einen kleinen UI‑Block (Karte, Liste, Karussell) plus eine Follow‑up‑Nachricht vom GPT darunter.

Die Idee ist einfach: Anstatt den Nutzer in ein separates, großes UI zu schicken, geben wir ihm einen kompakten visuellen „Impuls“ direkt im Gesprächskontext: Das Modell erklärt, was passiert ist und welche Optionen es gibt, und das Widget zeigt sauber Struktur und verfügbare Aktionen.

Inline‑Widget:

• leichtgewichtig im Inhalt und erfordert nicht viele Schritte;
• führt den Nutzer nicht in komplexe Navigation mit Tabs und internen Scrollleisten;
• löst ein bis zwei kleine Aufgaben: Optionen anzeigen, Auswahl ermöglichen, Aktion bestätigen, Status zeigen.

Der fullscreen‑Modus (dazu in der nächsten Vorlesung) ist für größere Assistenten und komplexe Inhalte gedacht. Wichtig ist jetzt: Denkt standardmäßig inline, und schaltet fullscreen bewusst zu, wenn inline klar nicht mehr ausreicht.

Unsere Aufgabe in dieser Vorlesung: die drei wichtigsten inline‑Pattern sicher beherrschen und darauf CTA gestalten:

• Karten
• Listen
• Karussells

sowie sinnvoll CTA‑Buttons (Call to Action) daran anzubringen.

2. Wann inline besser ist als fullscreen

Vereinfacht gesagt: Der inline‑Modus ist der „schnelle Helfer“, während fullscreen eine Art „separate App innerhalb von ChatGPT“ ist.

Inline ist besonders gut, wenn:

• mehrere Optionen gezeigt werden sollen und man eine oder zwei auswählt;
• das Ergebnis in einer kompakten Struktur darstellbar ist: Geschenkkarte, Bestellübersicht, Mini‑Tabelle;
• der Nutzer eine kurze Aktion ausführt: „auswählen“, „Details anzeigen“, „Filter ändern“;
• der Dialog im Vordergrund bleibt: GPT erklärt, scherzt, kommentiert, und das Widget bietet nur ein bequemes Formular oder Visual.

In GiftGenius bedeutet inline:

• die 3–5 besten Geschenke für die ausgewählte Person anzeigen;
• schnell filtern: „zeige nur digitale Geschenke“;
• die Auswahl bestätigen: „hier ist die Bestellübersicht, passt das?“.

Fullscreen braucht ihr später für einen dreistufigen, komplexen Checkout‑Assistenten. Jetzt bleiben wir in der leichten Zone: ein Tool‑Call → ein inline‑Widget.

Zur Veranschaulichung — eine kleine Tabelle:

Mit diesem Verständnis gehen wir in die Praxis: Wie werden diese Pattern im UI und im Code umgesetzt? Wir gehen jedes Pattern im gleichen Schema durch: zuerst — was es aus UX‑Sicht ist, dann — eine einfache React‑Komponente für GiftGenius und schließlich die Einbettung in ein inline‑Widget.

3. Karten: der Grundbaustein des inline‑UI

Was ist eine Karte im Kontext des Apps SDK?

Gemäß den OpenAI‑Guidelines ist die inline‑Karte ein leichtgewichtiger, auf eine Person gerichteter Widget‑Block, der eine kleine Menge strukturierter Daten und 1–2 Aktionen unten zeigt. Sie kann einen Titel, ein Bild, ein paar Metadatenzeilen und einen primären CTA‑Button (plus optional einen sekundären) haben.

In GiftGenius steht jede Karte für ein Geschenk. Darauf lassen sich gut platzieren:

• der Geschenkname;
• der Preis;
• für wen es passt (z. B. „Kollege“, „enge Freundin“);
• eine kurze Begründung, warum es eine gute Option ist;
• ein Button „Dieses Geschenk auswählen“ oder „Details“.

Eine Karte sollte selbstbeschreibend sein: Aus einem Blick sollte klar werden, welche Entität das ist und was die Hauptaktion ist.

Datentyp und einfache Komponente GiftCard

Zuerst definieren wir den Datentyp fürs Geschenk. Nehmen wir an, wir haben bereits ein ToolOutput mit einem Array dieser Objekte; uns interessiert hier nur die UI‑Seite.

// Allgemeine Struktur des Geschenks für das UI
export type GiftSuggestion = {
  id: string;
  title: string;
  priceLabel: string;         // z. B. "≈ 40 $"
  recipientLabel: string;     // "für Kolleg:innen"
  reason?: string;            // Erläuterung vom Modell
  imageUrl?: string;
};

Jetzt bauen wir eine einfache React‑Komponente für die Karte:

type GiftCardProps = {
  gift: GiftSuggestion;
  onSelect: (gift: GiftSuggestion) => void;
};

export function GiftCard({ gift, onSelect }: GiftCardProps) {
  return (
    <div className="flex flex-col gap-2 rounded-lg border p-3">
      <div className="text-sm font-medium">{gift.title}</div>
      <div className="text-xs text-muted-foreground">
        Für: {gift.recipientLabel} · {gift.priceLabel}
      </div>
      {gift.reason && (
        <div className="text-xs text-muted-foreground">{gift.reason}</div>
      )}
      <button
        className="mt-2 self-start rounded bg-primary px-3 py-1 text-xs text-primary-foreground"
        onClick={() => onSelect(gift)}
      >
        Dieses Geschenk auswählen
      </button>
    </div>
  );
}

Ein paar Punkte gleich vorweg:

• wir überladen die Karte nicht mit Text, maximal 2–3 Metadatenzeilen plus kurze Begründung;
• eine primäre CTA — „Dieses Geschenk auswählen“; keine fünf unterschiedlichen Optionen hereinzwingen;
• die Komponente ist sowohl in einer inline‑Liste als auch im Karussell wiederverwendbar.

Wie Karten ins Gesamt‑Widget passen

Nehmen wir an, wir haben ein Array gifts, das nach dem Tool‑Aufruf giftgenius.suggestGifts über unser MCP geliefert wurde. Im inline‑Modus kann das Widget sie einfach in einem 1–3‑Spalten‑Grid rendern.

type GiftGridProps = {
  gifts: GiftSuggestion[];
  onSelect: (gift: GiftSuggestion) => void;
};

export function GiftGrid({ gifts, onSelect }: GiftGridProps) {
  return (
    <div className="grid gap-3 sm:grid-cols-2">
      {gifts.map((gift) => (
        <GiftCard key={gift.id} gift={gift} onSelect={onSelect} />
      ))}
    </div>
  );
}

Hier:

• nutzen wir ein Grid mit 1–2 Spalten, damit das Widget nicht zur „Backsteinwand“ wird;
• können wir die Anzahl der Karten leicht begrenzen, z. B. nur die ersten 3–6 zeigen.

Der onSelect‑Handler kann das Checkout‑Tool aufrufen oder die Auswahl einfach im Widget‑State speichern und das Modell den Dialog fortsetzen lassen. Ein einfaches Beispiel für die Integration mit einem Tool:

async function handleSelect(gift: GiftSuggestion) {
  await window.openai.actions.call("giftgenius.startCheckout", {
    giftId: gift.id,
  });
}

Hier ist window.openai.actions.call die Brücke, um ein registriertes MCP‑Tool direkt aus dem Widget aufzurufen.

Typischerweise zeigt das Modell danach entweder einen Status oder öffnet das nächste Widget (z. B. die Bestellübersicht). Wichtig — versucht nicht, den gesamten Checkout in die Kartenlogik zu packen; die Karte sollte den nächsten, klaren Schritt starten.

4. Listen: wenn Visuals nicht entscheidend sind

Wenn die Karte ein kleiner „Poster“ ist, dann ist die Liste ein aufgeräumtes textuelles Verzeichnis. Dokumentation und UX‑Empfehlungen zeigen, dass Listen gut sind, wenn der Textinhalt wichtiger ist als ein greller visueller Akzent.

Eine Liste eignet sich, wenn:

• 5–10 Optionen gezeigt werden sollen, aber kein Bild erforderlich ist;
• der Nutzer die Titel und Kurzbeschreibungen einfach „überfliegen“ möchte;
• die Aktionen für alle Punkte gleich sind und das UI nicht ablenken soll.

Beispiele in GiftGenius:

• eine Liste „schneller“ Geschenkideen ohne Details;
• eine Liste favorisierter Kategorien: „für Kolleg:innen“, „für Eltern“, „für Kinder“;
• eine Liste gespeicherter Zusammenstellungen („Geschenke für die HR‑Abteilung“, „Kleine Weihnachtsgeschenke bis 20 $“).

Einfache Listenkomponente

Wir bauen eine kompakte Liste mit einem CTA‑Button „Details“ rechts.

type GiftListProps = {
  gifts: GiftSuggestion[];
  onSelect: (gift: GiftSuggestion) => void;
};

export function GiftList({ gifts, onSelect }: GiftListProps) {
  return (
    <ul className="flex flex-col gap-2">
      {gifts.map((gift) => (
        <li
          key={gift.id}
          className="flex items-center justify-between rounded-md border px-3 py-2 text-sm"
        >
          <span className="truncate">{gift.title}</span>
          <button
            className="text-xs text-primary"
            onClick={() => onSelect(gift)}
          >
            Details
          </button>
        </li>
      ))}
    <ul>
  );
}

Hier:

• geben wir dem Titel truncate, damit lange Namen das Layout nicht sprengen;
• nutzen wir wieder eine einzige CTA pro Element;
• lassen wir alle „reicheren“ Informationen (Beschreibung, Bild, Bewertungen) für den nächsten Schritt — z. B. beim Klick eine separate Karte oder fullscreen‑Ansicht öffnen.

Die Liste lässt sich besonders gut mit Follow‑up‑Vorschlägen von GPT kombinieren. Das Widget zeigt eine Liste von „Kandidat:innen“, und darunter schreibt GPT etwa:

„Ich kann auf Geschenke bis 30 $ eingrenzen oder nur digitale anzeigen. Was wählen wir?“ und bietet zwei bis drei Follow‑up‑Buttons an.

In einem separaten Abschnitt besprechen wir noch, wie man inline‑Widgets und Follow‑up‑Nachrichten in verschiedenen Szenarien am besten kombiniert.

5. Karussells: wenn es viele, aber ähnliche Varianten gibt

Ein Karussell ist eine Reihe von Karten, die horizontal angeordnet und per Wisch oder Navigationsbuttons durchgeblättert werden. Die Guidelines empfehlen Karussells, wenn ihr eine kleine Liste ähnlicher Elemente (typischerweise 3–8) zeigt, von denen jedes ein Bild, einen Titel und ein paar Metadaten enthält.

Die Hauptidee: Der Nutzer kann die Optionen schnell scannen, ohne unter einer endlosen Vertikal‑Liste zu versinken.

In GiftGenius ist ein Karussell sinnvoll, wenn:

• es 10–15 passende Geschenke gibt, der inline‑Widget aber nur die „heiße Acht“ zeigen soll;
• jedes Geschenk visuell ansprechend ist (Bild, Gestaltung);
• wichtig ist, dass der Nutzer blättern kann, ohne weit nach unten im Chat zu scrollen.

UX‑Regeln für Karussells

Auf Basis von Guidelines und Research:

• Anzahl der Karten im Karussell — zwischen 3 und 8; wenn es mehr sind, lieber einen separaten Befehl „Mehr anzeigen“ anbieten;
• jede Karte:
  • sollte ein Bild oder ein anderes visuelles Element haben;
  • sollte nicht mehr als zwei Zeilen Metadaten enthalten;
  • hat eine klare CTA, z. B. „Auswählen“ oder „Details“;
• keine komplexen verschachtelten Navigationsmuster (Tabs, Unterpfade) in der Karte;
• vermeidet interne (vertikale) Scrollleisten: die Kartenhöhe darf sich bis zu einem sinnvollen Limit anpassen, aber ohne eigene Scrollbar.

Ein einfaches Karussell nach dem Prinzip „eine Karte auf einmal“

Um keinen komplexen horizontalen Scroll zu bauen, kann man die einfachste Variante wählen: jeweils eine Karte anzeigen und Buttons „zurück/weiter“ anbieten.

import { useState } from "react";

type GiftCarouselProps = {
  gifts: GiftSuggestion[];
  onSelect: (gift: GiftSuggestion) => void;
};

export function GiftCarousel({ gifts, onSelect }: GiftCarouselProps) {
  const [index, setIndex] = useState(0);
  const gift = gifts[index];

  return (
    <div className="flex flex-col gap-2">
      <GiftCard gift={gift} onSelect={onSelect} />
      <div className="flex items-center justify-between text-xs">
        <button
          disabled={index === 0}
          onClick={() => setIndex((i) => i - 1)}
        >
          ← Zurück
        </button>
        <span>
          {index + 1} / {gifts.length}
        </span>
        <button
          disabled={index === gifts.length - 1}
          onClick={() => setIndex((i) => i + 1)}
        >
          Weiter →
        </button>
      </div>
    </div>
  );
}

Das vermittelt bereits „Karussell“-Feeling, und zugleich:

• bleibt der Code kompakt;
• muss man nicht mit Containerbreiten und horizontalen Scrolls im Widget kämpfen;
• lassen sich gifts vor der Übergabe an die Komponente leicht auf 8 Elemente begrenzen.

Wenn ihr ein „echteres“ Karussell wollt, könnt ihr overflow-x-auto und feste Kartenbreiten nutzen. Das ist aber ein Fall, bei dem es einfacher ist, einen fertigen Komponent aus einer UI‑Bibliothek (shadcn/ui, Radix‑kompatible Lösungen etc.) zu nehmen, statt das Rad neu zu erfinden.

6. CTA‑Buttons: wenig, klar, zielgerichtet

CTA (Call to Action) ist das Herz jedes inline‑Patterns. Erst Buttons machen euer Widget zum Werkzeug.

Grundprinzipien

Die OpenAI‑Dokumentation gibt recht strikte Empfehlungen:

• auf der Karte maximal zwei primäre Buttons (einer Haupt‑, einer sekundär);
• im Karussell möglichst eine CTA pro Element;
• der CTA‑Text sollte ein konkretes Verb sein: „Details anzeigen“, „Zur Liste hinzufügen“, „Zur Kasse gehen“ — nicht abstrakt „OK“ oder „Aktion“.

Je weniger Buttons, desto einfacher für Modell und Nutzer. Vergesst nicht: Über und unter dem Widget steht noch Text der Antwort, plus Follow‑up‑Vorschläge von GPT.

CTA an die Applogik binden

In unserem GiftGenius werden die meisten CTA entweder:

• Filter/Kriterien anpassen (neuer Tool‑Call giftgenius.refineSearch),
• den Checkout starten (giftgenius.startCheckout),
• eine externe Seite öffnen (über openExternal, aus den früheren Vorlesungen bekannt).

Beispiel für einen einfachen Handler zur CTA „Filter anpassen“:

async function handleRefineFilters(gift: GiftSuggestion) {
  await window.openai.actions.call("giftgenius.refineSearch", {
    baseGiftId: gift.id,
  });
}

Aus UX‑Sicht ist es sehr wichtig, in den System‑Instruktionen festzuhalten, wann und welche CTA‑Buttons das Modell vorschlagen soll. Zum Beispiel:

• Wenn der Nutzer „zeig mir noch mehr Optionen“ wünscht, zeigt man besser ein neues Karussell mit Button „Auswählen“;
• ist man beim Kauf angelangt, sollte die CTA „Zur Kasse gehen“ zu einem Tool‑Aufruf führen, der den ACP‑Checkout startet (dazu kommen wir im Modul zu Commerce und Zahlungen).

Eine weitere gute Praxis: ChatGPT‑Funktionen nicht in CTA duplizieren. Ein Button „ChatGPT fragen“ ist überflüssig — der Nutzer hat bereits ein Eingabefeld und Voice. Die Guidelines empfehlen ausdrücklich, „doppelte“ Eingaben innerhalb der Karte zu vermeiden.

7. Inline + Follow‑up: ein Duo‑Spiel

Ein Inline‑Widget existiert nie im Vakuum. Die Struktur der Antwort ist meist so:

1. das Modell entscheidet, eure App zu verwenden und ein Tool aufzurufen;
2. euer MCP liefert Daten zurück;
3. ChatGPT rendert das inline‑Widget mit diesen Daten;
4. darunter ergänzt das Modell einen kurzen Follow‑up‑Text und konkrete Vorschläge zur Fortsetzung.

Für GiftGenius könnte das so aussehen:

• inline‑Widget: drei Geschenkkarten mit CTA „Auswählen“;
• der Text darunter:
  „Hier sind drei Ideen für eine:n Kollegen/Kollegin: eine Schreibtischlampe, ein Kurs für öffentliches Sprechen und eine Café‑Gutscheinkarte. Ich kann: — nur Optionen bis 30 $ zeigen; — noch ein paar Ideen im ähnlichen Stil finden; — direkt beim Kauf eines davon helfen.“

Im Follow‑up kann sich das Modell auf die CTA eures Widgets beziehen („Klicken Sie auf ‚Auswählen‘ unter der bevorzugten Option“) oder Textkommandos anbieten, die erneut zu einem Tool‑Call und einer Neurenderung des inline‑UI führen.

Wichtig: Das Widget muss nicht alles können. Manchmal ist es besser, Teile des Szenarios dem Textdialog zu überlassen und das Widget als „visuellen Block“ im Gespräch einzusetzen.

8. Wie das in den Gesamt‑Flow von GiftGenius eingebettet ist

Zur weiteren Klärung fassen wir alles in einem einfachen Sequenzdiagramm zusammen:

sequenceDiagram
  participant U as Benutzer
  participant C as ChatGPT
  participant A as GiftGenius-Widget
  participant B as MCP/Backend

  U->>C: "Finde 3 Geschenke bis 50 $ für eine:n Kolleg:in"
  C->>B: call_tool(giftgenius.suggestGifts)
  B-->>C: 3 Top-Optionen
  C->>A: Inline-Widget rendern (Karten/Karussell)
  A-->>U: Karten mit CTA "Auswählen"
  U->>A: Klick auf CTA
  A->>B: call_tool(giftgenius.startCheckout)
  B-->>A: Status / Zahlungslink
  A-->>U: Auswahl-Übersicht / Status
  C-->>U: Follow-up: "Ich kann noch mehr Ideen finden oder bei der Grußkarte helfen"

Aus architektonischer Sicht:

• das MCP bleibt das „Gehirn“ (Auswahl, Business‑Logik, ACP),
• das Widget ist das „Gesicht“ (Karten/Listen/Karussells),
• ChatGPT ist der „Dialogführer“, der erklärt, was geschehen ist, und die nächsten Schritte anbietet.

Damit dieser Flow angenehm ist:

• überladet das Widget nicht mit Aktionen;
• haltet die Kartendaten kompakt;
• überlegt, welche Follow‑up‑Optionen nach jeder inline‑Darstellung nützlich sind.

9. Ein Wort zur visuellen Seite der inline‑Pattern

Wir sprechen in einer späteren Vorlesung des Moduls detailliert über visuelles Design, aber ein paar Punkte sind für inline‑Pattern schon jetzt kritisch.

Erstens: Stellt sicher, dass eure Karten und Listen nicht wie eine fremde Website innerhalb von ChatGPT wirken. Farben und Abstände sollten sauber sein, ohne grelle Verläufe und Comic‑Sans‑Fonts. Das Inline‑Widget ist Teil des allgemeinen ChatGPT‑UIs, kein Banner aus 2007.

Zweitens: Vermeidet interne Scrollleisten. Wenn eure Karte so lang ist, dass sie eine eigene Scrollleiste bekommt, läuft etwas falsch: Entweder versucht ihr, zu viel Content hineinzupressen, oder das Pattern ist falsch gewählt (vielleicht ist fullscreen nötig).

Drittens: Achtet auf die Dichte:

• zwischen Karten sollte ein sichtbarer Abstand sein;
• CTA muss gut klickbar sein (ausreichender Padding);
• Text muss auch auf dem Handy gut lesbar sein — keine Mikroschrift.

Das klingt vielleicht wie „Design‑Pingeligkeit“, aber die Praxis zeigt: Wenn ein inline‑Widget „nativ“ wirkt, nutzt das Modell es lieber, und Nutzer sind weniger verwirrt.

10. Praxis: GiftGenius anhand der Vorlesung weiterentwickeln

Wenn ihr das Gelernte festigen wollt, hier eine einfache Praxis‑Checkliste:

Nehmt zuerst das aktuelle Ergebnis des Tools giftgenius.suggestGifts (Geschenk‑Array) und:

1. Implementiert drei verschiedene UI‑Varianten in einer Komponente:
   • GiftGrid mit Karten;
   • GiftList mit Textliste;
   • GiftCarousel mit „zurück/weiter“-Navigation.
2. Fügt jeweils ein bis zwei CTA‑Buttons hinzu:
   • für Karten — „Auswählen“;
   • für die Liste — „Details“;
   • für das Karussell — ebenfalls „Auswählen“, plus eine separate Schaltfläche unter dem Widget „Weitere Optionen anzeigen“.
3. Wählt je nach Zustand (z. B. wie viele Geschenke das Tool insgesamt geliefert hat), welches Pattern verwendet wird:
   • wenn es wenige Optionen gibt (≤ 3) — Kartengrid;
   • wenn es viele Textideen sind — Liste;
   • wenn es viele visuelle Geschenke sind — Karussell.

So übt ihr nicht nur UI, sondern beginnt auch, über die dynamische Musterwahl je nach Kontext nachzudenken — etwas, das sowohl Nutzer als auch Store‑Reviewer schätzen werden.

Kurz gesagt: inline‑Pattern sind eine schnelle, leichte UI‑Schicht, die direkt im Chat‑Verlauf lebt und keine separate App ersetzen will. Karten, Listen und Karussells decken 80 % typischer Aufgaben ab: Optionen zeigen, Auswahl ermöglichen und den Dialog sauber fortsetzen.

In der nächsten Vorlesung dieses Moduls sehen wir, was zu tun ist, wenn inline „nicht mehr zieht“: Wir besprechen fullscreen‑Assistenten, den PiP‑Modus und Szenarien, in denen eure App wirklich einen eigenen großen Bildschirm innerhalb von ChatGPT braucht.

11. Typische Fehler beim Arbeiten mit inline‑Pattern

Fehler Nr. 1: Den inline‑Widget zur Mini‑Website machen.
Manchmal versuchen Entwickler, in eine einzige Karte Tabs, Akkordeons, Formulare, eine Tabelle und jede Menge weiterer Elemente zu quetschen. Das Ergebnis ist ein schweres UI, das den Chat‑Rhythmus bricht und auf mobilen Geräten unpraktisch ist. Die Guidelines sagen klar: keine tiefen Navigationen und komplexen Views in inline‑Karten; komplexe Szenarien gehören in fullscreen.

Fehler Nr. 2: Zu viele CTA‑Buttons.
„Machen wir auf der Karte doch ‚Details‘, ‚Kaufen‘, ‚Zu Favoriten‘, ‚Teilen‘, ‚Melden‘ und ‚Grußkarte generieren‘.“ Am Ende sind Nutzer und Modell gleichermaßen überfordert, und die Chance, dass der richtige Button geklickt wird, sinkt. Denkt an die Regel: eine Haupt‑CTA und maximal eine sekundäre. Andere Szenarien besser in die Follow‑up‑Nachricht von GPT oder in spätere Schritte auslagern.

Fehler Nr. 3: Liste, Karten und Karussell ohne Grund in einer Antwort mischen.
Wenn ein und derselbe Inhalt mal als Liste, mal als Karten und mal als Karussell gezeigt wird — „einfach, weil wir es können“ —, geht das Gefühl von Konsistenz verloren. Besser ein Pattern für einen konkreten Ergebnistyp wählen (z. B. Ideen ohne Bilder — Liste; Geschenke mit Bildern — Karussell) und dabei bleiben.

Fehler Nr. 4: Karten mit Text überladen.
Eine Karte mit drei Absätzen Beschreibung, drei Preisen und zwei Blöcken „warum das großartig ist“ wird zur Textwand. Nutzer scannen sie nicht mehr, sondern scrollen vorbei. Lasst in der Karte nur das Wichtigste: Titel, einen Schlüsselparameter, eine kurze Begründung und die CTA. Alles Weitere kann im Text von GPT daneben erklärt werden.

Fehler Nr. 5: Sich nur auf UI verlassen und den Follow‑up‑Dialog ignorieren.
Manchmal sieht man den Ansatz „alles per Buttons, reden muss der Nutzer nicht“. Das widerspricht der Idee von ChatGPT. Das Inline‑Widget sollte den Dialog ergänzen, nicht ersetzen. Denkt daran, welche Follow‑up‑Optionen das Modell unter dem Widget anbieten kann: Filter ändern, mehr Optionen anfordern, zum nächsten Schritt gehen.

Fehler Nr. 6: Begrenzungen bei der Elementanzahl ignorieren.
Ein Karussell mit 25 Karten oder eine Liste mit 50 Einträgen in einem einzigen inline‑Widget führt zuverlässig dazu, dass Nutzer alles überscrollen. Die Dokumentation empfiehlt 3–8 Elemente im Karussell und 5–10 Positionen in der Liste. Wenn es mehr Daten sind, ist eine CTA wie „Mehr anzeigen“ oder „Alles als Text anzeigen“ sinnvoll.

Fehler Nr. 7: inline einsetzen, wo schon fullscreen nötig wäre.
Es ist verlockend, „alles inline zu machen“, selbst wenn es bereits 4 Schritte, Formulare mit einem Dutzend Feldern und große Tabellen gibt. Am Ende bekommt ihr entweder ein Monster oder beginnt, verschachtelte Scrolls und Pseudo‑Stepper in Karten zu bauen. Sobald ihr merkt, dass Schritte und Felder zahlreich werden — ist das ein Signal, an einen fullscreen‑Assistenten zu denken und inline für schnelle Previews und Aktions‑Zusammenfassungen zu lassen.