Egendefinerte oppføringer: Element-skjema, begrensninger og eksempler

En egendefinert oppføring er en gjentakbar samling av elementer som deler et lite feltskjema. Hvert element kan ha en tittel, et kort sammendrag, én eller to metadataverdier og en destinasjonslenke. Denne strukturen gir leserne mer kontekst enn en punktliste uten å gjøre hvert element til et frittstående produktkort .

Eksempel — støttede eksportformater

• CSV — Tabellrader for regnearkanalyse. Best for flate poster. Tilgjengelighet: Alle abonnement. Handling: Se CSV-eksportoppsett.
• JSON — Nøstede poster for applikasjoner og datapipelines. Best for å bevare feltrelasjoner. Tilgjengelighet: Pro og Enterprise. Handling: Les JSON-referansen.
• Google Sheets — Et synkronisert regneark for team som gjennomgår data uten kode. Tilgjengelighet: Pro og Enterprise. Handling: Koble til Google Sheets.

Det gjengitte elementet bør ikke være en dekorativ versjon av disse kulepunktene. Det bør vise én samling som inneholder tre elementer, og hvert element bør ha de samme title-, summary-, bestFor-, availability- og url-feltene. Feltmodellen — ikke kanten, ikonet eller kolonneantallet — er det som gjør oppføringen egendefinert.

Hvorfor dette elementet er viktig

Vanlig brødtekst skjuler gjentakelser. Hvis seks integrasjoner beskrives i seks avsnitt, må en leser oppdage at hvert avsnitt inneholder et systemnavn, støttet handling, kontokrav og oppsettslenke. En egendefinert oppføring navngir disse gjentakende delene gjennom ett element-skjema: et definert sett med felt som brukes av hvert element. Lesere lærer mønsteret etter den første oppføringen og kan skanne senere oppføringer på en forutsigbar måte.

Denne konsistensen forbedrer også gjenbruk. Et innholdsstyringssystem kan validere obligatoriske felt, en mal kan gjengi hvert element uten side-spesifikk markering, og en nedstrømsapplikasjon kan transformere samme kilde til en kompakt mobilliste eller et søkbart katalogoppsett. Søkemotorer og KI-systemer mottar diskrete elementgrenser i stedet for å måtte gjette hvor én enhet slutter og en annen begynner.

Elementet er viktig fordi det er et vanlig gap mellom to gyldige strukturer. Kulepunkter fungerer når hvert element er én kompakt påstand. Kort fungerer når hvert element trenger uavhengige bilder, flere kommersielle attributter, en fremtredende handling, eller nok visuell vekt til å stå alene. Mange samlinger trenger ingen av ytterpunktene. En integrasjonsliste kan kreve et navn, et sammendrag på to setninger, en status og en lenke. Å flate dette ut til kulepunkter mister feltene; å blåse det opp til kort kaster bort plass og får en referansesamling til å virke salgsfremmende.

Struktur er ikke en unnskyldning for å gjøre hver samling skreddersydd. Et engangsdesign gir inkonsistente felt, sortering, tilgjengelighet og responsiv oppførsel. Skrivereglene for elementer gjelder derfor først: identifiser det gjentatte informasjonsbehovet, registrer det minste skjemaet som tilfredsstiller det, og hold innholdet portabelt på tvers av gjengivere.

Når du skal bruke det

Bruk en egendefinert oppføring når alle elementene svarer på samme leserspørsmål, hvert trenger to til fem synlige felt, og hovedoppgaven er å inspisere eller navigere i stedet for å sammenligne alle verdier side om side. Egnede samlinger inkluderer integrasjoner, tjenesteområder, støttede formater, nedlastbare ressurser, partnertyper, teamansvar, katalogforhåndsvisninger og grupperte funksjoner.

Kjør fire tester før du velger det:

