Listări Personalizate: Schemă de Elemente, Limite și Exemple

O listare personalizată este o colecție repetabilă de elemente care împart o schemă mică de câmpuri. Fiecare element poate avea un titlu, un rezumat concis, una sau două valori de metadate și un link de destinație. Această structură oferă cititorilor mai mult context decât o listă cu puncte fără a face fiecare element să se comporte ca un card de produs independent.

Exemplu — formate de export suportate

• CSV — Rânduri tabelare pentru analiză în foi de calcul. Cel mai bun pentru înregistrări plate. Disponibilitate: Toate planurile. Acțiune: Vezi configurarea exportului CSV.
• JSON — Înregistrări imbricate pentru aplicații și fluxuri de date. Cel mai bun pentru păstrarea relațiilor între câmpuri. Disponibilitate: Pro și Enterprise. Acțiune: Citește referința JSON.
• Google Sheets — O foaie de lucru sincronizată pentru echipe care revizuiesc date fără cod. Disponibilitate: Pro și Enterprise. Acțiune: Conectează Google Sheets.

Elementul redat nu ar trebui să fie o versiune decorativă a acelor puncte. Ar trebui să expună o singură colecție care conține trei elemente, iar fiecare element ar trebui să păstreze aceleași câmpuri title, summary, bestFor, availability și url. Modelul de câmpuri — nu bordura, pictograma sau numărul de coloane — este ceea ce face listarea personalizată.

De ce contează acest element

Proza obișnuită ascunde repetiția. Dacă șase integrări sunt descrise în șase paragrafe, un cititor trebuie să descopere că fiecare paragraf conține un nume de sistem, acțiune suportată, cerință de cont și link de configurare. O listare personalizată denumește acele părți recurente printr-o singură schemă de elemente: un set definit de câmpuri folosit de fiecare element. Cititorii învață modelul după prima intrare și pot parcurge intrările ulterioare în mod predictibil.

Această consistență îmbunătățește și reutilizarea. Un sistem de gestionare a conținutului poate valida câmpurile obligatorii, un șablon poate reda fiecare element fără markup specific paginii, iar o aplicație din aval poate transforma aceeași sursă într-o listă mobilă compactă sau într-un director căutabil. Motoarele de căutare și sistemele AI primesc limite discrete între elemente, în loc să fie nevoite să deducă unde se termină o entitate și începe alta.

Elementul contează deoarece există un decalaj comun între două structuri valide. Punctele funcționează când fiecare element este o afirmație compactă. Cardurile funcționează când fiecare element are nevoie de imagini independente, mai multe atribute comerciale, o acțiune proeminentă sau suficientă greutate vizuală pentru a sta singur. Multe colecții nu au nevoie de niciun extrem. O listă de integrări poate necesita un nume, un rezumat al capacității în două propoziții, o stare și un link. Aplatizarea acestora în puncte pierde câmpurile; umflarea lor în carduri irosește spațiu și face o colecție de referință să pară promoțională.

Structura nu este o scuză pentru a face fiecare colecție unică. Un design unicat produce câmpuri inconsistente, ordonare, accesibilitate și comportament responsive. Prin urmare, regulile de redactare pentru elemente se aplică mai întâi: identifică necesarul de informații repetat, înregistrează cea mai mică schemă care îl satisface și păstrează conținutul portabil între randări.

Când să îl folosești

Folosește o listare personalizată atunci când toate elementele răspund la aceeași întrebare a cititorului, fiecare are nevoie de două până la cinci câmpuri vizibile, iar sarcina principală este inspectarea sau navigarea, nu compararea fiecărei valori una lângă alta. Colecțiile potrivite includ integrări, zone de servicii, formate suportate, descărcări de resurse, tipuri de parteneri, responsabilități de echipă, previzualizări de director și caracteristici grupate.

Rulează patru teste înainte de a-l alege:

1. Repetabilitate: Poate fiecare element să folosească aceleași câmpuri obligatorii fără a inventa excepții?
2. Independență: Poate un cititor să înțeleagă un element fără a-l citi pe cel anterior?
3. Scanare: Este modelul titlu-plus-rezumat mai util decât un grid de valori comparabile?
4. Acțiune: Are fiecare element nevoie de cel mult o destinație principală?

Dacă răspunsurile sunt da, o listare personalizată este probabil potrivită. Folosește un alt element atunci când colecția eșuează la unul dintre aceste teste:

