Tilpasset liste: Elementskema, begrænsninger og eksempler

En tilpasset liste er en gentagelig samling af elementer, der deler et lille feltskema. Hvert element kan have en titel, et kortfattet resumé, en eller to metadataværdier og et destinationslink. Denne struktur giver læserne mere kontekst end en punktopstilling uden at få hvert element til at opføre sig som et selvstændigt produktkort .

Eksempel — understøttede eksportformater

• CSV — Tabellære rækker til regnearksanalyse. Bedst til flade poster. Tilgængelighed: Alle abonnementer. Handling: Se CSV-eksportopsætning.
• JSON — Indlejrede poster til applikationer og datapipelines. Bedst til at bevare feltrelationer. Tilgængelighed: Pro og Enterprise. Handling: Læs JSON-reference.
• Google Sheets — Et synkroniseret regneark til teams, der gennemgår data uden kode. Tilgængelighed: Pro og Enterprise. Handling: Tilslut Google Sheets.

Det gengivne element bør ikke være en dekorativ version af disse punkter. Det bør præsentere én samling med tre elementer, og hvert element bør bevare de samme title, summary, bestFor, availability og url-felter. Det er feltmodellen — ikke kantlinjen, ikonet eller kolonneantallet — der gør listen tilpasset.

Hvorfor dette element er vigtigt

Almindelig brødtekst skjuler gentagelser. Hvis seks integrationer beskrives i seks afsnit, må en læser opdage, at hvert afsnit indeholder et systemnavn, understøttet handling, konto krav og opsætningslink. En tilpasset liste navngiver disse tilbagevendende dele gennem ét elementskema: et defineret sæt felter, der bruges af hvert element. Læsere lærer mønsteret efter den første post og kan efterfølgende scanne senere poster forudsigeligt.

Denne konsistens forbedrer også genbrug. Et content management-system kan validere påkrævede felter, en skabelon kan gengive hvert element uden sidespecifik markup, og en downstream-applikation kan omdanne samme kilde til en kompakt mobil liste eller et søgbart katalog. Søgemaskiner og AI-systemer modtager diskrete elementafgrænsninger frem for at skulle gætte, hvor én enhed slutter, og en anden begynder.

Elementet er vigtigt, fordi der er et almindeligt hul mellem to gyldige strukturer. Punktopstillinger fungerer, når hvert element er én kompakt erklæring. Kort fungerer, når hvert element har brug for selvstændige billeder, flere kommercielle attributter, en fremtrædende handling eller nok visuel vægt til at stå alene. Mange samlinger har brug for ingen af yderpunkterne. En integrationsliste kan kræve et navn, en to-sætnings funktionsoversigt, en status og et link. At flade det ud til punkter mister felterne; at oppuste det til kort spilder plads og får en referencesamling til at føles salgsfremmende.

Struktur er ikke en undskyldning for at gøre hver samling skræddersyet. Et engangsdesign skaber inkonsistente felter, sortering, tilgængelighed og responsiv adfærd. Skrivereglerne for elementer gælder derfor først: identificér det gentagne informationsbehov, registrér det mindste skema, der opfylder det, og hold indholdet bærbart på tværs af gengivere.

Hvornår skal det bruges

Brug en tilpasset liste, når alle elementer besvarer det samme læserspørgsmål, hvert har brug for to til fem synlige felter, og den primære opgave er at inspicere eller navigere frem for at sammenligne alle værdier side om side. Egnede samlinger inkluderer integrationer, serviceområder, understøttede formater, resourcedownloads, partnertyper, teamansvar, katalogforhåndsvisninger og grupperede funktioner.

Kør fire tests, før du vælger det:

1. Gentagelighed: Kan hvert element bruge de samme påkrævede felter uden at opfinde undtagelser?
2. Uafhængighed: Kan en læser forstå ét element uden at læse det foregående element?
3. Skanning: Er titel-plus-resumé-mønsteret mere nyttigt end et gitter af sammenlignelige værdier?
4. Handling: Har hvert element brug for højst én primær destination?

Hvis svarene er ja, er en tilpasset liste sandsynligvis passende. Brug et andet element, når samlingen fejler en af disse test:

