Infobox: 2 kolonner — format, regler og eksempler

En to-kolonners infobox opdeler én idé i præcis to parallelle punkter, så en læser kan forstå relationen ved et øjekast. Brug den, når parret er mere nyttigt side om side end begravet i et afsnit: to ansvarsområder, to faser, to perspektiver eller to komplementære dele af ét svar.

Dette viste eksempel er én infobox, én fælles titel og præcis to elementer. Begge elementer besvarer samme type spørgsmål med sammenlignelig dybde. Elementet påstår ikke, at de to behov er modsætninger; det viser, at et nyttigt brief skal tage højde for begge.

Hvorfor dette element er vigtigt

Tæt brødtekst tvinger læsere til at genopbygge relationer. I en sætning som “Et content brief skal tjene læseren ved at løse en opgave og tjene virksomheden ved at understøtte en kvalificeret handling” eksisterer de to ansvarsområder, men deres grænser er svage. En to-kolonners infobox gør det fælles emne synligt én gang og giver hvert ansvarsområde en navngiven region. Læsere kan scanne begge overskrifter, vælge, hvor de vil starte, og sammenligne mængden og typen af detaljer uden at genlæse en sammensat sætning.

Den psykologiske fordel kommer fra chunking: gruppering af relateret information i afgrænsede enheder. Den fælles titel fortæller læseren, hvad der forbliver konstant, mens elementtitlerne viser, hvad der ændrer sig. Dette hierarki er især nyttigt, når intet punkt bør dominere. Almindelig brødtekst giver naturligt det første punkt større fremtræden og kan få det andet til at føles som en eftertanke; afstemte kolonner signalerer lige redaktionel vægt.

Maskinekstraherbarhed er softwarens evne til at isolere en indholdsenhed, mens dens betydning bevares. En typet infobox eksponerer et overordnet emne og to eksplicitte underemner. Et genfindingssystem kan bevare den fælles titel, elementtitler, brødtekst og kildens rækkefølge i stedet for at gætte, hvor én sætning slutter, og en anden begynder. Hvert element skal stadig være selvstændigt: “Forretningskravet er dokumentation, der understøtter en kvalificeret handling” overlever ekstraktion, mens “Den anden side” ikke gør.

Struktur redder ikke svag tankegang. Hvis kilden indeholder ét udviklet punkt og én sætning tilføjet for symmetri, gør gengivelsen blot ubalancen mere tydelig. Anvend skrivereglerne for elementer : skriv den fulde argumentation først, vælg derefter dette element kun, når den færdige idé genuint har to parallelle dele. De elementspecifikke regler på denne side har forrang, hvor de definerer elementets præcise emnekortlægning og begrænsninger.

Hvornår skal det bruges

Brug en to-kolonners infobox, når alle fire betingelser er opfyldt:

1. Der er én klar overordnet idé, der kan titulere hele boksen.
2. Den overordnede idé deler sig naturligt i præcis to elementer.
3. Begge elementer udfører samme informationsopgave, såsom at forklare et ansvar, en fase, et målgruppeperspektiv eller en dimension.
4. Hvert element kan forstås på cirka 30–90 ord uden en indlejret struktur.

Gode anvendelser omfatter “Før lancering / Efter lancering”, “Læsersignal / Virksomhedssignal”, “Hvad ændrer sig / Hvad forbliver det samme” og “Ejers ansvar / Reviewers ansvar”. Etiketterne skal eksponere en reel relation. Hvis læseren ikke kan fuldføre sætningen “Disse hører sammen, fordi…”, er grupperingen formentlig dekorativ.