1. Gjentakbarhet: Kan hvert element bruke de samme obligatoriske feltene uten å finne opp unntak?
2. Uavhengighet: Kan en leser forstå ett element uten å lese det forrige?
3. Skannbarhet: Er mønsteret med tittel-pluss-sammendrag mer nyttig enn et rutenett av sammenlignbare verdier?
4. Handling: Trenger hvert element ikke mer enn én primær destinasjon?

Hvis svarene er ja, er en egendefinert oppføring sannsynligvis passende. Bruk et annet element når samlingen mislykkes i en av disse testene:

• Bruk en punktliste når elementene bare trenger én parallell setning og ingen separate metadata.
• Bruk en sammenligningstabell når lesere må skanne de samme kriteriene vertikalt eller horisontalt på tvers av alternativer.
• Bruk et produktkort når bilde, pris, tilbud, vurdering, tilgjengelighet og kjøpshandling gjør hvert element til en betydelig kommersiell enhet.
• Bruk en trinnliste når plassering uttrykker rekkefølge i stedet for redaksjonell sortering.
• Bruk en ordliste eller definisjonsstruktur når hver oppføring i bunn og grunn er et begrep–definisjonspar.
• Bruk overskrifter og brødtekst når elementer krever forskjellige felt eller mer enn omtrent 100 ord forklaring hver.

Ikke velg en egendefinert oppføring bare fordi designet krever gjentatte bokser. Bevis først at en stabil innholdsmodell eksisterer. Hvis element én har en pris og element to har en forfatterbiografi mens element tre har en nedlastingsstørrelse, er de ikke én samling selv om CSS kan justere dem.

Hvor du skal plassere den

Plasser oppføringen etter at siden definerer samlingen og dens inkluderingsregel. «Støttede integrasjoner» er en etikett; «Disse integrasjonene kan sende reviderte sider til et eget rapporteringsområde» forteller leserne hva medlemskap betyr. Når utvelgelse eller testing har skapt settet, forklar metoden før det første elementet slik at oppføringen ikke antyder ufullstendighet eller rangering.

Plasser samlingen nær beslutnings- eller navigasjonsoppgaven den tjener. En integrasjonsside bør introdusere tilkoblingen og dens resultat før den lister opp støttede arbeidsflyter. En katalog bør forklare omfang og filtre før den viser oppføringer. En listeartikkel bør angi evalueringsmetoden før den presenterer utvalgte elementer.

Ikke avbryt en oppføring med brødtekst, annonser, handlingsfremmende uttrykk eller urelaterte skjermbilder. Elementgrenser må forbli sammenhengende. Plasser kvalifikasjoner innenfor det berørte elementets definerte metadata, eller forklar en samlingsomfattende betingelse før eller etter hele listen. Hvis mer enn tolv elementer er nødvendig, grupper dem under meningsfulle underoverskrifter, legg til filtrering, eller led lesere til en katalogindeks . Ikke lag én endeløs visuell stabel.

Anatomi

En komplett egendefinert oppføring har disse områdene:

1. Samlingstittel: navngir settet på leserens språk, ikke komponentens interne navn.
2. Omfangserklæring: definerer hva som kvalifiserer for inkludering og om samlingen er komplett, utvalgt eller illustrerende.
3. Listebeholder: etablerer én semantisk samling og eier antallet elementer.
4. Elementtittel: identifiserer entydig entiteten, ressursen, egenskapen eller alternativet.
5. Elementsammendrag: forklarer elementets relevante forskjell eller bruk i én eller to setninger.
6. Metadatagruppe: viser null til tre merkede fakta fra det registrerte skjemaet.
7. Primær handling: lenker til én tydelig destinasjon med beskrivende ankertekst.
8. Elementgrense: bruker mellomrom, en linje eller diskret flatebehandling uten å koble elementet fra samlingen.

Omfangserklæringen forhindrer en vanlig nøyaktighetsfeil. «Tilgjengelige integrasjoner» antyder fullstendighet; «Vanlige rapporteringsintegrasjoner» erklærer et utvalg. Forfatteren må velge ordlyden kildedataene kan støtte.

Designeksempler