• Brug en punktopstilling, når elementer kun har brug for én parallel sætning og ingen separate metadata.
• Brug en sammenligningstabel , når læsere skal scanne de samme kriterier lodret eller vandret på tværs af alternativer.
• Brug et produktkort, når billede, pris, tilbud, vurdering, tilgængelighed og købshandling gør hvert element til en væsentlig kommerciel enhed.
• Brug en trinliste, når placering udtrykker rækkefølge frem for redaktionel sortering.
• Brug en ordliste eller definitionsmønster, når hver post grundlæggende er et term-definition-par.
• Brug overskrifter og brødtekst, når elementer kræver forskellige felter eller mere end omkring 100 ord forklaring hver.

Vælg ikke en tilpasset liste blot fordi designet kalder på gentagne bokse. Bevis først, at der findes en stabil indholdsmodel. Hvis element ét har en pris og element to har en forfatterbiografi, mens element tre har en downloadstørrelse, er de ikke én samling, selvom CSS kan justere dem.

Hvor skal den placeres

Placer listen, efter at siden definerer samlingen og dens inklusionsregel. “Understøttede integrationer” er en etiket; “Disse integrationer kan sende reviderede sider til et ejet rapporteringsarbejdsområde” fortæller læserne, hvad medlemskab betyder. Når udvælgelse eller test har skabt sættet, forklar metoden før det første element, så listen ikke antyder uunderstøttet fuldstændighed eller rangering.

Placer samlingen tæt på den beslutnings- eller navigationsopgave, den betjener. En integrationsside bør introducere forbindelsen og dens resultat, før den oplister understøttede arbejdsgange. Et katalog bør forklare omfang og filtre, før det viser poster. En listeartikel bør angive sin evalueringsmetode, før den præsenterer udvalgte elementer.

Afbryd ikke en liste med brødtekst, annoncer, handlingsopfordringer eller ikke-relaterede skærmbilleder. Elementgrænser skal forblive fortløbende. Placer kvalifikationer inden for det påvirkede elements definerede metadata, eller forklar en samlingsdækkende betingelse før eller efter hele listen. Hvis mere end tolv elementer er nødvendige, gruppér dem under meningsfulde underoverskrifter, tilføj filtrering, eller led læsere til et Katalogindeks . Skab ikke én uendelig visuel stabel.

Anatomi

En komplet tilpasset liste har disse regioner:

1. Samlingstitel: navngiver sættet på læserens sprog, ikke komponentens interne navn.
2. Omfangserklæring: definerer, hvad der kvalificerer til inklusion, og om samlingen er komplet, udvalgt eller illustrativ.
3. Listebeholder: etablerer én semantisk samling og ejer elementantallet.
4. Elementtitel: identificerer unikt enheden, ressourcen, funktionen eller muligheden.
5. Elementresumé: forklarer elementets relevante forskel eller anvendelse i én eller to sætninger.
6. Metadatagruppe: viser nul til tre mærkede fakta fra det registrerede skema.
7. Primær handling: linker til én klar destination ved hjælp af beskrivende ankertekst.
8. Elementgrænse: bruger afstand, en streg eller en afdæmpet overfladebehandling uden at afkoble elementet fra sin samling.

Omfangserklæringen forhindrer en almindelig præcisionsfejl. “Tilgængelige integrationer” antyder fuldstændighed; “Almindelige rapporteringsintegrationer” erklærer en udvælgelse. Forfatteren skal vælge den formulering, kildedataene kan understøtte.

Designeksempler

Gengiveren kan variere tæthed, men den skal bevare feltordre, semantisk listestruktur og en forudsigelig læserækkefølge.

Stablet redaktionel liste

Brug det stablede standarddesign, når resuméer bærer det meste af værdien. Hold titlen først, resuméet andet, metadata tredje og handling sidst. En subtil skiller er nok; hvert element har ikke brug for et hævet kort.

Kompakt katalogforhåndsvisning

Brug en kompakt variant, når titler og én metadataværdi lader læsere vælge en destination. Resumeet kan være kortere, men etiketter skal forblive synlige. Erstat aldrig en meningsfuld status med en uforklaret farvet prik.