• Folosește o listă cu puncte când elementele au nevoie doar de o propoziție paralelă și fără metadate separate.
• Folosește un tabel comparativ când cititorii trebuie să scaneze aceleași criterii vertical sau orizontal între alternative.
• Folosește un card de produs când imaginea, prețul, oferta, evaluarea, disponibilitatea și acțiunea de cumpărare fac din fiecare element o unitate comercială substanțială.
• Folosește o listă de pași când poziția exprimă o secvență, nu o ordonare editorială.
• Folosește un ghid sau un model de definiție când fiecare intrare este fundamental o pereche termen–definiție.
• Folosește titluri și proză când elementele necesită câmpuri diferite sau mai mult de aproximativ 100 de cuvinte de explicație fiecare.

Nu alege o listare personalizată doar pentru că designul solicită casete repetate. Mai întâi demonstrează că există un model de conținut stabil. Dacă elementul unu are un preț, elementul doi o biografie de autor, iar elementul trei o dimensiune de descărcare, nu sunt o singură colecție, chiar dacă CSS le poate alinia.

Unde să o plasezi

Plasează listarea după ce pagina definește colecția și regula de includere. „Integrări suportate” este o etichetă; „Aceste integrări pot trimite pagini auditate către un spațiu de lucru de raportare deținut” le spune cititorilor ce înseamnă apartenența. Atunci când selecția sau testarea a creat setul, explică acea metodă înainte de primul element, astfel încât listarea să nu sugereze exhaustivitate sau clasament nejustificat.

Plasează colecția aproape de sarcina de decizie sau navigare pe care o servește. O pagină de integrare ar trebui să introducă conexiunea și rezultatul acesteia înainte de a lista fluxurile de lucru suportate. Un director ar trebui să explice domeniul și filtrele înainte de a afișa intrări. Un ghid listicol ar trebui să își declare metoda de evaluare înainte de a prezenta elementele selectate.

Nu întrerupe o listare cu proză, reclame, îndemnuri la acțiune sau capturi de ecran nelegate. Limitele dintre elemente trebuie să rămână consecutive. Plasează calificările în metadatele definite ale elementului afectat sau explică o condiție la nivelul întregii colecții înainte sau după întreaga listă. Dacă sunt necesare mai mult de douăsprezece elemente, grupează-le sub subtitluri semnificative, adaugă filtrare sau redirecționează cititorii către un Index de director . Nu crea o stivă vizuală nesfârșită.

Anatomie

O listare personalizată completă are următoarele regiuni:

1. Titlul colecției: denumește setul în limbajul cititorului, nu numele intern al componentei.
2. Enunțul de domeniu: definește ce se califică pentru includere și dacă colecția este completă, selectată sau ilustrativă.
3. Containerul listei: stabilește o colecție semantică unică și deține numărul de elemente.
4. Titlul elementului: identifică unic entitatea, resursa, capacitatea sau opțiunea.
5. Rezumatul elementului: explică diferența relevantă sau utilitatea elementului într-una sau două propoziții.
6. Grupul de metadate: expune zero până la trei fapte etichetate din schema înregistrată.
7. Acțiunea principală: face legătura către o destinație clară, folosind text de ancoră descriptiv.
8. Limita elementului: folosește spațiere, o linie sau un tratament de suprafață reținut, fără a deconecta elementul de colecția sa.

Enunțul de domeniu previne o eroare frecventă de acuratețe. „Integrări disponibile” sugerează exhaustivitate; „Integrări comune de raportare” declară o selecție. Autorul trebuie să aleagă formularea pe care sursa de date o poate susține.

Exemple de design

Renderer-ul poate varia densitatea, dar trebuie să păstreze ordinea câmpurilor, structura semantică a listei și o secvență de citire previzibilă.

Listare editorială suprapusă

Folosește designul implicit suprapus atunci când rezumatele aduc cea mai mare valoare. Păstrează titlul primul, rezumatul al doilea, metadatele al treilea și acțiunea ultima. Un separator subtil este suficient; fiecare element nu are nevoie de un card reliefat.

Previzualizare compactă de director

Folosește o variantă compactă atunci când titlurile și o valoare de metadate permit cititorilor să aleagă o destinație. Rezumatul poate fi mai scurt, dar etichetele trebuie să rămână vizibile. Nu înlocui niciodată o stare semnificativă cu un punct colorat neexplicat.