Gjengiveren kan variere tetthet, men må bevare feltrekkefølge, semantisk listestruktur og en forutsigbar lesesekvens.

Stablet redaksjonell oppføring

Bruk det stablede standarddesignet når sammendrag bærer mesteparten av verdien. Hold tittel først, sammendrag andre, metadata tredje og handling sist. En subtil skiller er tilstrekkelig; hvert element trenger ikke et opphøyd kort.

Kompakt katalogforhåndsvisning

Bruk en kompakt variant når titler og én metadataverdi lar leserne velge en destinasjon. Sammendraget kan være kortere, men etiketter må forbli synlige. Erstatt aldri en meningsfull status med en uforklarlig farget prikk.

Gruppert oppføring

Bruk grupper når én stabil klassifisering reduserer en samling på åtte til tjuefire elementer til seksjoner. Gruppeoverskrifter må beskrive en ekte taksonomi som eksporttype eller tjenesteregion. Ikke grupper bare for å oppnå like kolonner.

Smal visning

Ved smale bredder, behold kilde-rekkefølgen og stable metadata under sammendraget. Ikke skjul felt som fortsatt er relevante, krymp tekst for å opprettholde kolonner, eller flytt handlinger bort fra elementet sitt.

Parametere

Skjemaet nedenfor er bevisst begrenset. Et felt blir en del av komponenten bare når det er nyttig på tvers av samlingen, ikke fordi ett element tilfeldigvis har data for det.

Tre elementer er minimum fordi et par vanligvis er tydeligere som brødtekst, en to-kolonne-sammenligning eller to substansielle kort. Tolv er normal maksimum fordi skanning av en lang ufiltrert stabel blir ineffektiv. Det grupperte taket på tjuefire er en sikkerhetsbarriere, ikke et mål; større eller hyppig endrede sett trenger en katalog, søk, paginering eller en datadrevet applikasjon.

Velg ordered=true bare når den synlige rekkefølgen uttrykker en erklært rangering. Redaksjonell bekvemmelighet, alfabetisk sortering eller datakilde-rekkefølge skaper ikke en rangering. Når rangering er reell, oppgi metodikken og behold posisjonen i både synlig utdata og eventuelle strukturerte data.

Syntaks og kodeeksempler

Den portable direktivet definerer den forfatteravtalte kontrakten. Plattformadaptere kan lagre dataene annerledes, men de må bevare de samme feltnavnene, elementrekkefølgen, valgfriheten og 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
:::
:::

Eksempel-URLene beskriver kun den portable syntaksen; en implementering må erstatte dem med verifiserte destinasjoner. Ikke publiser en eksempelsti som en levende lenke bare fordi den vises i en kodeblokk.

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 >}}

Denne notasjonen spesifiserer en fremtidig eller prosjektnivå-adapter; den autoriserer ikke opprettelse av en side-lokal shortcode. Alle parametere er navngitt. Inntil en adapter finnes, gjengi samlingen som semantisk HTML med <ul> og <li> eller som native Markdown i stedet for å stille droppe feltrelasjonene.

WordPress-blokk

<!-- 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 -->

Native blokker er et akseptabelt alternativ når de produserer én liste, ett listeelement per oppføring, ekte overskrifter, en definisjonsliste for merkede metadata og beskrivende lenker. En generisk Columns-blokk er ikke en pålitelig erstatning fordi kilde-rekkefølge og elementgruppering ofte brytes på mobil.

Eksempler

Bra: en konsistent ressursoppføring

Migreringsressurser

Disse ressursene støtter team som forbereder, utfører og validerer en nettstedmigrering.

1. Omdirigeringskartleggingsark — Registrerer hver gammel URL, dens godkjente destinasjon, eier og valideringsstatus. Format: Regneark. Fase: Planlegging. Handling: Last ned omdirigeringsarket.
2. Lanseringsdagsvalideringsskript — Sjekker svarkoder, omdirigeringskjeder, kanoniske mål og indekserbarhet for det migrerte URL-settet. Format: Skript. Fase: Lansering. Handling: Se gjennom valideringsoppsett.
3. Etter-lansering overvåkingsvisning — Sporer gjennomsøkingsfeil og uventede trafikkendringer etter distribusjon. Format: Dashbord. Fase: Overvåking. Handling: Konfigurer overvåkingsvisningen.