Næsten-ramte tilfælde er vigtige, fordi et to-kolonners layout kan få næsten ethvert par til at se bevidst ud. Brug det ikke til en enkelt idé opdelt ved et vilkårligt sætningsbrud. Omform ikke en liste med fire elementer til to lange kolonner blot for at spare lodret plads; kildens rækkefølge og skanning bliver tvetydige. Brug det ikke til en detaljeret produktsammenligning med flere kriterier, fordi en sammenligningstabel giver hvert kriterium en eksplicit række. Brug det ikke til fordele og ulemper, når antallet af punkter er forskelligt, eller når læsere skal afveje flere afvejninger. Par ikke en definition med et salgsfremmende call to action: disse blokke udfører forskellige opgaver og fortjener ikke ligebehandling.

Det stærkeste advarselstegn er en etiket som “Andet”, “Mere” eller “Yderligere information”. Disse etiketter afslører, at opdelingen følger tilgængelig plads snarere end betydning. Returner indholdet til brødtekst, eller find den faktiske skelnen, før du bruger elementet.

Hvor skal det placeres

Placer infoboxen umiddelbart efter det afsnit, der introducerer den fælles idé. Læseren har brug for én sætning kontekst, før de møder opdelingen, men bør ikke skulle krydse urelateret dokumentation eller et andet underafsnit for at nå den. Efter boksen fortsætter du med analyse, eksempler eller instruktioner, der gælder for begge elementer.

Den kan sidde direkte under en H2, når H2’en selv leverer den overordnede idé, og infoboxen har sin egen mere specifikke titel. Den kan også følge efter en kort definition, når de to elementer forklarer dimensioner af den definition. Den må ikke optræde mellem en påstand og dens kildehenvisning, mellem et trin og betingelsen for at udføre det trin, eller inde i et listeelement i en nummereret liste. Disse positioner bryder relationer, der bør forblive sammenhængende.

Placer den ikke ved siden af en anden to-kolonners infobox, sammenligningstabel, fanesæt eller fordele-og-ulemper-blok. Tilstødende parallelle strukturer tvinger læseren til at beslutme, hvilken visuel relation der betyder noget, og kan skabe fire tilsyneladende kolonner på brede skærme. Indsæt forklarende brødtekst mellem forskellige strukturer, eller kombiner materialet i én bedre egnet tabel eller sektion. Undgå at placere den umiddelbart før eller efter et to-kolonners call to action; identisk geometri kan få redaktionel forklaring til at ligne reklame.

Brug højst én to-kolonners infobox i en kort sektion. Gentagelse forvandler en nyttig kontrast til side-inventar. Når en lang artikel indeholder flere ægte par, skal de adskilles under forskellige overskrifter, og bekræft, at hvert par har en tydelig overordnet idé.

Anatomi

Anatomi indeholder én overordnet region og to gentagne underregioner. Skærmbilledet bør mærke semantiske dele, ikke polstring eller farvetokens, så specifikationen forbliver brugbar, hvis det visuelle system ændrer sig.

1. Ydre afgrænsning: Grupperer den overordnede titel og begge elementer som én redaktionel enhed.
2. Fælles titel: Navngiver den idé, som begge elementer forklarer. Det er ikke et tredje punkt.
3. Første elements titel og brødtekst: Angiver det første medlem af parret i komplet, ekstraherbart sprog.
4. Andet elements titel og brødtekst: Besvarer samme type spørgsmål med afstemt dybde.
5. Layoutrelation: Bruger kolonner med lige bredde, når pladsen tillader det, og stabler element ét før element to på smalle skærme.

Kanter, baggrund, mellemrum, radius, typeskala og breakpoint tilhører gengiveren. Forfattere kontrollerer indholdshierarkiet og rækkefølgen, ikke visuelle tokens.

Designeksempler

Der er ét semantisk element med fire understøttede indholds- og viewport-varianter. Varianter ændrer titelhåndtering eller responsiv præsentation; de ændrer aldrig kravet om præcis to elementer.

Standard titelvariant: Foretrukket til selvstændig brug. En fælles titel navngiver den overordnede idé, og begge underelementer har kortfattede titler.