Listare grupată

Folosește grupuri atunci când o clasificare stabilă reduce o colecție de opt până la douăzeci și patru de elemente în secțiuni. Titlurile grupurilor trebuie să descrie o taxonomie reală, cum ar fi tipul de export sau regiunea de service. Nu grupa doar pentru a obține coloane egale.

Vizualizare îngustă

La lățimi înguste, păstrează ordinea sursei și suprapune metadatele sub rezumat. Nu ascunde câmpurile care rămân relevante, nu micșora textul pentru a menține coloanele și nu muta acțiunile departe de elementul lor.

Parametri

Schema de mai jos este intenționat limitată. Un câmp devine parte a componentei doar atunci când este util în întreaga colecție, nu pentru că un element se întâmplă să aibă date pentru el.

Trei elemente reprezintă minimul deoarece o pereche este de obicei mai clară ca proză, o comparație pe două coloane sau două carduri substanțiale. Doisprezece este maximul normal deoarece scanarea unei stive lungi nefiltrate devine ineficientă. Plafonul de douăzeci și patru pentru grupuri este o limită de siguranță, nu o țintă; seturile mai mari sau care se schimbă frecvent au nevoie de un director, căutare, paginare sau o aplicație bazată pe date.

Alege ordered=true doar atunci când ordinea vizibilă exprimă un clasament declarat. Comoditatea editorială, sortarea alfabetică sau ordinea sursei de date nu creează un clasament. Când clasamentul este real, menționează metodologia și păstrează poziția atât în rezultatul vizibil, cât și în orice date structurate.

Sintaxă și exemple de cod

Directiva portabilă definește contractul de autorizare. Adaptoarele de platformă pot stoca datele diferit, dar trebuie să păstreze aceleași nume de câmpuri, ordinea elementelor, opționalitatea și rezultatul vizibil.

Directivă portabilă Markdown

:::custom-listing{title="Formate de export" variant=stacked}
Acestea sunt formatele disponibile pentru trimiterea înregistrărilor de audit finalizate către un alt spațiu de lucru.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Rânduri tabelare pentru analiză în foi de calcul și ingestie de fișiere plate.

- Cel mai bun pentru: Analiză în foi de calcul
- Disponibilitate: Toate planurile
- Acțiune: Vezi configurarea exportului CSV
:::

:::item{id=json title="JSON" url="/docs/exports/json/"}
Înregistrări imbricate care păstrează relațiile pentru aplicații și fluxuri de date.

- Cel mai bun pentru: Fluxuri de lucru automatizate
- Disponibilitate: Pro și Enterprise
- Acțiune: Citește referința JSON
:::

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
O foaie de lucru sincronizată pentru echipe care revizuiesc date fără cod.

- Cel mai bun pentru: Revizuire partajată
- Disponibilitate: Pro și Enterprise
- Acțiune: Conectează Google Sheets
:::
:::

URL-urile din exemplu descriu doar sintaxa portabilă; o implementare trebuie să le înlocuiască cu destinații verificate. Nu publica o cale de exemplu ca link real doar pentru că apare într-un bloc de cod.

Adaptor Hugo

{{< custom-listing title="Formate de export" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="Vezi configurarea exportului CSV" >}}
  Rânduri tabelare pentru analiză în foi de calcul și ingestie de fișiere plate.

  **Cel mai bun pentru:** Analiză în foi de calcul  
  **Disponibilitate:** Toate planurile
  {{< /custom-listing-item >}}
{{< /custom-listing >}}

Această notație specifică un adaptor viitor sau la nivel de proiect; nu autorizează crearea unui shortcode la nivel de pagină. Toți parametrii sunt denumiți. Până la existența unui adaptor, redă colecția ca HTML semantic cu <ul> și <li> sau ca Markdown nativ, mai degrabă decât să elimini în tăcere relațiile dintre câmpuri.

Bloc WordPress

