Benutzerdefinierte Auflistungen: Elementschema, Grenzen und Beispiele

Eine benutzerdefinierte Auflistung ist eine wiederholbare Sammlung von Elementen, die ein kleines Feldschema gemeinsam haben. Jedes Element kann einen Titel, eine prägnante Zusammenfassung, ein oder zwei Metadatenwerte und einen Ziellink enthalten. Diese Struktur gibt den Lesern mehr Kontext als eine Aufzählungsliste , ohne jedes Element wie eine eigenständige Produktkarte wirken zu lassen.

Beispiel – unterstützte Exportformate

• CSV — Tabellarische Zeilen für die Tabellenkalkulationsanalyse. Am besten für flache Datensätze. Verfügbarkeit: Alle Tarife. Aktion: CSV-Exporteinrichtung anzeigen.
• JSON — Verschachtelte Datensätze für Anwendungen und Datenpipelines. Am besten zur Bewahrung von Feldbeziehungen. Verfügbarkeit: Pro und Enterprise. Aktion: JSON-Referenz lesen.
• Google Sheets — Ein synchronisiertes Arbeitsblatt für Teams, die Daten ohne Code überprüfen. Verfügbarkeit: Pro und Enterprise. Aktion: Google Sheets verbinden.

Das gerenderte Element sollte keine dekorative Version dieser Aufzählungspunkte sein. Es sollte eine Sammlung mit drei Elementen darstellen, wobei jedes Element dieselben Felder title, summary, bestFor, availability und url verwendet. Das Feldmodell – nicht die Umrandung, das Symbol oder die Spaltenanzahl – macht die Auflistung zu einer benutzerdefinierten.

Warum dieses Element wichtig ist

Gewöhnlicher Fließtext verbirgt Wiederholungen. Wenn sechs Integrationen in sechs Absätzen beschrieben werden, muss ein Leser selbst entdecken, dass jeder Absatz einen Systemnamen, eine unterstützte Aktion, eine Kontoanforderung und einen Einrichtungslink enthält. Eine benutzerdefinierte Auflistung benennt diese wiederkehrenden Teile durch ein einheitliches Elementschema: eine definierte Menge von Feldern, die von jedem Element verwendet werden. Leser erkennen das Muster nach dem ersten Eintrag und können spätere Einträge vorhersagbar überfliegen.

Diese Konsistenz verbessert auch die Wiederverwendbarkeit. Ein Content-Management-System kann Pflichtfelder validieren, eine Vorlage kann jedes Element ohne seiten spezifisches Markup rendern, und eine nachgelagerte Anwendung kann dieselbe Quelle in eine kompakte mobile Liste oder ein durchsuchbares Verzeichnis umwandeln. Suchmaschinen und KI-Systeme erhalten klar abgegrenzte Elemente, anstatt selbst erkennen zu müssen, wo eine Entität endet und eine andere beginnt.

Das Element ist wichtig, weil es eine häufige Lücke zwischen zwei gültigen Strukturen gibt. Aufzählungen funktionieren, wenn jedes Element eine kompakte Aussage ist. Karten funktionieren, wenn jedes Element eigenständige Bilder, mehrere kommerzielle Attribute, eine prominente Handlungsoption oder genügend visuelles Gewicht benötigt, um allein zu stehen. Viele Sammlungen brauchen keines der Extreme. Eine Integrationsliste kann einen Namen, eine zweisätzige Leistungszusammenfassung, einen Status und einen Link erfordern. Dies in Aufzählungspunkte zu pressen, entfernt die Felder; es zu Karten aufzublähen, verschwendet Platz und lässt eine Referenzsammlung werblich wirken.

Struktur ist kein Vorwand, um jede Sammlung maßgeschneidert zu gestalten. Ein einmaliges Design führt zu inkonsistenten Feldern, Reihenfolgen, Barrierefreiheit und responsivem Verhalten. Die Element-Schreibregeln gelten daher zuerst: Identifizieren Sie das wiederkehrende Informationsbedürfnis, legen Sie das kleinste Schema fest, das es erfüllt, und halten Sie den Inhalt über verschiedene Renderer hinweg portierbar.