Dette fungerer fordi hvert element bruker de samme fem feltene: tittel, sammendrag, format, fase og handling. Omfanget forklarer hvorfor ressursene hører sammen. Nummereringen reflekterer den erklærte migreringsfasen, ikke et krav om at den første ressursen er «best». Hver handling identifiserer sin destinasjon i stedet for å gjenta «Les mer».

Dårlig: bokser uten en felles modell

Nyttige ting

• SEO-sjekkliste — Vår favorittguide. Oppdatert nylig. Les mer.
• Premium-revisjon — €499, inkluderer en samtale og rapport. Fem stjerner. Kjøp nå.
• Viktor — Teknisk leder basert i Bratislava, tilgjengelig på tirsdager.
• API-dokumentasjon — Autentisering, begrensninger, feil, eksempler, SDK-er, endringslogg, status, støtte og tjue flere emner.

Dette mislykkes før visuell design i det hele tatt begynner. Settet blander en ressurs, tjeneste, person og dokumentasjonsområde. Felt endrer seg på hvert element, «nylig» har ingen dato, vurderingen mangler kilde og skala, og elementdybden spenner fra et fragment til en seksjonsoversikt. Del innholdet etter formål, og velg deretter det registrerte elementet for hver samling. En kant rundt inkonsistente data skaper ikke en egendefinert oppføring.

Dårlig: en oppføring som burde være en tabell

Anta at seks abonnementer hver viser månedspris, årspris, brukergrense, lagring, supportrespons og SSO-tilgjengelighet. Lesere må sammenligne de samme seks verdiene på tvers av alle abonnementene. En oppføring ville tvinge dem til å huske abonnement én mens de blar gjennom abonnement seks. Bruk en sammenligningstabell fordi oppgaven er sammenligning på tvers av elementer. Hvis hvert abonnement også trenger en posisjoneringserklæring og kjøpshandling, plasser disse utenfor eller ved siden av tabellen ved hjelp av sidens registrerte abonnementskomponent; ikke dupliser motstridende verdier i to kilder.

Skjemamerking og tilgjengelighet

Gjengi samlingen med native listesemantikk. Bruk <ul> når elementrekkefølgen ikke har noen betydning og <ol> når siden erklærer en ekte sekvens eller rangering. Hver oppføring hører hjemme i én <li>. Inni den, bruk en ekte overskrift på riktig dokumentnivå, et avsnitt for sammendraget, og <dl>, <dt> og <dd> for merkede metadata. En skjermleser bør møte elementtittelen før dens beskrivelse, fakta og handling.

Ikke gjør hele elementet til en overdimensjonert lenke når det inneholder en annen kontroll eller flere tekstområder. Gi den primære lenken en beskrivende etikett som «Se CSV-eksportoppsett». Hvis et strekk-lenke-mønster brukes, må fokusindikatoren forbli synlig og dets tilgjengelige navn må fortsatt beskrive destinasjonen. Ikoner trenger alternativ tekst bare når de formidler informasjon som ikke allerede finnes i teksten. Dekorative ikoner bør skjules for hjelpeteknologi.

Visuell rekkefølge og kilde-rekkefølge må samsvare. Et flerkolonners skrivebordsoppsett må kollapse uten å lese element én, element tre, element fem, deretter element to. Metadataetiketter kan ikke forsvinne bare fordi gjentatte verdier visuelt ser justerte ut; «Enterprise» alene forteller ikke en ikke-visuell leser om det beskriver tilgjengelighet, målgruppe eller støtte.

