Anpassade listor: Objektschema, gränser och exempel

En anpassad lista är en återkommande samling av objekt som delar ett litet fältschema. Varje objekt kan ha en titel, en kort sammanfattning, ett eller två metadatavärden och en destinationslänk. Den strukturen ger läsarna mer sammanhang än en punktlista utan att få varje objekt att bete sig som ett fristående produktkort .

Exempel — exporterade format som stöds

• CSV — Tabellrader för kalkylbladsanalys. Bäst för platta poster. Tillgänglighet: Alla planer. Åtgärd: Visa CSV-exportinställningar.
• JSON — Hierarkiska poster för applikationer och datapipelines. Bäst för att bevara fältrelationer. Tillgänglighet: Pro och Enterprise. Åtgärd: Läs JSON-referensen.
• Google Sheets — Ett synkroniserat kalkylblad för team som granskar data utan kod. Tillgänglighet: Pro och Enterprise. Åtgärd: Anslut Google Sheets.

Det renderade elementet bör inte vara en dekorativ version av dessa punkter. Det bör visa en samling som innehåller tre objekt, och varje objekt bör ha samma fält title, summary, bestFor, availability och url. Fältmodellen — inte kanten, ikonen eller kolumnantalet — är det som gör listan anpassad.

Varför detta element är viktigt

Vanlig brödtext döljer upprepningar. Om sex integrationer beskrivs i sex stycken måste en läsare upptäcka att varje stycke innehåller ett systemnamn, en åtgärd som stöds, ett kontokrav och en installationslänk. En anpassad lista namnger dessa återkommande delar genom ett objektschema: en definierad uppsättning fält som används av varje objekt. Läsare lär sig mönstret efter den första posten och kan skanna senare poster förutsägbart.

Den konsekvensen förbättrar också återanvändning. Ett innehållshanteringssystem kan validera obligatoriska fält, en mall kan rendera varje objekt utan sidspecifik markup, och en nedströmsapplikation kan omvandla samma källa till en kompakt mobil lista eller en sökbar katalog. Sökmotorer och AI-system får diskreta objektgränser istället för att behöva gissa var en enhet slutar och en annan börjar.

Elementet är viktigt eftersom det finns ett vanligt gap mellan två giltiga strukturer. Punkter fungerar när varje objekt är ett kompakt påstående. Kort fungerar när varje objekt behöver oberoende bilder, flera kommersiella attribut, en framträdande åtgärd eller tillräcklig visuell tyngd för att stå ensam. Många samlingar behöver varken extremen. En integrationslista kan kräva ett namn, en tvåmeningars sammanfattning av funktioner, en status och en länk. Att platta ut det till punkter förlorar fälten; att blåsa upp det till kort slösar plats och får en referenssamling att kännas reklamaktig.

Struktur är inte en ursäkt för att göra varje samling unik. En engångsdesign ger inkonsekventa fält, sortering, tillgänglighet och responsivt beteende. Skrivreglerna för element gäller därför först: identifiera det återkommande informationsbehovet, registrera det minsta schemat som uppfyller det och håll innehållet portabelt över renderare.

När du ska använda det

Använd en anpassad lista när alla objekt svarar på samma läsarfråga, varje behöver två till fem synliga fält, och den primära uppgiften är att granska eller navigera snarare än att jämföra varje värde sida vid sida. Lämpliga samlingar inkluderar integrationer, tjänsteområden, format som stöds, resursnedladdningar, partnertyper, teamansvar, katalogförhandsvisningar och grupperade funktioner.

Utför fyra tester innan du väljer det:

1. Återanvändning: Kan varje objekt använda samma obligatoriska fält utan att uppfinna undantag?
2. Oberoende: Kan en läsare förstå ett objekt utan att läsa föregående objekt?
3. Skannbarhet: Är mönstret med titel-plus-sammanfattning mer användbart än ett rutnät med jämförbara värden?
4. Åtgärd: Behöver varje objekt högst en primär destination?