Wann es verwendet werden sollte

Verwenden Sie eine benutzerdefinierte Auflistung, wenn alle Elemente dieselbe Leserfrage beantworten, jedes zwei bis fünf sichtbare Felder benötigt und die primäre Aufgabe darin besteht, zu inspizieren oder zu navigieren, anstatt jeden Wert nebeneinander zu vergleichen. Geeignete Sammlungen umfassen Integrationen, Dienstleistungsbereiche, unterstützte Formate, Ressourcen-Downloads, Partnertypen, Teamverantwortlichkeiten, Verzeichnisvorschauen und gruppierte Funktionen.

Führen Sie vier Tests durch, bevor Sie sich dafür entscheiden:

1. Wiederholbarkeit: Kann jedes Element dieselben Pflichtfelder verwenden, ohne Ausnahmen zu erfinden?
2. Eigenständigkeit: Kann ein Leser ein Element verstehen, ohne das vorherige gelesen zu haben?
3. Überfliegbarkeit: Ist das Muster aus Titel und Zusammenfassung nützlicher als ein Raster vergleichbarer Werte?
4. Handlungsoption: Benötigt jedes Element nicht mehr als ein primäres Ziel?

Wenn die Antworten ja lauten, ist eine benutzerdefinierte Auflistung wahrscheinlich angemessen. Verwenden Sie ein anderes Element, wenn die Sammlung einen dieser Tests nicht besteht:

• Verwenden Sie eine Aufzählungsliste, wenn die Elemente nur einen parallelen Satz und keine separaten Metadaten benötigen.
• Verwenden Sie eine Vergleichstabelle , wenn Leser dieselben Kriterien vertikal oder horizontal über Alternativen hinweg überfliegen müssen.
• Verwenden Sie eine Produktkarte, wenn Bild, Preis, Angebot, Bewertung, Verfügbarkeit und Kaufaktion jedes Element zu einer eigenständigen kommerziellen Einheit machen.
• Verwenden Sie eine Schrittliste, wenn die Position eine Abfolge und keine redaktionelle Reihenfolge ausdrückt.
• Verwenden Sie ein Glossar- oder Definitionsmuster, wenn jeder Eintrag im Wesentlichen ein Begriff-Definition-Paar ist.
• Verwenden Sie Überschriften und Fließtext, wenn Elemente unterschiedliche Felder oder mehr als etwa 100 Wörter Erklärung pro Stück benötigen.

Wählen Sie eine benutzerdefinierte Auflistung nicht nur deshalb, weil das Design wiederholte Boxen vorsieht. Zeigen Sie zuerst, dass ein stabiles Inhaltsmodell existiert. Wenn Element eins einen Preis hat, Element zwei eine Autorenbiografie und Element drei eine Downloadgröße, handelt es sich nicht um eine Sammlung – selbst wenn CSS sie ausrichten kann.

Wo es platziert werden sollte

Platzieren Sie die Auflistung, nachdem die Seite die Sammlung und ihre Aufnahmeregel definiert hat. „Unterstützte Integrationen“ ist ein Etikett; „Diese Integrationen können geprüfte Seiten an einen eigenen Berichtsarbeitsbereich senden“ sagt den Lesern, was die Zugehörigkeit bedeutet. Wenn eine Auswahl oder Prüfung die Menge erzeugt hat, erklären Sie diese Methode vor dem ersten Element, damit die Auflistung keine unbegründete Vollständigkeit oder Rangfolge suggeriert.

Setzen Sie die Sammlung in die Nähe der Entscheidungs- oder Navigationsaufgabe, die sie bedient. Eine Integrationsseite sollte die Verbindung und ihr Ergebnis vorstellen, bevor sie unterstützte Workflows auflistet. Ein Verzeichnis sollte Umfang und Filter erklären, bevor es Einträge zeigt. Ein Listenführer sollte seine Bewertungsmethode darlegen, bevor er ausgewählte Elemente präsentiert.