<!-- wp:amicited/custom-listing {"title":"Formate de export","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Rânduri tabelare pentru analiză în foi de calcul și ingestie de fișiere plate.</p>
    <dl><dt>Cel mai bun pentru</dt><dd>Analiză în foi de calcul</dd><dt>Disponibilitate</dt><dd>Toate planurile</dd></dl>
    <a href="/docs/exports/csv/">Vezi configurarea exportului CSV</a>
  </li>
</ul>
<!-- /wp:amicited/custom-listing -->

Blocurile native sunt o soluție de rezervă acceptabilă atunci când produc o singură listă, un element de listă pe intrare, titluri reale, o listă de definiții pentru metadate etichetate și linkuri descriptive. Un bloc generic Columns nu este un substitut de încredere, deoarece ordinea sursei și gruparea elementelor se strică adesea pe mobil.

Exemple

Bun: o listare consistentă de resurse

Resurse pentru migrare

Aceste resurse sprijină echipele în pregătirea, executarea și validarea unei migrări de site.

1. Foaie de lucru pentru maparea redirecționărilor — Înregistrează fiecare URL vechi, destinația aprobată, responsabilul și starea de validare. Format: Foaie de calcul. Etapă: Planificare. Acțiune: Descarcă foaia de lucru pentru redirecționări.
2. Script de validare pentru ziua lansării — Verifică codurile de răspuns, lanțurile de redirecționare, țintele canonice și indexabilitatea pentru setul de URL-uri migrat. Format: Script. Etapă: Lansare. Acțiune: Revizuiește configurarea validării.
3. Vizualizare de monitorizare post-lansare — Urmărește eșecurile de crawling și schimbările neașteptate de trafic după implementare. Format: Dashboard. Etapă: Monitorizare. Acțiune: Configurează vizualizarea de monitorizare.

Acest exemplu funcționează deoarece fiecare element folosește aceleași cinci câmpuri: titlu, rezumat, format, etapă și acțiune. Domeniul explică de ce resursele aparțin împreună. Numerotarea reflectă etapa declarată de migrare, nu o afirmație că prima resursă este „cea mai bună”. Fiecare acțiune își identifică destinația în loc să repete „Află mai multe”.

Rău: casete fără un model comun

Lucruri utile

• Checklist SEO — Ghidul nostru preferat. Actualizat recent. Află mai multe.
• Audit premium — 499 €, include un apel și un raport. Cinci stele. Cumpără acum.
• Viktor — Lider tehnic cu sediul în Bratislava, disponibil marțea.
• Documentație API — Autentificare, limite, erori, exemple, SDK-uri, jurnal de modificări, stare, suport și încă douăzeci de subiecte.

Acest exemplu eșuează înainte ca designul vizual să înceapă. Setul amestecă o resursă, un serviciu, o persoană și o zonă de documentație. Câmpurile se schimbă la fiecare element, „recent” nu are o dată, evaluarea nu are sursă și scală, iar profunzimea elementelor variază de la un fragment la o schiță de secțiune. Împarte conținutul pe scop, apoi alege elementul înregistrat pentru fiecare colecție. O bordură în jurul datelor inconsistente nu creează o listare personalizată.

Rău: o listare care ar trebui să fie un tabel

Să presupunem că șase planuri arată fiecare preț lunar, preț anual, limită de utilizatori, stocare, timp de răspuns la suport și disponibilitate SSO. Cititorii trebuie să compare aceleași șase valori pentru fiecare plan. O listare i-ar forța să rețină planul unu în timp ce derulează prin planul șase. Folosește un tabel comparativ, deoarece sarcina este evaluarea între elemente. Dacă fiecare plan are nevoie și de o declarație de poziționare și o acțiune de cumpărare, plasează-le în afara sau lângă tabel, folosind componenta de plan înregistrată a paginii; nu duplica valori contradictorii în două surse.

Marcarea schemei și accesibilitatea

Redă colecția cu semantică nativă de listă. Folosește <ul> când ordinea elementelor nu are semnificație și <ol> când pagina declară o secvență sau un clasament real. Fiecare intrare aparține unui singur <li>. În interior, folosește un titlu real la nivelul corect al documentului, un paragraf pentru rezumat și <dl>, <dt> și <dd> pentru metadate etichetate. Un cititor de ecran ar trebui să întâlnească titlul elementului înaintea descrierii, faptelor și acțiunii sale.

Nu face întregul element un link supradimensionat atunci când conține un alt control sau mai multe zone de text. Oferă linkului principal o etichetă descriptivă, cum ar fi „Vezi configurarea exportului CSV”. Dacă se folosește un model de link întins, indicatorul său de focalizare trebuie să rămână vizibil, iar numele său accesibil trebuie să descrie în continuare destinația. Pictogramele au nevoie de text alternativ doar atunci când comunică informații care nu sunt deja prezente în text. Pictogramele decorative ar trebui ascunse tehnologiei de asistare.

Ordinea vizuală și ordinea sursei trebuie să coincidă. Un aspect desktop pe mai multe coloane trebuie să se restrângă fără a citi elementul unu, elementul trei, elementul cinci, apoi elementul doi. Etichetele de metadate nu pot dispărea doar pentru că valorile repetate apar aliniate vizual; „Enterprise” singur nu spune unui cititor non-vizual dacă descrie disponibilitatea, audiența sau suportul.

Datele structurate ItemList sunt opționale, nu un cârlig de stilizare implicit. Folosește-le atunci când colecția vizibilă este o listă finită semnificativă și pagina beneficiază de pe urma identificării acelei colecții. Mapează fiecare intrare vizibilă la itemListElement. Include position doar pentru o listă ordonată reală și asigură-te că numele, URL-urile și numărătoarea se potrivesc cu conținutul redat. Nu marca meniuri de navigare, teasere de funcții arbitrare sau un set parțial ca și cum ar fi o listă completă clasată. Când intrările sunt entități identificabile, cum ar fi organizații sau aplicații software, folosește cel mai specific tip eligibil doar atunci când pagina furnizează și verifică datele de identitate necesare.

Reguli de redactare

1. Explică apartenența înainte de a prezenta membrii. Cititorii trebuie să știe dacă setul este complet, selectat, sponsorizat, clasat sau ilustrativ înainte de a interpreta omisiunea sau ordinea. Enunță regula de includere în propoziția de domeniu.
2. Definește o schemă de elemente înainte de a redacta elementele. Câmpurile consistente permit cititorilor să învețe un model de scanare și permit validarea să detecteze conținutul lipsă. Înregistrează câmpurile obligatorii și opționale înainte ca autorii să popula colecția.
3. Menține câmpurile obligatorii cu adevărat universale. Un câmp nominal obligatoriu pe care autorii îl completează cu „N/A” în jumătate din intrări este fie câmpul greșit, fie dovada că colecția conține tipuri diferite de elemente.
4. Limitează metadatele vizibile la trei perechi. Mai multe câmpuri mută sarcina către comparare și fac fiecare rând greu de scanat. Mută faptele secundare pe pagina de destinație sau folosește un tabel.
5. Scrie rezumate pentru diferență, nu pentru repetiție. Titlul denumește deja elementul. Folosește rezumatul pentru a explica capacitatea relevantă, audiența, limitarea sau rolul acestuia.
6. Folosește etichete și unități paralele. Nu alterna „Plan”, „Disponibil pe” și „Nivel” pentru același concept. Normalizează datele, monedele, unitățile și vocabularul stărilor înainte de redare.
7. Oferă fiecărui element o singură acțiune principală. Butoanele concurente transformă o listă de referință într-un grid de carduri și ascund următorul pas intenționat. Plasează destinațiile secundare pe pagina de detalii.
8. Declară ordinea semnificativă. Ordinea alfabetică, cronologică, clasată, editorială și cea a sistemului sursă creează așteptări diferite. Numește ordinea atunci când ar putea afecta interpretarea.
9. Stabilește numărătoarea minimă și maximă. Folosește trei până la doisprezece elemente în mod normal, până la douăzeci și patru doar în grupuri utile. Schimbă modelul atunci când colecția depășește aceste limite.
10. Menține o singură sursă de adevăr. Dacă prețul, starea, disponibilitatea sau un alt câmp volatil apare în altă parte, populează fiecare reprezentare din aceeași sursă deținută și expune o dată de verificare acolo unde este necesar.

Tipuri de postări care îl folosesc

• Un Ghid listicol folosește o listare personalizată atunci când fiecare intrare selectată are nevoie de același rezumat, potrivire, limitare și link de continuare, dar nu de o matrice densă de comparație.
• O Pagină Cel-mai-bun-X-pentru-Y îl poate folosi pentru recomandări specifice audienței, după explicarea metodei de evaluare. Clasamentul trebuie să fie explicit, nu implicit prin ordinea vizuală.
• O Pagină Alternative-la-X poate prezenta opțiuni de înlocuire cu câmpuri consistente „cel mai bun pentru”, schimburi și linkuri de detalii, înainte de o comparație mai restrânsă.
• O Pagină de categorie folosește o listare compactă sau grupată pentru a previzualiza un set gestionabil de produse sau servicii subordonate, când filtrarea nu este încă necesară.
• Un index de director folosește elementul doar pentru o previzualizare sau un director mic și stabil. Seturile mari de entități au nevoie de căutare, filtre, paginare și o interfață de director bazată pe date.
• Un Profil de companie poate lista unități de afaceri verificate, certificări sau locații, atunci când fiecare intrare împărtășește aceleași câmpuri.
• Un Profil de furnizor poate lista servicii suportate, regiuni sau modele de implicare, fără a transforma profilul într-un grid de produse.
• O Pagină de integrare poate lista fluxurile de lucru suportate, obiectele de date, declanșatoarele sau destinațiile, folosind o schemă predictibilă de capacități și cerințe.

Prezența unei colecții nu impune acest element. Folosește-l doar atunci când modelul personalizat de câmpuri îmbunătățește regăsirea sau navigarea. Un set scurt de prerequisite aparține în continuare punctelor, iar o matrice de capacități aparține în continuare unui tabel.

Checklist QA

• Colecția are un titlu și o propoziție de domeniu care definește includerea.
• Fiecare element reprezintă același tip de entitate, resursă, capacitate sau opțiune.
• Câmpurile obligatorii și opționale sunt documentate înainte de introducerea conținutului.
• Fiecare element are un ID unic stabil, un titlu și un rezumat de 12–60 de cuvinte.
• Niciun element nu inventează un câmp care lipsește din schema înregistrată.
• Colecția conține 3–12 elemente sau grupuri justificate cu cel mult 24 în total.
• Elementele nu au mai mult de trei perechi de metadate vizibile și o singură acțiune principală.
• Etichetele, unitățile, stările, datele și formularea acțiunilor sunt consistente.
• Ordinea este declarată atunci când implică clasament, cronologie sau prioritate.
• Un tabel a fost ales în schimb atunci când comparația între elemente este sarcina principală.
• Rezultatul folosește un <ul> sau <ol> semantic cu un <li> per element.
• Titlurile urmează ierarhia paginii, iar metadatele folosesc semantică termen–descriere.
• Focalizarea tastaturii este vizibilă, iar linkurile descriu destinațiile lor.
• Ordinea sursei coincide cu ordinea vizuală la lățimi desktop și mobil.
• Marcarea ItemList, dacă este prezentă, se potrivește cu elementele vizibile, ordinea, numărul, numele și URL-urile.
• Valorile volatile provin dintr-o sursă deținută și includ o dată de verificare adecvată.

Întrebări frecvente

Întrebările de mai jos rezolvă limitele care fac cel mai adesea ca o listare personalizată să alunece spre puncte, carduri sau tabele.

Ce este o listare personalizată?

O listare personalizată este o colecție repetabilă ai cărei itemi împart o schemă mică de câmpuri denumite, cum ar fi titlu, rezumat, metadate și link. Se situează între o simplă listă cu puncte și un grid de carduri independente vizual.

Câte elemente ar trebui să conțină o listare personalizată?

Folosește trei până la doisprezece elemente ca interval editorial normal. Două elemente necesită de obicei proză sau o componentă unul lângă altul. Mai mult de douăsprezece necesită grupare utilă, filtrare, paginare sau un model de director; varianta grupată nu trebuie să depășească douăzeci și patru de elemente.

Când ar trebui o listare personalizată să devină un tabel?

Folosește un tabel atunci când cititorii trebuie să compare majoritatea elementelor după aceleași trei sau mai multe câmpuri, în special valori numerice, date, stări sau capacități da/nu. Păstrează o listare atunci când rezumatele și linkurile de continuare contează mai mult decât comparația între elemente.

Are o listare personalizată nevoie de schemă ItemList?

Nu. Adaugă ItemList doar atunci când colecția este semnificativă și finită, fiecare element marcat este vizibil, iar orice poziție reflectă o ordine declarată. Navigările obișnuite, listele de teasere și conținut similar necesită de obicei HTML semantic, nu o schemă specială.

Pot elementele să aibă câmpuri diferite?

Doar câmpurile opționale definite de schema comună pot lipsi. Nu lăsa autorii să inventeze câmpuri per element. Dacă mai multe elemente au nevoie de un model informațional diferit, împarte-le într-o altă listare sau alege un element mai potrivit.