Kontekstuel titelvariant: Den umiddelbart foregående H2 kan fungere som den fælles titel. Dette er kun tilladt, når intet afsnit eller komponent adskiller H2’en fra boksen, og infoboxen har et tilgængeligt navn afledt af den overskrift.

Kompakt variant: Brug til to korte definitioner eller ansvarsområder. Hver brødtekst danner stadig en komplet sætning; layoutet bliver ikke et par taglines.

Small-viewport-variant: Elementer stables vertikalt. Rækkefølgen forbliver meningsfuld uden henvisninger til “venstre”, “højre”, “over” eller “ved siden af”.

Ikoner er ikke en indholdsvariant. Hvis designsystemet tilføjer dekorative ikoner, bruger de tom alternativ tekst og erstatter ikke elementtitler. Hvis hvert element har brug for et informativt billede, brug et billedorienteret element i stedet for at udvide denne infobox-kontrakt.

Parametre

Parameterkontrakten forhindrer elementet i at glide over i et generisk grid. Værdier, der beskriver betydning, hører til i forfattet indhold; responsivt layout forbliver i gengiveren.

Titlen er påkrævet, medmindre den umiddelbart foregående dokumentoverskrift leverer samme overordnede emne og kan mærke containeren programmatisk. Elementernes brødtekster tillader fremhævelse, indlejret kode og ét nyttigt link. De tillader ikke indlejrede overskrifter, tabeller, medier, accordions, formularer, calls to action eller en anden infobox.

Syntaks og kodeeksempler

Alle tre notationer bevarer samme overordnede titel, to ordnede elementer, elementtitler og elementbrødtekster. Det portable Markdown-direktiv er den kanoniske kilde. Hugo- og WordPress-formerne er adapterkontrakter; deres gengivere skal producere tilsvarende semantisk HTML og responsiv rækkefølge.

Portabelt Markdown-direktiv

:::infobox-2-columns
## Et nyttigt content brief besvarer to spørgsmål

::item
### Hvad har læseren brug for?

Angiv det spørgsmål, den beslutning eller den opgave, siden skal løse, inklusive den kontekst, der ændrer svaret.
::

::item
### Hvad har virksomheden brug for?

Angiv den kvalificerede handling, siden skal understøtte, sammen med den dokumentation, der kræves for at opnå den handling.
::
:::

Det første overordnede hovedkortlægges til title. Hvert ::item kortlægger sin første overskrift til item.title og den resterende brødtekst til item.content. Denne præcise to-element-kortlægning tilsidesætter den generelle tilladelse til gentagelige elementer i basereglerne.

Hugo shortcode

{{< infobox-2-columns title="Et nyttigt content brief besvarer to spørgsmål" >}}
  {{< infobox-item title="Hvad har læseren brug for?" >}}
  Angiv det spørgsmål, den beslutning eller den opgave, siden skal løse, inklusive den kontekst, der ændrer svaret.
  {{< /infobox-item >}}
  {{< infobox-item title="Hvad har virksomheden brug for?" >}}
  Angiv den kvalificerede handling, siden skal understøtte, sammen med den dokumentation, der kræves for at opnå den handling.
  {{< /infobox-item >}}
{{< /infobox-2-columns >}}

Adapteren bruger kun navngivne parametre. Den må afvise et tredje element frem for lydløst at omslutte det, og den skal bevare den forfattede elementrækkefølge, når layoutet stabler.

WordPress-blok

<!-- wp:amicited/infobox-2-columns {"title":"Et nyttigt content brief besvarer to spørgsmål"} -->
  <!-- wp:amicited/infobox-item {"title":"Hvad har læseren brug for?"} -->
  <p>Angiv det spørgsmål, den beslutning eller den opgave, siden skal løse, inklusive den kontekst, der ændrer svaret.</p>
  <!-- /wp:amicited/infobox-item -->
  <!-- wp:amicited/infobox-item {"title":"Hvad har virksomheden brug for?"} -->
  <p>Angiv den kvalificerede handling, siden skal understøtte, sammen med den dokumentation, der kræves for at opnå den handling.</p>
  <!-- /wp:amicited/infobox-item -->