Unterbrechen Sie eine Auflistung nicht mit Fließtext, Werbung, Handlungsaufforderungen oder nicht zugehörigen Screenshots. Die Grenzen der Elemente müssen aufeinanderfolgend bleiben. Platzieren Sie Einschränkungen innerhalb der definierten Metadaten des betroffenen Elements oder erklären Sie eine sammlungsweite Bedingung vor oder nach der gesamten Liste. Wenn mehr als zwölf Elemente erforderlich sind, gruppieren Sie sie unter sinnvollen Zwischenüberschriften, fügen Sie eine Filterung hinzu oder leiten Sie die Leser zu einem Verzeichnisindex weiter. Erzeugen Sie keinen endlosen visuellen Stapel.

Anatomie

Eine vollständige benutzerdefinierte Auflistung besteht aus diesen Bereichen:

1. Sammlungstitel: Benennt die Menge in der Sprache des Lesers, nicht im internen Namen der Komponente.
2. Umfangsangabe: Definiert, was für die Aufnahme qualifiziert und ob die Sammlung vollständig, ausgewählt oder beispielhaft ist.
3. Listencontainer: Stellt eine semantische Sammlung dar und trägt die Elementanzahl.
4. Elementtitel: Identifiziert eindeutig die Entität, Ressource, Fähigkeit oder Option.
5. Elementzusammenfassung: Erklärt den relevanten Unterschied oder die Verwendung des Elements in ein oder zwei Sätzen.
6. Metadatengruppe: Zeigt null bis drei beschriftete Fakten aus dem registrierten Schema an.
7. Primäre Aktion: Verlinkt zu einem klaren Ziel mit beschreibendem Ankertext.
8. Elementgrenze: Verwendet Abstände, eine Linie oder eine dezente Oberflächengestaltung, ohne das Element von seiner Sammlung zu trennen.

Die Umfangsangabe verhindert einen häufigen Genauigkeitsfehler. „Verfügbare Integrationen“ impliziert Vollständigkeit; „Häufige Berichtsintegrationen“ erklärt eine Auswahl. Der Autor muss die Formulierung wählen, die die Datenquelle unterstützen kann.

Designbeispiele

Der Renderer kann die Dichte variieren, muss aber die Feldreihenfolge, die semantische Listenstruktur und eine vorhersagbare Lesereihenfolge bewahren.

Gestapelte redaktionelle Auflistung

Verwenden Sie das standardmäßige gestapelte Design, wenn Zusammenfassungen den größten Wert liefern. Halten Sie den Titel zuerst, die Zusammenfassung als zweites, die Metadaten als drittes und die Aktion als letztes. Ein dezenter Trenner ist ausreichend; jedes Element benötigt keine erhabene Karte.

Kompakte Verzeichnisvorschau

Verwenden Sie eine kompakte Variante, wenn Titel und ein Metadatenwert den Lesern die Wahl eines Ziels ermöglichen. Die Zusammenfassung kann kürzer sein, aber die Beschriftungen müssen sichtbar bleiben. Ersetzen Sie niemals einen aussagekräftigen Status durch einen unerklärten farbigen Punkt.

Gruppierte Auflistung

Verwenden Sie Gruppen, wenn eine stabile Klassifikation eine Sammlung von acht bis vierundzwanzig Elementen in Abschnitte unterteilt. Gruppenüberschriften müssen eine echte Taxonomie beschreiben, wie Exporttyp oder Serviceregion. Gruppieren Sie nicht nur, um gleichmäßige Spalten zu erreichen.

Schmaler Viewport

Bewahren Sie bei schmalen Breiten die Quellreihenfolge und platzieren Sie die Metadaten unterhalb der Zusammenfassung. Verstecken Sie keine Felder, die relevant bleiben, verkleinern Sie keinen Text, um Spalten zu erhalten, und verschieben Sie keine Aktionen von ihrem Element weg.

Parameter

Das folgende Schema ist bewusst eingeschränkt. Ein Feld wird nur dann Teil der Komponente, wenn es für die gesamte Sammlung nützlich ist, nicht nur, weil ein Element zufällig Daten dafür hat.