ItemList strukturerte data er valgfrie, ikke en standard stilingskrok. Bruk det når den synlige samlingen er en meningsfull avgrenset liste og siden drar nytte av å identifisere den samlingen. Kartlegg hver synlig oppføring til itemListElement. Inkluder position bare for en ekte sortert liste, og sørg for at navn, URL-er og antall samsvarer med det gjengitte innholdet. Ikke merk opp navigasjonsmenyer, vilkårlige funksjonsteasere eller et delvis sett som om de var en komplett rangert liste. Når oppføringer er identifiserbare enheter som organisasjoner eller programvareapplikasjoner, bruk den mest spesifikke kvalifiserte typen bare når siden leverer og verifiserer de nødvendige identitetsdataene.

Skriveregler

1. Forklar medlemskap før du presenterer medlemmer. Lesere trenger å vite om settet er komplett, utvalgt, sponset, rangert eller illustrerende før de tolker utelatelse eller rekkefølge. Angi inkluderingsregelen i omfangssetningen.
2. Definer ett element-skjema før du utformer elementer. Konsistente felt lar lesere lære ett skannemønster og lar validering fange opp manglende innhold. Registrer obligatoriske og valgfrie felt før forfattere fyller samlingen.
3. Hold obligatoriske felt virkelig universelle. Et nominelt obligatorisk felt som forfattere fyller med «N/A» i halvparten av oppføringene, er feil felt eller bevis på at samlingen inneholder forskjellige elementtyper.
4. Begrens synlige metadata til tre par. Flere felt forskyver oppgaven mot sammenligning og gjør hver rad vanskelig å skanne. Flytt sekundære fakta til destinasjonssiden eller bruk en tabell.
5. Skriv sammendrag for forskjell, ikke gjentakelse. Tittelen navngir allerede elementet. Bruk sammendraget til å forklare dets relevante evne, målgruppe, begrensning eller rolle.
6. Bruk parallelle etiketter og enheter. Ikke veksle mellom «Plan», «Tilgjengelig på» og «Nivå» for samme konsept. Normaliser datoer, valutaer, enheter og statusvokabular før gjengivelse.
7. Gi hvert element én primær handling. Konkurrerende knapper gjør en referanseliste om til et kortnett og skjuler den tiltenkte neste handlingen. Plasser sekundære destinasjoner på detaljsiden.
8. Erklær meningsfull rekkefølge. Alfabetisk, kronologisk, rangert, redaksjonell og kildesystem-rekkefølge skaper forskjellige forventninger. Navngi rekkefølgen når den kan påvirke tolkning.
9. Sett minimums- og maksimumsantall. Bruk tre til tolv elementer normalt, med opptil tjuefire bare i nyttige grupper. Bytt mønster når samlingen faller utenfor disse grensene.
10. Oppretthold én sannhetskilde. Hvis pris, status, tilgjengelighet eller et annet ustabilt felt vises andre steder, populér hver representasjon fra samme eide kilde og vis en verifiseringsdato der det er nødvendig.

Innholdstyper som bruker det

• En Listeartikkelguide bruker en egendefinert oppføring når hver utvalgte oppføring trenger samme sammendrag, egnethet, begrensning og videre lenke, men ikke en tett sammenligningsmatrise.
• En Best-X-for-Y-side kan bruke den for målgruppespesifikke anbefalinger etter å ha forklart evalueringsmetoden. Rangering må være eksplisitt i stedet for å være antydet av visuell rekkefølge.
• En Alternativer-til-X-side kan presentere erstatningsalternativer med konsistente «best for»-, avveinings- og detaljlenkefelt før en mer avgrenset sammenligning.
• En Kategoriside bruker en kompakt eller gruppert oppføring for å forhåndsvise et håndterbart sett med underliggende produkter eller tjenester når filtrering ennå ikke er nødvendig.
• En katalogindeks bruker elementet bare for en forhåndsvisning eller en liten, stabil katalog. Store enhetssett trenger søk, filtre, paginering og en databasert katalog-grensesnitt.
• En Bedriftsprofil kan liste bekreftede forretningsenheter, sertifiseringer eller steder når hver oppføring deler de samme feltene.
• En Leverandørprofil kan liste støttede tjenester, regioner eller engasjementsmodeller uten å gjøre profilen om til et produktnett.
• En Integrasjonsside kan liste støttede arbeidsflyter, dataobjekter, triggere eller destinasjoner ved hjelp av et forutsigbart evne-og-krav-skjema.