Grupperet liste

Brug grupper, når én stabil klassifikation reducerer en samling på otte til fireogtyve elementer til sektioner. Gruppeoverskrifter skal beskrive en ægte taksonomi såsom eksporttype eller serviceregion. Gruppér ikke blot for at opnå lige store kolonner.

Smal visning

Ved smalle bredder, bevar kildens rækkefølge og stabl metadata under resumeet. Skjul ikke felter, der forbliver relevante, formindsk ikke tekst for at bevare kolonner, eller flyt handlinger væk fra deres element.

Parametre

Skemaet nedenfor er bevidst begrænset. Et felt bliver kun en del af komponenten, når det er nyttigt på tværs af samlingen, ikke fordi ét element tilfældigvis har data til det.

Tre elementer er minimum, fordi et par normalt er tydeligere som brødtekst, en to-kolonne sammenligning eller to væsentlige kort. Tolv er det normale maksimum, fordi skanning af en lang ufiltreret stak bliver ineffektiv. Det grupperede loft på fireogtyve er en sikkerhedsbarriere, ikke et mål; større eller ofte skiftende sæt har brug for et katalog, søgning, paginering eller en datadrevet applikation.

Vælg ordered=true kun når den synlige rækkefølge udtrykker en erklæret rangering. Redaktionel bekvemmelighed, alfabetisk sortering eller datakildeorden skaber ikke en rangering. Når rangering er reel, angiv metodologien og bibehold positionen i både synlig output og eventuelle strukturerede data.

Syntaks og kodeeksempler

Den bærbare direktiv definerer den forfattedes kontrakt. Platformadaptere kan gemme data anderledes, men de skal bevare de samme feltnavne, elementrækkefølge, valgfrihed og synlige output.

Bærbart Markdown-direktiv

:::custom-listing{title="Eksportformater" variant=stacked}
Disse er de formater, der er tilgængelige til at sende færdige revisionsposter til et andet arbejdsområde.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Tabellære rækker til regnearksanalyse og fladfilindlæsning.

- Bedst til: Regnearksanalyse
- Tilgængelighed: Alle abonnementer
- Handling: Se CSV-eksportopsætning
:::

:::item{id=json title="JSON" url="/docs/exports/json/"}
Indlejrede poster, der bevarer relationer til applikationer og datapipelines.

- Bedst til: Automatiserede arbejdsgange
- Tilgængelighed: Pro og Enterprise
- Handling: Læs JSON-reference
:::

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
Et synkroniseret regneark til teams, der gennemgår data uden kode.

- Bedst til: Fælles gennemgang
- Tilgængelighed: Pro og Enterprise
- Handling: Tilslut Google Sheets
:::
:::

Eksempel-URL’erne beskriver kun den bærbare syntaks; en implementering skal erstatte dem med verificerede destinationer. Publicér ikke en eksempelsti som et aktivt link blot fordi den optræder i en kodeblok.

Hugo-adapter

{{< custom-listing title="Eksportformater" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="Se CSV-eksportopsætning" >}}
  Tabellære rækker til regnearksanalyse og fladfilindlæsning.

  **Bedst til:** Regnearksanalyse  
  **Tilgængelighed:** Alle abonnementer
  {{< /custom-listing-item >}}
{{< /custom-listing >}}

Denne notation specificerer en fremtidig eller projektniveau-adapter; den giver ikke tilladelse til at oprette en side-lokal shortcode. Alle parametre er navngivne. Indtil en adapter eksisterer, gengiv samlingen som semantisk HTML med <ul> og <li> eller som indbygget Markdown frem for stille og roligt at droppe feltrelationerne.

WordPress-blok