Drei Elemente sind das Minimum, weil ein Paar meist als Fließtext, zweispaltiger Vergleich oder zwei umfangreiche Karten klarer ist. Zwölf ist das normale Maximum, weil das Überfliegen eines langen ungefilterten Stapels ineffizient wird. Die Obergrenze von vierundzwanzig bei Gruppierung ist eine Leitplanke, kein Ziel; größere oder sich häufig ändernde Mengen benötigen ein Verzeichnis, eine Suche, Seitenaufteilung oder eine datengetriebene Anwendung.

Wählen Sie ordered=true nur, wenn die sichtbare Reihenfolge eine deklarierte Rangfolge ausdrückt. Redaktionelle Zweckmäßigkeit, alphabetische Sortierung oder Datenquellen-Reihenfolge erzeugen keinen Rang. Wenn eine Rangfolge real ist, geben Sie die Methodik an und behalten Sie die Position sowohl in der sichtbaren Ausgabe als auch in allen strukturierten Daten bei.

Syntax und Codebeispiele

Die portable Anweisung definiert den Autorenvertrag. Plattform-Adapter können die Daten anders speichern, müssen aber dieselben Feldnamen, die Elementreihenfolge, die Optionalität und die sichtbare Ausgabe bewahren.

Portable Markdown-Anweisung

::custom-listing{title="Exportformate" variant=stacked}
Dies sind die verfügbaren Formate zum Senden abgeschlossener Prüfdatensätze an einen anderen Arbeitsbereich.

::item{id=csv title="CSV" url="/docs/exports/csv/"}
Tabellarische Zeilen für Tabellenkalkulationsanalyse und Flat-File-Import.

- Am besten für: Tabellenkalkulationsanalyse
- Verfügbarkeit: Alle Tarife
- Aktion: CSV-Exporteinrichtung anzeigen
:::

::item{id=json title="JSON" url="/docs/exports/json/"}
Verschachtelte Datensätze, die Beziehungen für Anwendungen und Datenpipelines bewahren.

- Am besten für: Automatisierte Workflows
- Verfügbarkeit: Pro und Enterprise
- Aktion: JSON-Referenz lesen
:::

::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
Ein synchronisiertes Arbeitsblatt für Teams, die Daten ohne Code überprüfen.

- Am besten für: Gemeinsame Überprüfung
- Verfügbarkeit: Pro und Enterprise
- Aktion: Google Sheets verbinden
:::
:::

Die Beispiel-URLs beschreiben nur die portable Syntax; eine Implementierung muss sie durch verifizierte Ziele ersetzen. Veröffentlichen Sie keinen Beispielpfad als Live-Link, nur weil er in einem Codeblock erscheint.

Hugo-Adapter

{{< custom-listing title="Exportformate" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="CSV-Exporteinrichtung anzeigen" >}}
  Tabellarische Zeilen für Tabellenkalkulationsanalyse und Flat-File-Import.

  **Am besten für:** Tabellenkalkulationsanalyse  
  **Verfügbarkeit:** Alle Tarife
  {{< /custom-listing-item >}}
{{< /custom-listing >}}

Diese Notation spezifiziert einen zukünftigen oder projektweiten Adapter; sie berechtigt nicht zur Erstellung eines seitenlokalen Shortcodes. Alle Parameter sind benannt. Bis ein Adapter existiert, rendern Sie die Sammlung als semantisches HTML mit <ul> und <li> oder als natives Markdown, anstatt die Feldbeziehungen stillschweigend zu verwerfen.

WordPress-Block