Om svaren är ja är en anpassad lista troligen lämplig. Använd ett annat element när samlingen misslyckas med ett av dessa test:

• Använd en punktlista när objekt endast behöver en parallell mening och ingen separat metadata.
• Använd en jämförelsetabell när läsare måste skanna samma kriterier vertikalt eller horisontellt över alternativ.
• Använd ett produktkort när bild, pris, erbjudande, betyg, tillgänglighet och köpåtgärd gör varje objekt till en betydande kommersiell enhet.
• Använd en steglista när position uttrycker sekvens snarare än redaktionell ordning.
• Använd ett ordlist- eller definitionsmönster när varje post i grunden är ett term–definitionspar.
• Använd rubriker och brödtext när objekt kräver olika fält eller mer än cirka 100 ord förklaring var.

Välj inte en anpassad lista bara för att designen kräver upprepade rutor. Bevisa först att en stabil innehållsmodell finns. Om objekt ett har ett pris och objekt två har en författarbiografi medan objekt tre har en nedladdningsstorlek, är de inte en samling även om CSS kan justera dem.

Var du ska placera den

Placera listan efter att sidan definierar samlingen och dess inkluderingsregel. “Integrationer som stöds” är en etikett; “Dessa integrationer kan skicka granskade sidor till en egen rapporteringsarbetsyta” berättar för läsarna vad medlemskap innebär. När urval eller tester har skapat uppsättningen, förklara den metoden före det första objektet så att listan inte antyder ogrundad fullständighet eller rankning.

Placera samlingen nära den besluts- eller navigeringsuppgift den tjänar. En integrationssida bör introducera anslutningen och dess resultat innan den listar arbetsflöden som stöds. En katalog bör förklara omfattning och filter innan den visar poster. En listguide bör ange sin utvärderingsmetod innan den presenterar valda objekt.

Avbryt inte en lista med brödtext, annonser, uppmaningar till handling eller orelaterade skärmbilder. Objektgränser måste vara sammanhängande. Placera kvalifikationer inom det berörda objektets definierade metadata eller förklara ett samlingsövergripande villkor före eller efter hela listan. Om fler än tolv objekt är nödvändiga, gruppera dem under meningsfulla underrubriker, lägg till filtrering eller dirigera läsare till ett Katalogindex . Skapa inte en oändlig visuell stapel.

Anatomi

En komplett anpassad lista har dessa regioner:

1. Samlingstitel: namnger samlingen på läsarens språk, inte komponentens interna namn.
2. Omfattningsbeskrivning: definierar vad som kvalificerar för inkludering och om samlingen är fullständig, utvald eller illustrativ.
3. Listbehållare: etablerar en semantisk samling och äger objektantalet.
4. Objekttitel: identifierar entydigt enheten, resursen, funktionen eller alternativet.
5. Objektsammanfattning: förklarar objektets relevanta skillnad eller användning på en eller två meningar.
6. Metadatagrupp: visar noll till tre etiketterade fakta från det registrerade schemat.
7. Primär åtgärd: länkar till en tydlig destination med beskrivande ankartext.
8. Objektgräns: använder avstånd, en linje eller återhållsam ytbehandling utan att koppla bort objektet från sin samling.

Omfattningsbeskrivningen förhindrar ett vanligt noggrannhetsfel. “Tillgängliga integrationer” antyder fullständighet; “Vanliga rapporteringsintegrationer” deklarerar ett urval. Författaren måste välja formulering som källdata kan stödja.

Designexempel

Renderaren kan variera densitet, men måste bevara fältordning, semantisk liststruktur och en förutsägbar läsföljd.

Staplad redaktionell lista

Använd standarddesignen med staplad layout när sammanfattningar bär det mesta av värdet. Håll titeln först, sammanfattningen andra, metadatan tredje och åtgärden sist. En subtil avdelare räcker; varje objekt behöver inte ett upphöjt kort.

Kompakt katalogförhandsvisning

Använd en kompakt variant när titlar och ett metadatavärde låter läsare välja en destination. Sammanfattningen kan vara kortare, men etiketterna måste förbli synliga. Ersätt aldrig en meningsfull status med en oförklarad färgad prick.