Tilstedeværelsen av en samling krever ikke dette elementet. Bruk det bare når den egendefinerte feltmodellen forbedrer innhenting eller navigasjon. Et kort sett med forutsetninger hører fortsatt hjemme i kulepunkter, og en matrise av egenskaper hører fortsatt hjemme i en tabell.

QA-sjekkliste

• Samlingen har en tittel og en omfangssetning som definerer inkludering.
• Hvert element representerer samme type enhet, ressurs, evne eller alternativ.
• Obligatoriske og valgfrie felt er dokumentert før innholdsregistrering.
• Hvert element har en unik stabil ID, tittel og et sammendrag på 12–60 ord.
• Ingen element finner opp et felt som mangler fra det registrerte skjemaet.
• Samlingen inneholder 3–12 elementer, eller begrunnede grupper med maksimalt 24 totalt.
• Elementer har ikke mer enn tre synlige metadatapar og én primær handling.
• Etiketter, enheter, statusverdier, datoer og handlingsordlyd er konsistente.
• Rekkefølgen er erklært når den antyder rangering, kronologi eller prioritet.
• En tabell ble valgt i stedet når sammenligning på tvers av elementer er hovedoppgaven.
• Resultatet bruker én semantisk <ul> eller <ol> med én <li> per element.
• Overskrifter følger sidehierarkiet og metadata bruker term–beskrivelse-semantikk.
• Tastaturfokus er synlig og lenker beskriver sine destinasjoner.
• Kilde-rekkefølge samsvarer med visuell rekkefølge på skjermbord og mobilbredder.
• ItemList-markering, hvis til stede, samsvarer med synlige elementer, rekkefølge, antall, navn og URL-er.
• Ustabile verdier kommer fra en eid kilde og inkluderer en passende verifiseringsdato.

FAQ

Spørsmålene nedenfor løser grensene som oftest får en egendefinert oppføring til å gli over i kulepunkter, kort eller tabeller.

Hva er en egendefinert oppføring?

En egendefinert oppføring er en gjentakbar samling der elementene deler et lite, navngitt feltskjema, som tittel, sammendrag, metadata og lenke. Den befinner seg mellom en enkel punktliste og et visuelt uavhengig kortnett.

Hvor mange elementer bør en egendefinert oppføring inneholde?

Bruk tre til tolv elementer som normalt redaksjonelt spenn. To elementer trenger vanligvis brødtekst eller en side-ved-side-komponent. Mer enn tolv trenger nyttig gruppering, filtrering, paginering eller en katalogstruktur; den grupperte varianten må ikke overstige tjuefire elementer.

Når bør en egendefinert oppføring bli en tabell?

Bruk en tabell når lesere må sammenligne de fleste elementene på tvers av de samme tre eller flere feltene, spesielt numeriske verdier, datoer, statusverdier eller ja/nei-egenskaper. Behold en oppføring når sammendrag og videre lenker betyr mer enn sammenligning på tvers av elementer.

Trenger en egendefinert oppføring ItemList-skjema?

Nei. Legg til ItemList bare når samlingen er meningsfull og avgrenset, hvert markerte element er synlig, og eventuell posisjon reflekterer en erklært rekkefølge. Vanlige navigasjons-, teaser- og relatert-innholdsoppføringer trenger vanligvis semantisk HTML i stedet for spesialskjema.

Kan elementer ha forskjellige felt?

Bare valgfrie felt definert av det felles skjemaet kan være fraværende. Ikke la forfattere finne opp felt per element. Hvis flere elementer trenger en annen informasjonsmodell, del dem opp i en annen oppføring eller velg et mer passende element.