<!-- wp:amicited/custom-listing {"title":"Exportformate","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Tabellarische Zeilen für Tabellenkalkulationsanalyse und Flat-File-Import.</p>
    <dl><dt>Am besten für</dt><dd>Tabellenkalkulationsanalyse</dd><dt>Verfügbarkeit</dt><dd>Alle Tarife</dd></dl>
    <a href="/docs/exports/csv/">CSV-Exporteinrichtung anzeigen</a>
  </li>
</ul>
<!-- /wp:amicited/custom-listing -->

Native Blöcke sind ein akzeptabler Fallback, wenn sie eine Liste, einen Listeneintrag pro Element, echte Überschriften, eine Definitionsliste für beschriftete Metadaten und beschreibende Links erzeugen. Ein generischer Spaltenblock ist kein zuverlässiger Ersatz, weil Quellreihenfolge und Elementgruppierung auf Mobilgeräten oft zerbrechen.

Beispiele

Gut: Eine konsistente Ressourcenauflistung

Migrationsressourcen

Diese Ressourcen unterstützen Teams bei der Vorbereitung, Durchführung und Validierung einer Site-Migration.

1. Redirect-Mapping-Tabelle — Enthält jede alte URL, ihr genehmigtes Ziel, den Verantwortlichen und den Validierungsstatus. Format: Tabelle. Phase: Planung. Aktion: Redirect-Tabelle herunterladen.
2. Launch-Validierungsskript — Überprüft Antwortcodes, Weiterleitungsketten, kanonische Ziele und Indexierbarkeit für die migrierte URL-Menge. Format: Skript. Phase: Launch. Aktion: Validierungseinrichtung überprüfen.
3. Post-Launch-Überwachungsansicht — Verfolgt Crawl-Fehler und unerwartete Traffic-Änderungen nach dem Deployment. Format: Dashboard. Phase: Überwachung. Aktion: Überwachungsansicht konfigurieren.

Dies funktioniert, weil jedes Element dieselben fünf Felder verwendet: Titel, Zusammenfassung, Format, Phase und Aktion. Die Umfangsangabe erklärt, warum die Ressourcen zusammengehören. Die Nummerierung spiegelt die deklarierte Migrationsphase wider, nicht die Behauptung, dass die erste Ressource die „beste“ sei. Jede Aktion identifiziert ihr Ziel, anstatt „Mehr erfahren“ zu wiederholen.

Schlecht: Boxen ohne gemeinsames Modell

Nützliche Dinge

• SEO-Checkliste — Unser Lieblingsleitfaden. Kürzlich aktualisiert. Mehr erfahren.
• Premium-Audit — 499 €, beinhaltet ein Gespräch und einen Bericht. Fünf Sterne. Jetzt kaufen.
• Viktor — Technischer Leiter mit Sitz in Bratislava, verfügbar dienstags.
• API-Dokumentation — Authentifizierung, Grenzen, Fehler, Beispiele, SDKs, Changelog, Status, Support und zwanzig weitere Themen.

Dies scheitert bereits vor dem visuellen Design. Die Menge mischt eine Ressource, eine Dienstleistung, eine Person und einen Dokumentationsbereich. Die Felder wechseln bei jedem Element, „kürzlich“ hat kein Datum, die Bewertung fehlt Quelle und Skala, und die Elementtiefe reicht von einem Fragment bis zu einer Abschnittsgliederung. Teilen Sie den Inhalt nach Zweck auf und wählen Sie dann das registrierte Element für jede Sammlung. Eine Umrandung um inkonsistente Daten ergibt keine benutzerdefinierte Auflistung.

Schlecht: Eine Auflistung, die eine Tabelle sein sollte

Angenommen, sechs Tarife zeigen jeweils monatlichen Preis, Jahrespreis, Benutzerlimit, Speicher, Support-Antwortzeit und SSO-Verfügbarkeit. Leser müssen dieselben sechs Werte über alle Tarife hinweg vergleichen. Eine Auflistung würde sie zwingen, sich an Tarif eins zu erinnern, während sie durch Tarif sechs scrollen. Verwenden Sie eine Vergleichstabelle, weil die Aufgabe der elementübergreifende Vergleich ist. Wenn jeder Tarif auch ein Positionierungsstatement und eine Kaufaktion benötigt, platzieren Sie diese außerhalb oder neben der Tabelle mit der registrierten Tarifkomponente der Seite; duplizieren Sie keine widersprüchlichen Werte in zwei Quellen.

Schema-Markup und Barrierefreiheit

Rendern Sie die Sammlung mit nativen Listensemantiken. Verwenden Sie <ul>, wenn die Elementreihenfolge keine Bedeutung hat, und <ol>, wenn die Seite eine echte Abfolge oder Rangfolge deklariert. Jeder Eintrag gehört in ein <li>. Verwenden Sie darin eine echte Überschrift auf der korrekten Dokumentebene, einen Absatz für die Zusammenfassung und <dl>, <dt> und <dd> für beschriftete Metadaten. Ein Screenreader sollte den Elementtitel vor seiner Beschreibung, Fakten und Aktion wahrnehmen.

Machen Sie nicht das gesamte Element zu einem übergroßen Link, wenn es ein anderes Steuerelement oder mehrere Textbereiche enthält. Geben Sie dem primären Link eine beschreibende Bezeichnung wie „CSV-Exporteinrichtung anzeigen“. Wenn ein Stretched-Link-Muster verwendet wird, muss sein Fokusindikator sichtbar bleiben und sein zugänglicher Name muss dennoch das Ziel beschreiben. Symbole benötigen Alternativtext nur, wenn sie Informationen vermitteln, die nicht bereits im Text vorhanden sind. Dekorative Symbole sollten für assistive Technologien verborgen sein.

Visuelle Reihenfolge und Quellreihenfolge müssen übereinstimmen. Ein mehrspaltiges Desktop-Layout muss zusammenbrechen, ohne Element eins, drei, fünf und dann zwei zu lesen. Metadaten-Beschriftungen dürfen nicht verschwinden, nur weil wiederholte Werte visuell ausgerichtet erscheinen; „Enterprise“ allein sagt einem nicht-visuellen Leser nicht, ob es Verfügbarkeit, Zielgruppe oder Support beschreibt.

ItemList-strukturierte Daten sind optional, kein standardmäßiger Styling-Hook. Verwenden Sie sie, wenn die sichtbare Sammlung eine sinnvolle endliche Liste ist und die Seite davon profitiert, diese Sammlung zu identifizieren. Ordnen Sie jeden sichtbaren Eintrag itemListElement zu. Fügen Sie position nur für eine echte geordnete Liste hinzu und stellen Sie sicher, dass Namen, URLs und Anzahl mit dem gerenderten Inhalt übereinstimmen. Markieren Sie keine Navigationsmenüs, willkürliche Feature-Teaser oder eine unvollständige Menge, als ob sie eine vollständige Rangliste wären. Wenn Einträge identifizierbare Entitäten wie Organisationen oder Softwareanwendungen sind, verwenden Sie den spezifischsten zulässigen Typ nur, wenn die Seite die erforderlichen Identitätsdaten bereitstellt und verifiziert.

Schreibregeln

1. Erklären Sie die Zugehörigkeit, bevor Sie Mitglieder präsentieren. Leser müssen wissen, ob die Menge vollständig, ausgewählt, gesponsert, bewertet oder beispielhaft ist, bevor sie Auslassungen oder die Reihenfolge interpretieren. Geben Sie die Aufnahmeregel im Umfangssatz an.
2. Definieren Sie ein Elementschema, bevor Sie Elemente verfassen. Konsistente Felder ermöglichen es den Lesern, ein Überfliegungsmuster zu erlernen, und erlauben der Validierung, fehlende Inhalte zu erkennen. Legen Sie Pflicht- und optionale Felder fest, bevor Autoren die Sammlung befüllen.
3. Halten Sie Pflichtfelder wirklich universell. Ein nominelles Pflichtfeld, das Autoren bei der Hälfte der Einträge mit „N/A“ füllen, ist das falsche Feld oder ein Beleg dafür, dass die Sammlung verschiedene Elementtypen enthält.
4. Begrenzen Sie sichtbare Metadaten auf drei Paare. Mehr Felder verschieben die Aufgabe in Richtung Vergleich und machen jede Zeile schwer überfliegbar. Verschieben Sie sekundäre Fakten auf die Zielseite oder verwenden Sie eine Tabelle.
5. Schreiben Sie Zusammenfassungen für Unterschiede, nicht für Wiederholungen. Der Titel benennt das Element bereits. Nutzen Sie die Zusammenfassung, um seine relevante Fähigkeit, Zielgruppe, Einschränkung oder Rolle zu erklären.
6. Verwenden Sie parallele Bezeichnungen und Einheiten. Wechseln Sie nicht zwischen „Tarif“, „Verfügbar auf“ und „Stufe“ für dasselbe Konzept. Normalisieren Sie Daten, Währungen, Einheiten und Statusvokabular vor dem Rendern.
7. Geben Sie jedem Element eine primäre Aktion. Konkurrierende Schaltflächen verwandeln eine Referenzliste in ein Kartenraster und verschleiern den beabsichtigten nächsten Schritt. Platzieren Sie sekundäre Ziele auf der Detailseite.
8. Deklarieren Sie eine sinnvolle Reihenfolge. Alphabetische, chronologische, bewertete, redaktionelle und quellsystembezogene Reihenfolgen erzeugen unterschiedliche Erwartungen. Nennen Sie die Reihenfolge, wenn sie die Interpretation beeinflussen könnte.
9. Legen Sie Mindest- und Höchstzahlen fest. Verwenden Sie normalerweise drei bis zwölf Elemente, mit bis zu vierundzwanzig nur in sinnvollen Gruppen. Wechseln Sie das Muster, wenn die Sammlung außerhalb dieser Grenzen liegt.
10. Halten Sie eine einzige Quelle der Wahrheit vor. Wenn Preis, Status, Verfügbarkeit oder ein anderes veränderliches Feld anderswo erscheint, befüllen Sie jede Darstellung aus derselben eigenen Quelle und geben Sie bei Bedarf ein Prüfdatum an.

Beitragstypen, die es verwenden

• Ein Listenführer verwendet eine benutzerdefinierte Auflistung, wenn jeder ausgewählte Eintrag dieselbe Zusammenfassung, Eignung, Einschränkung und Weiterleitung benötigt, aber keine dichte Vergleichsmatrix.
• Eine Best-X-for-Y-Seite kann sie für zielgruppenspezifische Empfehlungen verwenden, nachdem die Bewertungsmethode erläutert wurde. Die Rangfolge muss explizit sein und nicht durch die visuelle Anordnung impliziert werden.
• Eine Alternatives-to-X-Seite kann Ersatzoptionen mit konsistenten Feldern für „am besten geeignet für“, Kompromisse und Detail-Links präsentieren, bevor ein engerer Vergleich folgt.
• Eine Kategorieseite verwendet eine kompakte oder gruppierte Auflistung, um eine überschaubare Menge untergeordneter Produkte oder Dienstleistungen vorzusehen, wenn eine Filterung noch nicht erforderlich ist.
• Ein Verzeichnisindex verwendet das Element nur für eine Vorschau oder ein kleines, stabiles Verzeichnis. Große Entitätsmengen benötigen Suche, Filter, Seitenaufteilung und eine datengestützte Verzeichnisoberfläche.
• Ein Unternehmensprofil kann verifizierte Geschäftsbereiche, Zertifizierungen oder Standorte auflisten, wenn jeder Eintrag dieselben Felder gemeinsam hat.
• Ein Anbieterprofil kann unterstützte Dienstleistungen, Regionen oder Engagementmodelle auflisten, ohne das Profil in ein Produktraster zu verwandeln.
• Eine Integrationsseite kann unterstützte Workflows, Datenobjekte, Trigger oder Ziele mithilfe eines vorhersagbaren Fähigkeits- und Anforderungsschemas auflisten.

Das Vorhandensein einer Sammlung erfordert nicht dieses Element. Verwenden Sie es nur, wenn das benutzerdefinierte Feldmodell die Abrufbarkeit oder Navigation verbessert. Eine kurze Liste von Voraussetzungen gehört weiterhin in Aufzählungspunkte, und eine Matrix von Fähigkeiten gehört weiterhin in eine Tabelle.

QA-Checkliste

• Die Sammlung hat einen Titel und einen Umfangssatz, der die Aufnahmebedingung definiert.
• Jedes Element repräsentiert dieselbe Art von Entität, Ressource, Fähigkeit oder Option.
• Pflicht- und optionale Felder sind vor der Inhaltseingabe dokumentiert.
• Jedes Element hat eine eindeutige stabile ID, einen Titel und eine 12–60-Wörter-Zusammenfassung.
• Kein Element erfindet ein Feld, das im registrierten Schema nicht vorhanden ist.
• Die Sammlung enthält 3–12 Elemente oder begründete Gruppen mit nicht mehr als 24 insgesamt.
• Elemente haben nicht mehr als drei sichtbare Metadatenpaare und eine primäre Aktion.
• Bezeichnungen, Einheiten, Statusangaben, Daten und Aktionsformulierungen sind konsistent.
• Die Reihenfolge wird deklariert, wenn sie Rangfolge, Chronologie oder Priorität impliziert.
• Stattdessen wurde eine Tabelle gewählt, wenn der elementübergreifende Vergleich die Hauptaufgabe ist.
• Die Ausgabe verwendet ein semantisches <ul> oder <ol> mit einem <li> pro Element.
• Überschriften folgen der Seitenhierarchie und Metadaten verwenden Begriff-Beschreibungs-Semantik.
• Der Tastaturfokus ist sichtbar und Links beschreiben ihre Ziele.
• Die Quellreihenfolge stimmt mit der visuellen Reihenfolge bei Desktop- und Mobilbreiten überein.
• ItemList-Markup, falls vorhanden, stimmt mit den sichtbaren Elementen, der Reihenfolge, der Anzahl, den Namen und den URLs überein.
• Veränderliche Werte stammen aus einer eigenen Quelle und enthalten ein angemessenes Prüfdatum.

FAQ

Die folgenden Fragen klären die Abgrenzungen, die am häufigsten dazu führen, dass eine benutzerdefinierte Auflistung in Aufzählungen, Karten oder Tabellen abdriftet.

Was ist eine benutzerdefinierte Auflistung?

Eine benutzerdefinierte Auflistung ist eine wiederholbare Sammlung, deren Elemente ein kleines, benanntes Feldschema gemeinsam haben, wie Titel, Zusammenfassung, Metadaten und Link. Sie liegt zwischen einer einfachen Aufzählungsliste und einem visuell eigenständigen Kartenraster.

Wie viele Elemente sollte eine benutzerdefinierte Auflistung enthalten?

Verwenden Sie drei bis zwölf Elemente als normalen redaktionellen Rahmen. Zwei Elemente benötigen in der Regel Fließtext oder eine Side-by-Side-Komponente. Mehr als zwölf benötigen sinnvolle Gruppierung, Filterung, Seitenaufteilung oder ein Verzeichnismuster; die gruppierte Variante darf vierundzwanzig Elemente nicht überschreiten.

Wann sollte eine benutzerdefinierte Auflistung zu einer Tabelle werden?

Verwenden Sie eine Tabelle, wenn Leser die meisten Elemente anhand derselben drei oder mehr Felder vergleichen müssen, insbesondere bei Zahlenwerten, Daten, Statusangaben oder Ja/Nein-Funktionen. Behalten Sie eine Auflistung bei, wenn Zusammenfassungen und Weiterleitungs-Links wichtiger sind als der Vergleich zwischen den Elementen.

Benötigt eine benutzerdefinierte Auflistung ein ItemList-Schema?

Nein. Fügen Sie ItemList nur hinzu, wenn die Sammlung sinnvoll und endlich ist, jedes ausgezeichnete Element sichtbar ist und jede Position eine deklarierte Reihenfolge widerspiegelt. Gewöhnliche Navigations-, Teaser- und verwandte Inhaltslisten benötigen in der Regel semantisches HTML anstelle eines speziellen Schemas.

Können Elemente unterschiedliche Felder haben?

Nur optionale Felder, die durch das gemeinsame Schema definiert sind, dürfen fehlen. Lassen Sie nicht zu, dass Autoren feldspezifische Angaben pro Element erfinden. Wenn mehrere Elemente ein anderes Informationsmodell benötigen, teilen Sie sie in eine andere Auflistung auf oder wählen Sie ein besser geeignetes Element.