<!-- wp:amicited/custom-listing {"title":"Eksportformater","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Tabellære rækker til regnearksanalyse og fladfilindlæsning.</p>
    <dl><dt>Bedst til</dt><dd>Regnearksanalyse</dd><dt>Tilgængelighed</dt><dd>Alle abonnementer</dd></dl>
    <a href="/docs/exports/csv/">Se CSV-eksportopsætning</a>
  </li>
</ul>
<!-- /wp:amicited/custom-listing -->

Indbyggede blokke er en acceptabel fallback, når de producerer én liste, ét listeelement pr. post, rigtige overskrifter, en definitionsliste til mærkede metadata og beskrivende links. En generisk Columns-blok er ikke en pålidelig erstatning, fordi kildens rækkefølge og elementgruppering ofte går i stykker på mobil.

Eksempler

Godt: en konsistent ressourceoversigt

Migrationsressourcer

Disse ressourcer understøtter teams, der forbereder, udfører og validerer en webstedsmigration.

1. Redirect-kortlægningsregneark — Registrerer hver gammel URL, dens godkendte destination, ejer og valideringsstatus. Format: Regneark. Fase: Planlægning. Handling: Download redirect-regnearket.
2. Valideringsscript til lanceringsdagen — Tjekker svarkoder, redirect-kæder, kanoniske mål og indekserbarhed for det migrerede URL-sæt. Format: Script. Fase: Lancering. Handling: Gennemgå valideringsopsætning.
3. Overvågningsvisning efter lancering — Sporer crawlf ejl og uventede trafikændringer efter implementering. Format: Dashboard. Fase: Overvågning. Handling: Konfigurér overvågningsvisningen.

Dette fungerer, fordi hvert element bruger de samme fem felter: titel, resumé, format, fase og handling. Omfanget forklarer, hvorfor ressourcerne hører sammen. Nummerering afspejler den erklærede migrationsfase, ikke en påstand om, at den første ressource er “bedst.” Hver handling identificerer sin destination i stedet for at gentage “Læs mere.”

Dårligt: bokse uden en fælles model

Nyttige ting

• SEO-tjekliste — Vores foretrukne guide. Opdateret for nylig. Læs mere.
• Premium-audit — €499, inkluderer et opkald og rapport. Fem stjerner. Køb nu.
• Viktor — Teknisk leder baseret i Bratislava, tilgængelig om tirsdagen.
• API-dokumentation — Autentifikation, begrænsninger, fejl, eksempler, SDK’er, ændringslog, status, support og tyve yderligere emner.

Dette fejler allerede før visuelt design påbegyndes. Sættet blander en ressource, en tjeneste, en person og et dokumentationsområde. Felter ændrer sig på hvert element, “for nylig” har ingen dato, vurderingen mangler en kilde og skala, og elementdybden spænder fra et fragment til en sektionsoversigt. Opdel indholdet efter formål, vælg derefter det registrerede element for hver samling. En kantlinje omkring inkonsistente data skaber ikke en tilpasset liste.

Dårligt: en liste, der burde være en tabel

Antag seks abonnementer, der hver viser månedlig pris, årlig pris, brugerbegrænsning, lagerplads, supportrespons og SSO-tilgængelighed. Læsere har brug for at sammenligne de samme seks værdier på tværs af alle abonnementer. En liste ville tvinge dem til at huske abonnement ét mens de scroller gennem abonnement seks. Brug en sammenligningstabel, fordi opgaven er evaluering på tværs af elementer. Hvis hvert abonnement også har brug for en positioneringserklæring og købshandling, placer disse uden for eller ved siden af tabellen ved hjælp af sidens registrerede abonnementskomponent; dupliker ikke modstridende værdier i to kilder.

Skemamarkup og tilgængelighed

Gengiv samlingen med indbyggede listesemantikker. Brug <ul> når elementrækkefølge ikke har nogen betydning, og <ol> når siden erklærer en ægte sekvens eller rangering. Hver post hører til i én <li>. Inden i den, brug en rigtig overskrift på det korrekte dokumentniveau, et afsnit til resumeet og <dl>, <dt> og <dd> til mærkede metadata. En skærmlæser bør støde på elementtitlen før dens beskrivelse, fakta og handling.

Gør ikke hele elementet til et overdimensioneret link, når det indeholder en anden kontrol eller flere tekstområder. Giv det primære link en beskrivende etiket såsom “Se CSV-eksportopsætning.” Hvis et strakt-link-mønster anvendes, skal dets fokusindikator forblive synlig, og dets tilgængelige navn skal stadig beskrive destinationen. Ikoner har kun brug for alternativ tekst, når de kommunikerer information, der ikke allerede findes i teksten. Dekorative ikoner bør skjules for hjælpeteknologi.

Visuel orden og kildeorden skal matche. Et multikolonne desktop-layout skal kunne kollapse uden at læse element ét, element tre, element fem og derefter element to. Metadataetiketter kan ikke forsvinde bare fordi gentagne værdier visuelt fremstår justeret; “Enterprise” alene fortæller ikke en ikke-visuel læser, om det beskriver tilgængelighed, målgruppe eller support.

ItemList-strukturerede data er valgfrie, ikke en standard stylingkrog. Brug det, når den synlige samling er en meningsfuld afgrænset liste, og siden har gavn af at identificere den samling. Kortlæg hver synlig post til itemListElement. Inkludér position kun for en ægte ordnet liste, og sørg for, at navne, URL’er og antal matcher det gengivne indhold. Markér ikke navigationsmenuer, vilkårlige funktionsteasere eller et delvist sæt, som om de var en komplet rangeret liste. Når poster er identificerbare enheder såsom organisationer eller softwareapplikationer, brug den mest specifikke kvalificerede type kun når siden leverer og verificerer de påkrævede identitetsdata.

Skriveregler

1. Forklar medlemskab før præsentation af medlemmer. Læsere har brug for at vide, om sættet er komplet, udvalgt, sponsoreret, rangeret eller illustrativt, før de fortolker udeladelse eller rækkefølge. Angiv inklusionsreglen i omfangssætningen.
2. Definér ét elementskema før udarbejdelse af elementer. Konsistente felter lader læsere lære ét skanningsmønster og lader validering fange manglende indhold. Registrér påkrævede og valgfrie felter, før forfattere udfylder samlingen.
3. Hold påkrævede felter virkelig universelle. Et nominelt påkrævet felt, som forfattere udfylder med “N/A” i halvdelen af posterne, er det forkerte felt eller bevis på, at samlingen indeholder forskellige elementtyper.
4. Begræns synlige metadata til tre par. Flere felter skubber opgaven i retning af sammenligning og gør hver række svær at scanne. Flyt sekundære fakta til destinationssiden eller brug en tabel.
5. Skriv resuméer for forskel, ikke gentagelse. Titlen navngiver allerede elementet. Brug resumeet til at forklare dets relevante funktion, målgruppe, begrænsning eller rolle.
6. Brug parallelle etiketter og enheder. Skift ikke mellem “Abonnement,” “Tilgængelig på” og “Niveau” for det samme koncept. Normalisér datoer, valutaer, enheder og statusordforråd før gengivelse.
7. Giv hvert element én primær handling. Konkurrerende knapper forvandler en referenceliste til et kortgitter og skjuler det tilsigtede næste trin. Placer sekundære destinationer på detaljesiden.
8. Erklær meningsfuld orden. Alfabetisk, kronologisk, rangeret, redaktionel og kildesystemsorden skaber forskellige forventninger. Navngiv ordenen, når den kan påvirke fortolkning.
9. Angiv minimums- og maksimumsantal. Brug tre til tolv elementer normalt, med op til fireogtyve kun i nyttige grupper. Skift mønster, når samlingen falder uden for disse grænser.
10. Oprethold én sandhedskilde. Hvis pris, status, tilgængelighed eller et andet flygtigt felt optræder andetsteds, udfyld hver repræsentation fra den samme ejede kilde og vis en verifikationsdato, hvor det er nødvendigt.

Posttyper, der bruger det

• En Listeartikelguide bruger en tilpasset liste, når hver valgt post har brug for det samme resumé, pasform, begrænsning og videre link, men ikke en tæt sammenligningsmatrix.
• En Bedste-X-for-Y-side kan bruge det til målgruppespecifikke anbefalinger efter at have forklaret evalueringsmetoden. Rangering skal være eksplicit frem for antydet af visuel orden.
• En Alternativer-til-X-side kan præsentere erstatningsmuligheder med konsistente “bedst til,” afvejnings- og detaljelinkfelter før en snævrere sammenligning.
• En Kategoriside bruger en kompakt eller grupperet liste til at forhåndsvise et overskueligt sæt af underliggende produkter eller tjenester, når filtrering endnu ikke er nødvendig.
• Et katalogindeks bruger elementet kun til en forhåndsvisning eller et lille, stabilt katalog. Store enhedssæt har brug for søgning, filtre, paginering og en databaseret kataloggrænseflade.
• En Virksomhedsprofil kan opliste verificerede forretningsenheder, certificeringer eller lokationer, når hver post deler de samme felter.
• En Leverandørprofil kan opliste understøttede tjenester, regioner eller engagementsmodeller uden at forvandle profilen til et produktgitter.
• En Integrationsside kan opliste understøttede arbejdsgange, dataobjekter, udløsere eller destinationer ved hjælp af et forudsigeligt funktions-og-krav-skema.

Tilstedeværelsen af en samling kræver ikke dette element. Brug det kun, når den tilpassede feltmodel forbedrer genfinding eller navigation. Et kort sæt forudsætninger hører stadig hjemme i punktopstillinger, og en matrix af funktioner hører stadig hjemme i en tabel.

QA-tjekliste

• Samlingen har en titel og en omfangssætning, der definerer inklusion.
• Hvert element repræsenterer den samme slags enhed, ressource, funktion eller mulighed.
• Påkrævede og valgfrie felter er dokumenteret før indtastning af indhold.
• Hvert element har et unikt stabilt ID, titel og 12–60-ords resumé.
• Intet element opfinder et felt, der er fraværende fra det registrerede skema.
• Samlingen indeholder 3–12 elementer eller begrundede grupper med højst 24 i alt.
• Elementer har højst tre synlige metadatapar og én primær handling.
• Etiketter, enheder, statusser, datoer og handlingsformulering er konsistente.
• Rækkefølge er erklæret, når den antyder rangering, kronologi eller prioritet.
• En tabel blev valgt i stedet, når sammenligning på tværs af elementer er hovedopgaven.
• Outputtet bruger ét semantisk <ul> eller <ol> med ét <li> pr. element.
• Overskrifter følger sidehierarkiet, og metadata bruger term–beskrivelsessemantik.
• Tastaturfokus er synligt, og links beskriver deres destinationer.
• Kildeorden matcher visuel orden ved desktop- og mobilbredder.
• ItemList-markup, hvis til stede, matcher de synlige elementer, orden, antal, navne og URL’er.
• Flygtige værdier kommer fra en ejet kilde og inkluderer en passende verifikationsdato.

FAQ

Spørgsmålene nedenfor afgrænser de grænser, der oftest får en tilpasset liste til at glide over i punkter, kort eller tabeller.

Hvad er en tilpasset liste?

En tilpasset liste er en gentagelig samling, hvis elementer deler et lille, navngivet feltskema, såsom titel, resumé, metadata og link. Den placerer sig mellem en simpel punktopstilling og et visuelt uafhængigt kortgitter.

Hvor mange elementer bør en tilpasset liste indeholde?

Brug tre til tolv elementer som det normale redaktionelle interval. To elementer kræver normalt brødtekst eller en side-om-side-komponent. Mere end tolv har brug for nyttig gruppering, filtrering, paginering eller et katalogmønster; den grupperede variant må ikke overstige fireogtyve elementer.

Hvornår bør en tilpasset liste blive til en tabel?

Brug en tabel, når læsere skal sammenligne de fleste elementer på tværs af de samme tre eller flere felter, især numeriske værdier, datoer, statusser eller ja/nej-funktioner. Behold en liste, når resuméer og videre links betyder mere end sammenligning på tværs af elementer.

Har en tilpasset liste brug for ItemList-skema?

Nej. Tilføj ItemList kun når samlingen er meningsfuld og afgrænset, hvert markeret element er synligt, og eventuel position afspejler en erklæret orden. Almindelige navigations-, teaser- og relateret-indholdslister har normalt brug for semantisk HTML frem for særligt skema.

Kan elementer have forskellige felter?

Kun valgfrie felter defineret af det fælles skema må være fraværende. Lad ikke forfattere opfinde felter pr. element. Hvis flere elementer har brug for en anden informationsmodel, opdel dem i en anden liste eller vælg et mere passende element.