<!-- /wp:amicited/infobox-2-columns -->

WordPress bør eksponere to faste elementpladser frem for et ubegrænset “tilføj blok”-område. Redaktører kan omorganisere de to elementer, men kan ikke indsætte en urelateret blok mellem dem eller tilføje en tredje kolonne.

Eksempler

Godt eksempel

Dette virker, fordi den fælles titel etablerer én idé, tidsgrænsen skaber et ægte par, og begge kolonner specificerer sammenligneligt målearbejde. Hvert element forbliver meningsfuldt, når det stabler eller ekstraheres uafhængigt.

Dårligt eksempel

Forbedr dit indhold

Skriv godt: Skab nyttigt, autoritativt, engagerende indhold, som dit publikum vil elske, og søgemaskiner vil belønne.

Andre ting: SEO omfatter også teknisk arbejde, links, konverteringsdesign, analyse, brandopbygning, distribution, vedligeholdelse og mange flere vigtige aktiviteter.

Dette fejler, fordi parret er kunstigt. “Skriv godt” er en vag instruktion, “Andre ting” er en blandet kategori, og det andet element indeholder langt større omfang end det første. Boksen antyder lige, parallelle koncepter, hvor ingen findes. Erstat den med brødtekst, der definerer det faktiske indholdsmål, brug derefter en liste eller separate sektioner til de forskellige arbejdsstrømme.

Skema-markup og tilgængelighed

En to-kolonners infobox har ingen dedikeret Schema.org-type og opretter ikke selvstændige strukturerede data. Dens tekst forbliver en del af den omsluttende Article, TechArticle eller WebPage, når siden kvalificerer sig til den markup. Markér ikke de to elementer som ItemList blot fordi der er to af dem; elementet repræsenterer en relation, ikke nødvendigvis en rangeret eller komplet liste. Hvis et element uafhængigt indeholder en kendsgerning, der bruges andetsteds i strukturerede data, styrer sidens skemapolitik den kendsgerning.

Semantisk HTML bør udtrykke én mærket container med to undersektioner. Brug et aside kun når parret er komplementært til den omgivende fortælling; brug et section når det er en del af hovedargumentet. Giv containeren et tilgængeligt navn gennem dens synlige titel og aria-labelledby. Hver undertitel skal være en reel overskrift på korrekt niveau, ikke fed tekst valgt for udseendets skyld.

Kildens rækkefølge er tilgængelighedsrækkefølgen. Tastaturnavigation, skærmlæsere, kopiér-indsæt og smalle skærme skal møde element ét før element to. CSS må oprette kolonner, men må ikke visuelt vende dem om. Referér aldrig til “den venstre boks” eller “den højre boks”, fordi disse positioner forsvinder, når de stables. Farve, ikonform og baggrund kan ikke være den eneste måde at skelne elementer på. Designet skal understøtte tekstzoom uden beskæring, horisontal scroll eller overlappende kolonner.

Skriveregler

Start med at skrive overordnet sætning: “Denne idé har to dele: X og Y.” Hvis den sætning er unøjagtig, brug ikke elementet. Giv begge elementtitler samme grammatiske form — to navneord, to spørgsmål eller to tidsangivelser — fordi parallel sprogbrug gør relationen umiddelbart læsbar.

Brug præcis to elementer. Hold hver titel på 2–7 ord og hver brødtekst på 30–90 ord, hvor det er muligt, med et absolut maksimum på 120 ord. En forskel på én sætning er acceptabel; et 35-ords element ved siden af et 110-ords element kræver redigering eller en anden struktur. Hver brødtekst bør besvare samme underforståede spørgsmål og bruge sammenlignelig dokumentationsdybde. Afstemt dybde betyder ikke at fylde et kort svar med fyldord.