Grupperad lista

Använd grupper när en stabil klassificering reducerar en samling på åtta till tjugofyra objekt till sektioner. Grupprubriker måste beskriva en genuin taxonomi såsom exporttyp eller tjänsteregion. Gruppera inte enbart för att uppnå lika kolumner.

Smal visningsyta

Vid smala bredder, bevara källordningen och stapla metadata under sammanfattningen. Dölj inte fält som fortfarande är relevanta, krymp inte text för att behålla kolumner, eller flytta inte åtgärder bort från sitt objekt.

Parametrar

Schemat nedan är avsiktligt begränsat. Ett fält blir en del av komponenten endast när det är användbart över samlingen, inte för att ett objekt råkar ha data för det.

Tre objekt är minimum eftersom ett par oftast är tydligare som brödtext, en tvåkolumnsjämförelse eller två substantiella kort. Tolv är normalt maximum eftersom skanning av en lång ofiltrerad stapel blir ineffektiv. Det grupperade taket på tjugofyra är en skyddsräcke, inte ett mål; större eller ofta föränderliga uppsättningar behöver en katalog, sökning, paginering eller en datadriven applikation.

Välj ordered=true endast när den synliga ordningen uttrycker en deklarerad rankning. Redaktionell bekvämlighet, alfabetisk sortering eller datakällans ordning skapar inte en rangordning. När rankning är verklig, ange metodiken och behåll positionen i både synlig utdata och eventuell strukturerad data.

Syntax och kodexempel

Den portabla direktivet definierar det skriftliga avtalet. Plattformsadaptrar kan lagra data annorlunda, men de måste bevara samma fältnamn, objektordning, valfrihet och synlig utdata.

Portabelt Markdown-direktiv

:::custom-listing{title="Export formats" variant=stacked}
These are the formats available for sending completed audit records to another workspace.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Tabular rows for spreadsheet analysis and flat-file ingestion.

- Best for: Spreadsheet analysis
- Availability: All plans
- Action: View CSV export setup
:::

:::item{id=json title="JSON" url="/docs/exports/json/"}
Nested records that preserve relationships for applications and data pipelines.

- Best for: Automated workflows
- Availability: Pro and Enterprise
- Action: Read the JSON reference
:::

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
A synchronized worksheet for teams that review data without code.

- Best for: Shared review
- Availability: Pro and Enterprise
- Action: Connect Google Sheets
:::
:::

Exempel-URL:erna beskriver endast den portabla syntaxen; en implementation måste ersätta dem med verifierade destinationer. Publicera inte en exempelsökväg som en aktiv länk bara för att den förekommer i ett kodblock.

Hugo-adapter

{{< custom-listing title="Export formats" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="View CSV export setup" >}}
  Tabular rows for spreadsheet analysis and flat-file ingestion.

  **Best for:** Spreadsheet analysis  
  **Availability:** All plans
  {{< /custom-listing-item >}}
{{< /custom-listing >}}

Denna notation specificerar en framtida adapter eller adapter på projektnivå; den ger inte tillstånd att skapa en sidlokal shortcode. Alla parametrar är namngivna. Tills en adapter finns, rendera samlingen som semantisk HTML med <ul> och <li> eller som inbyggd Markdown istället för att tyst tappa fältrelationerna.

WordPress-block