Brug direkte, neutralt sprog. Angiv skelnen i titlerne og forklar dens konsekvens i brødteksterne. Foretræk “Før lancering / Efter lancering” frem for “Først / Andet,” fordi meningsfulde etiketter overlever ekstraktion. Undgå “enten/eller,” medmindre valgene er genuint eksklusive, og undgå “versus,” når elementerne er komplementære.

Indsæt aldrig disse inde i elementet:

• Et tredje element, selv hvis gengiveren kunne omslutte det.
• En flertrinsprocedure, lang punktopstilling, datatabel, prissætningsgrid, formular, udtalelse eller reklamebanner.
• Uafhængige H2-sektioner, indlejrede infoboxes, faner, accordions, video eller billedgallerier.
• Påkrævet juridisk tekst, sikkerhedsadvarsler, kildelister eller kvalifikationer, der kun gælder for én sætning uden for boksen.
• To urelaterede links designet til at ligne konkurrerende calls to action.

Hvis et af elementerne har brug for underoverskrifter eller mere end to afsnit, fremryk begge elementer til almindelige sidesektioner. Hvis læsere skal vælge mellem elementerne, tilføj beslutningskriterier i brødtekst eller brug et sammenlignings- eller beslutningselement; visuel symmetri alene forklarer ikke et valg.

Indlægstyper, der bruger det

Feltet postTypes i front matter er kilden til dette brugssæt. Hvert listede format har en naturlig todelt relation, men ingen bør inkludere elementet som standard, når indholdet ikke danner et ægte par.

QA-tjekliste

• Én overordnet idé: Boksen har ét klart fælles emne, der forklarer, hvorfor begge elementer hører sammen.
• Præcis to elementer: Kilde og gengivet output indeholder to underelementer — aldrig ét, tre eller en tom plads.
• Ægte parallelitet: Begge elementer besvarer samme type spørgsmål og bruger titler med parallel grammatik.
• Afstemt dybde: Intet element er en token-modvægt eller en blandet opsamlingskategori; detaljer og dokumentation er sammenlignelige.
• Nyttig placering: Boksen følger sin introducerende kontekst og adskiller ikke en påstand fra dokumentation eller et trin fra dets krav.
• Sikre naboer: Den er ikke tilstødende til et andet parallelt grid, sammenligningskomponent eller to-kolonners CTA.
• Ekstraherbar ordlyd: Overordnet og elementtitler navngiver deres emner, og brødtekster afhænger ikke af “venstre,” “højre” eller nærliggende stedord.
• Responsiv rækkefølge: Smalle layouts stabler element ét før element to uden beskæring, horisontal scroll eller visuel omorganisering.
• Tilgængelig struktur: Containeren har et synligt programmatisk mærkat, undertitler er rigtige overskrifter, og farve eller ikoner bærer ikke betydning alene.
• Indholdsbegrænsninger: Hver brødtekst holder sig inden for to afsnit og indeholder ingen indlejret kompleks komponent, procedure eller salgsfremmende kontrol.
• Notationsparitet: Portabel Markdown, Hugo og WordPress bevarer samme titel, to elementer, brødtekster og rækkefølge.
• Skema-begrænsning: Ingen liste- eller sammenligningsmarkup tilføjes, medmindre sideindholdet uafhængigt kvalificerer sig til det.

En reviewer bør afvise elementet, når nogen af de første fire tjek fejler. Disse fejl indikerer et konceptuelt problem, ikke en stilingsdefekt, og ændring af bredden eller dekorationen kan ikke reparere dem.

FAQ

Front matter-FAQ-posterne besvarer de tilbagevendende implementeringsspørgsmål: elementantallet er fastsat til to, dybde betyder mere end identiske ordtal, detaljerede sammenligninger har brug for en tabel, mobil bevarer kildens rækkefølge, og elementet genererer ikke skema-markup. At holde disse svar i struktureret front matter lader akademiskabelonen gengive den godkendte FAQ-behandling uden at duplikere indholdet i brødteksten.