<!-- wp:amicited/custom-listing {"title":"Export formats","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Tabular rows for spreadsheet analysis and flat-file ingestion.</p>
    <dl><dt>Best for</dt><dd>Spreadsheet analysis</dd><dt>Availability</dt><dd>All plans</dd></dl>
    <a href="/docs/exports/csv/">View CSV export setup</a>
  </li>
</ul>
<!-- /wp:amicited/custom-listing -->

Inbyggda block är ett acceptabelt alternativ när de producerar en lista, en listpunkt per post, riktiga rubriker, en definitionslista för etiketterad metadata och beskrivande länkar. Ett generiskt kolumnblock är ingen pålitlig ersättning eftersom källordning och objektgruppering ofta bryts på mobil.

Exempel

Bra: en konsekvent resurslista

Migrationsresurser

Dessa resurser stöder team som förbereder, genomför och validerar en webbplatsmigrering.

1. Omdirigeringskartläggningskalkylblad — Registrerar varje gammal URL, dess godkända destination, ägare och valideringsstatus. Format: Kalkylblad. Steg: Planering. Åtgärd: Ladda ner omdirigeringskalkylbladet.
2. Lanseringsdagsvalideringsskript — Kontrollerar svarskoder, omdirigeringskedjor, kanoniska mål och indexerbarhet för den migrerade URL-uppsättningen. Format: Skript. Steg: Lansering. Åtgärd: Granska valideringsinställningar.
3. Vy för övervakning efter lansering — Spårar crawlfel och oväntade trafikförändringar efter driftsättning. Format: Dashboard. Steg: Övervakning. Åtgärd: Konfigurera övervakningsvyn.

Detta fungerar eftersom varje objekt använder samma fem fält: titel, sammanfattning, format, steg och åtgärd. Omfattningen förklarar varför resurserna hör ihop. Numreringen återspeglar den deklarerade migrationsfasen, inte ett påstående att den första resursen är “bäst”. Varje åtgärd identifierar sin destination istället för att upprepa “Läs mer”.

Dåligt: rutor utan en gemensam modell

Användbara saker

• SEO-checklista — Vår favoritguide. Uppdaterad nyligen. Läs mer.
• Premiumgranskning — €499, inkluderar ett samtal och rapport. Fem stjärnor. Köp nu.
• Viktor — Teknisk ledare baserad i Bratislava, tillgänglig på tisdagar.
• API-dokumentation — Autentisering, begränsningar, fel, exempel, SDK:er, ändringslogg, status, support och tjugo ytterligare ämnen.

Detta misslyckas redan innan visuell design påbörjas. Uppsättningen blandar en resurs, tjänst, person och dokumentationsområde. Fält ändras på varje objekt, “nyligen” har inget datum, betyget saknar källa och skala, och objektets djup sträcker sig från ett fragment till en sektionsöversikt. Dela upp innehållet efter syfte, välj sedan det registrerade elementet för varje samling. En ram runt inkonsekvent data skapar inte en anpassad lista.

Dåligt: en lista som borde vara en tabell

Anta sex planer som var och en visar månadspris, årspris, användargräns, lagring, supporttid och SSO-tillgänglighet. Läsare behöver jämföra samma sex värden över alla planer. En lista skulle tvinga dem att komma ihåg plan ett medan de bläddrar igenom plan sex. Använd en jämförelsetabell eftersom uppgiften är utvärdering mellan objekt. Om varje plan också behöver ett positioneringsutlåtande och köpåtgärd, placera dessa utanför eller bredvid tabellen med sidens registrerade plankomponent; duplicera inte motstridiga värden i två källor.

Schemamarkup och tillgänglighet

Rendera samlingen med inbyggd listsemantik. Använd <ul> när objektordning saknar betydelse och <ol> när sidan deklarerar en äkta sekvens eller rankning. Varje post hör till i en <li>. Inuti den, använd en riktig rubrik på rätt dokumentnivå, ett stycke för sammanfattningen och <dl>, <dt> och <dd> för etiketterad metadata. En skärmläsare bör möta objekttiteln innan dess beskrivning, fakta och åtgärd.

Gör inte hela objektet till en överdimensionerad länk när det innehåller en annan kontroll eller flera textområden. Ge den primära länken en beskrivande etikett såsom “Visa CSV-exportinställningar.” Om ett sträckt-länkmönster används måste dess fokusindikator förbli synlig och dess tillgängliga namn måste fortfarande beskriva destinationen. Ikoner behöver alternativ text endast när de förmedlar information som inte redan finns i text. Dekorativa ikoner bör döljas för hjälpmedelsteknik.

Visuell ordning och källordning måste matcha. En flerkolumns layout för skrivbord måste komprimeras utan att läsa objekt ett, objekt tre, objekt fem och sedan objekt två. Metadataetiketter kan inte försvinna bara för att upprepade värden visas visuellt justerade; “Enterprise” ensamt berättar inte för en icke-visuell läsare om det beskriver tillgänglighet, målgrupp eller support.

Strukturerad data för ItemList är valfritt, inte en standardformateringskrok. Använd det när den synliga samlingen är en meningsfull avgränsad lista och sidan gynnas av att identifiera den samlingen. Mappa varje synlig post till itemListElement. Inkludera position endast för en verkligt ordnad lista, och säkerställ att namn, URL:er och antal matchar det renderade innehållet. Markera inte upp navigeringsmenyer, godtyckliga funktionssmygtittar eller en partiell uppsättning som om de vore en fullständig rankad lista. När poster är identifierbara enheter såsom organisationer eller mjukvaruapplikationer, använd den mest specifika kvalificerade typen endast när sidan tillhandahåller och verifierar nödvändig identitetsdata.

Skrivregler

1. Förklara medlemskap innan du presenterar medlemmar. Läsare behöver veta om uppsättningen är fullständig, utvald, sponsrad, rankad eller illustrativ innan de tolkar utelämnanden eller ordning. Ange inkluderingsregeln i omfattningsmeningen.
2. Definiera ett objektschema innan du utformar objekt. Konsekventa fält låter läsare lära sig ett skanningsmönster och låter validering fånga saknat innehåll. Registrera obligatoriska och valfria fält innan skribenter fyller samlingen.
3. Håll obligatoriska fält verkligt universella. Ett nominellt obligatoriskt fält som skribenter fyller i med “N/A” i hälften av posterna är fel fält eller bevis på att samlingen innehåller olika objekttyper.
4. Begränsa synlig metadata till tre par. Fler fält förskjuter uppgiften mot jämförelse och gör varje rad svår att skanna. Flytta sekundära fakta till målsidan eller använd en tabell.
5. Skriv sammanfattningar för skillnad, inte upprepning. Titeln namnger redan objektet. Använd sammanfattningen för att förklara dess relevanta funktion, målgrupp, begränsning eller roll.
6. Använd parallella etiketter och enheter. Växla inte mellan “Plan”, “Tillgänglig på” och “Nivå” för samma koncept. Normalisera datum, valutor, enheter och statusvokabulär före rendering.
7. Ge varje objekt en primär åtgärd. Konkurrerande knappar förvandlar en referenslista till ett kortrutnät och döljer nästa avsedda steg. Lägg sekundära destinationer på detailsidan.
8. Deklarera meningsfull ordning. Alfabetisk, kronologisk, rankad, redaktionell och källsystemsordning skapar olika förväntningar. Namnge ordningen när den kan påverka tolkning.
9. Sätt minimum- och maximumantal. Använd tre till tolv objekt normalt, med upp till tjugofyra endast i användbara grupper. Byt mönster när samlingen ligger utanför dessa gränser.
10. Håll en sanningskälla. Om pris, status, tillgänglighet eller ett annat föränderligt fält förekommer på annat håll, hämta varje representation från samma ägda källa och visa ett verifieringsdatum där det behövs.

Inläggstyper som använder det

• En Listguide använder en anpassad lista när varje vald post behöver samma sammanfattning, lämplighet, begränsning och vidarelänk men inte en tät jämförelsematris.
• En Bästa-X-för-Y-sida kan använda det för målgruppsspecifika rekommendationer efter att ha förklarat utvärderingsmetoden. Rankning måste vara explicit snarare än antydd av visuell ordning.
• En Alternativ-till-X-sida kan presentera ersättningsalternativ med konsekventa “bäst för”, avvägnings- och detaljlänksfält före en snävare jämförelse.
• En Kategorisida använder en kompakt eller grupperad lista för att förhandsvisa en hanterbar uppsättning underliggande produkter eller tjänster när filtrering ännu inte är nödvändig.
• Ett katalogindex använder elementet endast för en förhandsvisning eller en liten, stabil katalog. Stora enhetsuppsättningar behöver sökning, filter, paginering och ett databaserat kataloggränssnitt.
• En Företagsprofil kan lista verifierade affärsenheter, certifieringar eller platser när varje post delar samma fält.
• En Leverantörsprofil kan lista tjänster som stöds, regioner eller engagemangsmodeller utan att förvandla profilen till ett produktgalleri.
• En Integrationssida kan lista arbetsflöden som stöds, dataobjekt, triggers eller destinationer med ett förutsägbart funktions- och kravschema.

Förekomsten av en samling kräver inte detta element. Använd det endast när den anpassade fältmodellen förbättrar återhämtning eller navigering. En kort uppsättning förutsättningar hör fortfarande hemma i punkter, och en matris av funktioner hör fortfarande hemma i en tabell.

QA-checklista

• Samlingen har en titel och en omfattningsmening som definierar inkludering.
• Varje objekt representerar samma typ av enhet, resurs, funktion eller alternativ.
• Obligatoriska och valfria fält är dokumenterade innan innehållsinmatning.
• Varje objekt har ett unikt stabilt ID, titel och 12–60 ords sammanfattning.
• Inget objekt uppfinner ett fält som saknas i det registrerade schemat.
• Samlingen innehåller 3–12 objekt, eller motiverade grupper med högst 24 totalt.
• Objekt har högst tre synliga metadatapar och en primär åtgärd.
• Etiketter, enheter, statusar, datum och åtgärdstext är konsekventa.
• Ordning är deklarerad när den antyder rankning, kronologi eller prioritet.
• En tabell valdes istället när jämförelse mellan objekt är huvuduppgiften.
• Utdata använder en semantisk <ul> eller <ol> med en <li> per objekt.
• Rubriker följer sidhierarkin och metadata använder term–beskrivningssemantik.
• Tangentbordsfokus är synligt och länkar beskriver sina destinationer.
• Källordning matchar visuell ordning på skrivbords- och mobila bredder.
• ItemList-markup, om den finns, matchar synliga objekt, ordning, antal, namn och URL:er.
• Föränderliga värden kommer från en ägd källa och inkluderar ett lämpligt verifieringsdatum.

FAQ

Frågorna nedan löser de gränser som oftast får en anpassad lista att glida mot punkter, kort eller tabeller.

Vad är en anpassad lista?

En anpassad lista är en återkommande samling vars objekt delar ett litet, namngivet fältschema, såsom titel, sammanfattning, metadata och länk. Den placerar sig mellan en enkel punktlista och ett visuellt oberoende kortrutnät.

Hur många objekt bör en anpassad lista innehålla?

Använd tre till tolv objekt som normalt redaktionellt spann. Två objekt kräver vanligtvis brödtext eller en sida-vid-sida-komponent. Fler än tolv kräver användbar gruppering, filtrering, paginering eller ett katalogmönster; den grupperade varianten får inte överstiga tjugofyra objekt.

När bör en anpassad lista bli en tabell?

Använd en tabell när läsare måste jämföra de flesta objekt över samma tre eller fler fält, särskilt numeriska värden, datum, statusar eller ja-eller-nej-funktioner. Behåll en lista när sammanfattningar och vidarelänkar är viktigare än jämförelse mellan objekt.

Behöver en anpassad lista ItemList-schema?

Nej. Lägg till ItemList endast när samlingen är meningsfull och avgränsad, varje uppmärkt objekt är synligt och eventuell position återspeglar en deklarerad ordning. Vanliga navigerings-, smygtitt- och relaterat-innehållslistor behöver vanligtvis semantisk HTML snarare än ett speciellt schema.

Kan objekt ha olika fält?

Endast valfria fält som definieras av det delade schemat får utelämnas. Låt inte skribenter uppfinna fält per objekt. Om flera objekt behöver en annan informationsmodell, dela upp dem i en annan lista eller välj ett mer lämpligt element.