Varsling i to kolonner — Regler og eksempler

En to-kolonne varsling plasserer to korte, merkede varsler under ett felles emne. Varslene kan kontrastere handlinger, forklare to betingelser, eller skille mellom relaterte tilstander, men hvert må forbli nøyaktig og nyttig når det leses alene.

Dette gjengitte elementet fungerer fordi «Kladdeside» og «Publisert side» er ekte betingelser, ikke dekorative overskrifter. Den felles tittelen definerer beslutningen, hvert varsel gir en fullstendig instruksjon, og ingen av dem ber leseren om å utlede mening fra farge eller horisontal plassering.

Hvorfor dette elementet er viktig

Lesere møter ofte veiledning mens de skanner etter betingelsen som gjelder dem. En lang avsnitt som sier «kladder kan inneholde merkede eksempler, mens publiserte sider krever verifiserte verdier» tvinger leseren til å holde én setning i minnet mens den andre testes. To avgrensede varsler reduserer den arbeidsmengden. Etikettene viser først forgreningen, slik at en leser kan identifisere den relevante betingelsen og deretter lese instruksjonen.

Den psykologiske fordelen er selektiv oppmerksomhet. Folk trenger ikke alltid begge meldingene like mye; de trenger trygghet på at de har sett den riktige. En felles tittel etablerer spørsmålet, mens distinkte etiketter gjør de tilgjengelige tilstandene synlige. Side-om-side-presentasjon gjør også en meningsfull kontrast tydelig uten å overdrive den som en vinner og taper.

Denne fordelen forsvinner når forfatteren tvinger frem falsk symmetri. Falsk symmetri oppstår når layout antyder at to ideer har likt omfang, viktighet eller gyldighet selv om innholdet ikke har det. En én-setnings påminnelse ved siden av en seks-trinns sikkerhetsprosedyre er ikke et par. Det er heller ikke et påkrevd juridisk krav ved siden av et valgfritt produktivitetstips. Like brede kolonner kan få ulike meldinger til å se utbyttbare ut, noe som er helt feil signal.

Maskinuttrekkbarhet er evnen programvare har til å isolere innhold samtidig som relasjonene som gjør det nøyaktig bevares. En typet to-kolonne varsling eksponerer ett overordnet emne og to merkede barnevarsler. Søkesystemer og AI-agenter kan hente ut «For en publisert side, bruk verifiserte verdier med en kilde og kontrollert dato» uten å måtte gjette hvilken overskrift som styrer hvilken setning. Eksplisitte etiketter, kilde-rekkefølge og selvstendige tekstblokker overlever responsiv stabling og tekstbasert uttrekk.

Følg skrivereglene for elementer før du velger denne komponenten. Formål har forrang over utseende. En alvorlig risiko forblir en advarselsboks , en oppførsel-for-oppførsel-korrigering forblir en gjør-og-ikke-gjør-blokk , og to fakta blir ikke varsler bare fordi et design kan sette dem i kolonner.

Når du skal bruke det

Bruk dette elementet når ett felles emne har nøyaktig to korte varsler, og det å se begge samtidig hjelper leseren med å klassifisere, sammenligne eller unngå forvirring. Hensiktsmessige relasjoner inkluderer:

• To betingelser: innlogget versus utlogget, kladd versus publisert, før migrering versus etter migrering.
• To målgrupper: kontoeier versus invitert bruker, så lenge begge får veiledning om samme hendelse.
• Anbefalt og frarådet oppførsel: kun når hver side er et kort varsel snarere enn en liste over matchede handlinger.
• Tilgjengelige og utilgjengelige tilstander: når etikettene angir forholdene som produserer hver tilstand.
• Nåværende og kommende oppførsel: når datoer eller versjonsgrenser er eksplisitte.

Alle disse testene må bestå:

1. Én overskrift kan nøyaktig introdusere begge varslene.
2. Nøyaktig to betingelser eller meldinger eksisterer; kilden skjuler ikke et tredje tilfelle.
3. Hvert varsel har en spesifikk etikett og en fullstendig konsekvens eller handling.
4. Paret kan forstås i kilde-rekkefølge på en smal skjerm.
5. Intet varsel krever en nestet prosedyre, tabell, skjema eller lang kvalifisering.

Nære bom avslører feilbruk. Bruk vanlig prosa når den andre påstanden bare fortsetter den første. Bruk en sammenligningstabell når lesere må vurdere flere kriterier. Bruk et beslutningstre når mer enn to betingelser forgrener seg, eller når ett svar fører til et nytt spørsmål. Bruk en frittstående advarsel når det å gå glipp av meldingen kan forårsake skade, datatap, juridisk eksponering eller en irreversibel handling. Bruk gjør-og-ikke-gjør når flere gale handlinger hver trenger en tilsvarende korrigering.

Ikke oppfinn en motvekt. Hvis den ærlige instruksjonen er «Sikkerhetskopier databasen før migrering», skaper det å legge til «Etter migrering: fortsett å jobbe» symmetri uten verdi. Ikke del heller ett varsel opp i «Viktig» og «Også viktig». Etiketter må navngi reelle betingelser, tilstander, målgrupper eller posisjoner.

Hvor du skal plassere det

Plasser elementet rett etter avsnittet som definerer den felles situasjonen. Lesere må vite hvilken beslutning eller tilstand varslene kvalifiserer før de møter forgreningene. Når paret går foran en handling, plasser det før det første trinnet som endrer data eller forplikter leseren til et valg.

Nøyaktige posisjonsregler er:

• Plasser et to-betingelses-par etter forutsetninger og før betingelsesspesifikke instruksjoner.
• Plasser en før-handling-kontrast før kontrollen, kommandoen, nedlastingen eller trinnet den kvalifiserer.
• Plasser et resultat-tilstand-par etter at resultatet er definert og før feilsøkingsdetaljer.
• Hold bevis eller en kilde inne i det relevante varselet når det kun støtter det varselet; plasser felles bevis rett etter det komplette paret.
• I gjentatte dokumentasjonsseksjoner, bruk samme kilde-rekkefølge slik at gjentakende tilstander ikke bytter plass.

Elementet må ikke sitte ved siden av en annen to-kolonnekomponent, sammenligningstabell, fanekontroll, pristabell eller delt handlingsknapp. Tilstøtende rutenett gjør grensene uklare og kan antyde et fireveis valg. Det må ikke skille en påstand fra sin kilde, et trinn fra sin nødvendige advarsel, eller et skjemakontroll fra sin etikett. Ikke plasser det inne i et nummerert trinn: de nestede forgreningene kan gjøre rekkefølge og ansvar uklare.

Aldri plasser en alvorlig advarsel i én kolonne ved siden av rutinemessige råd i den andre. Den like geometrien reduserer advarselens dominans og antyder at lesere kan velge mellom de to. Oppgrader risikoen til en frittstående advarsel før den relevante handlingen, og bruk deretter dette elementet senere kun hvis to trygge betingelser fortsatt trenger avklaring.

Anatomi

1. Felles overskrift: navngir den ene situasjonen eller beslutningen som styres av begge varslene.
2. Varslingsbeholder: grupperer paret som ett redaksjonelt element uten å antyde at det er en enkelt alarm.
3. Varslingsetikett: navngir en betingelse, tilstand, målgruppe eller oppførsel i 2–6 ord.
4. Varslingstekst: oppgir det relevante faktum, konsekvens og neste handling i den rekkefølgen når alle tre er nødvendige.
5. Valgfritt ikon: forsterker en synlig tekstitikett; det bærer aldri skillet alene.
6. Valgfri kildehenvisning: støtter en endrende, regulert eller eksternt definert påstand innenfor varselet den kvalifiserer.
7. Kilde-rekkefølge: bestemmer skjermleser-, kopi- og mobilrekkefølge; visuell utforming må ikke reversere den.

Forfatteren leverer felles overskrift, to etiketter, to tekster, tone og eventuelle kilder. Gjengiveren leverer responsivt rutenett, avstand, visuell vekt, semantisk beholder og dekorativ ikonbehandling.

Designeksempler

Dette er de fullt støttede variantene. Varianter endrer etiketter og vektlegging, ikke to-varsler-datamodellen.

Kontrasterende handlinger

Bruk for én anbefalt og én frarådet handling når det kun er én melding på hver side. Oppgi handlingen og dens grunn; ikke utvid denne varianten til matchede lister.

Betingede tilstander

Bruk når den korrekte instruksjonen avhenger av en gjensidig utelukkende betingelse som «Eksisterende konto» og «Ny konto». Navngi betingelsen i hver etikett og sett den mest vanlige eller forutgående tilstanden først.

Parede avklaringer

Bruk når to relaterte fakta forhindrer forskjellige misforståelser, men ikke er motsetninger. Bruk nøytral utforming på begge slik at designet ikke skaper godkjenning, alvorlighetsgrad eller preferanse.

Kompakt statuspar

Bruk for korte statuskonsekvenser etter at tilstandene allerede er forklart. Hver tekst er én setning. Ikke fjern etiketter eller reduser tekstene til uforklarte verdier.

Stablet mobilpar

Alle varianter stabler ved smale bredder. Hold det første varselet rett før det andre og behold den felles overskriften. Ikke lag en sveveinteraksjon eller faner, fordi det å skjule ett varsel ødelegger elementets formål.

Parametere

«Kilde» identifiserer hvor en adapter henter hver verdi. Tekstmappingen lagrer med vilje to komplette varseloppføringer snarere enn to visuelt plasserte kolonner.

Den overordnede brødteksens første overskrift mapper til title. Hvert nestet element mapper sin første overskrift til label og alt etter det til content; varslingsattributter holder tone og icon. Gjengiveren må avvise ett, tre eller tomme varslingselementer fremfor å stille fylle eller droppe en kolonne.

Syntaks og kodeeksempler

Alle formater bevarer samme tittel, varslingsrekkefølge, etiketter, tekster, toner og kilder. «Kolonne én» og «kolonne to» er presentasjonsbegreper, ikke feltnavn.

Bærbar Markdown-direktiv

:::notification-two-column{variant=conditional}
## Velg instruksjonen for din publiseringsstatus

::notice{tone=neutral icon="draft"}
### Kladdeside

Bruk eksempelverdier kun når de er tydelig merket som eksempler. Fjern eller erstatt alle eksempler før publisering.
::

::notice{tone=caution icon="publish"}
### Publisert side

Bruk verifiserte verdier med en kilde og kontrollert dato. Hvis verifisering er ufullstendig, hold tilbake påstanden.
::
:::

Dette elementet overstyrer det generiske nestet-element-navnet med notice fordi oppføringene har varselspesifikk toneoppførsel. Den første overordnede overskriften leverer den felles tittelen; hvert varsels første overskrift leverer etiketten.

Hugo shortcode

Ingen nåværende produksjons-shortcode implementerer denne eksakte parede varslingskontrakten. Inntil en adapter eksisterer, bruk semantisk HTML som i gjengivelseseksemplet. Den tiltenkte Hugo-notasjonen er dokumentert som:

{{< notification-two-column variant="conditional" >}}
## Velg instruksjonen for din publiseringsstatus

{{< notification tone="neutral" icon="draft" >}}
### Kladdeside
Bruk merkede eksempelverdier kun, og fjern dem før publisering.
{{< /notification >}}

{{< notification tone="caution" icon="publish" >}}
### Publisert side
Bruk verifiserte verdier med en kilde og kontrollert dato.
{{< /notification >}}
{{< /notification-two-column >}}

Skråstrek-kommentarformen forhindrer at dette spesifikasjonseksemplet kaller en shortcode som ikke eksisterer. En fremtidig adapter må validere nøyaktig to barnevarsler og gjengi dem i kilde-rekkefølge.

WordPress-blokk

<!-- wp:amicited/notification-two-column {"variant":"conditional"} -->
<h2>Velg instruksjonen for din publiseringsstatus</h2>
<!-- wp:amicited/notification {"tone":"neutral","icon":"draft"} -->
<h3>Kladdeside</h3>
<p>Bruk merkede eksempelverdier kun, og fjern dem før publisering.</p>
<!-- /wp:amicited/notification -->
<!-- wp:amicited/notification {"tone":"caution","icon":"publish"} -->
<h3>Publisert side</h3>
<p>Bruk verifiserte verdier med en kilde og kontrollert dato.</p>
<!-- /wp:amicited/notification -->
<!-- /wp:amicited/notification-two-column -->

En WordPress-editor bør presentere to faste varse losteplasser, tillate omorganisering og forhindre publisering når enten etikett eller tekst er tom. Den må ikke la forfattere legge til et tredje varsel bare fordi rutenettblokken støtter flere kolonner.

Eksempler

Bra: to reelle betingelser med fullstendige handlinger

Før importering
Last ned gjeldende poster og noter eksporttidspunktet. Kopien gir deg et gjenopprettingspunkt hvis felttilordning gir et uventet resultat.

Etter importering
Sammenlign antall importerte poster med kildetallet, inspiser deretter minst én post som inneholder hvert tilordnede felt. Antall oppdager utelatelser; den fullstendige posten oppdager forskjøvne verdier.

Dette paret har ett emne—trygg importverifisering—og en ekte tidsgrense. Hvert varsel navngir en handling og forklarer hvilken feil den fanger opp. Det andre er lengre fordi det inneholder to relaterte kontroller, men begge sider bærer sammenlignbart ansvar og forblir forståelige når de stables.

Dårlig: falsk symmetri som nedgraderer en risiko

Nyttig tips
Gi eksporten et nytt navn slik at den er lettere å finne senere.

Viktig
Importering med «Erstatt alle» sletter permanente eksisterende poster permanent og kan ikke angres. Sikkerhetskopier databasen, bekreft målet, innhent godkjenning og planlegg nedetid før du fortsetter.

Det første varselet er valgfri husarbeid; det andre beskriver irreversibelt datatap og flere forutsetninger. Å plassere dem i like kolonner antyder lik vekt og får den kritiske meldingen til å se ut som ett av to alternativer. Flytt datatapsvarselet til en frittstående advarsel før kontrollen. Behold filnavnforslaget som vanlig støttende prosa.

Skjemamerking og tilgjengelighet

En to-kolonne varsling har ingen dedikert Schema.org-type. Innholdet forblir innenfor den omsluttende Article, TechArticle eller WebPage. Ikke utsted ItemList, HowToStep, Question eller Answer bare fordi to avgrensede oppføringer eksisterer. Hvis et varsel inneholder innhold som uavhengig kvalifiserer for strukturert data, bestemmer den omsluttende posttypens skjemaregler kartleggingen; dette elementet legger til ingenting av seg selv.

Bruk én merket section når paret tilhører hovedforklaringen, eller en merket aside når begge varslene er komplementære. Hvert barneelement kan være en aside eller section med en reell overskrift på riktig dokumentnivå. Ikke bruk ARIA alert eller alertdialog: disse rollene annonserer dynamiske, tidsensitive endringer og er upassende for statisk redaksjonell veiledning.

Det tilgjengelige navnet kommer fra den synlige felles overskriften gjennom innfødt overskriftsstruktur eller aria-labelledby. Hver varslingsetikett må være tekst. Farge, kantstil, plassering og ikoner kan forsterke tone, men kan ikke definere den. Hvis et ikon er dekorativt, skjul det for hjelpemiddelteknologi; hvis det kommuniserer informasjon som ikke finnes i etiketten, omskriv etiketten istedenfor å stole på alternativ tekst for å reparere designet.

DOM-rekkefølge styrer mening. Skjermlesere og mobiloppsett må møte det første varselet og deretter det andre. Ikke reverser den visuelle rekkefølgen med CSS. Ved 200 % tekstzoom og smale bredder må varslene stables uten avskjæring eller horisontal sideblading. Lenker trenger beskrivende etiketter, og flere lenker må ikke komprimeres til en umerket rad med ikoner.

Skriveregler

Skriv relasjonen før du skriver varslene: «Leseren trenger to meldinger fordi den korrekte veiledningen endres av ___». Hvis blankfeltet ikke kan fylles med en konkret betingelse, tilstand, målgruppe, tid eller atferdskontrast, bruk prosa.

• Bruk nøyaktig to varsler under én felles tittel.
• Hold tittelen til 3–12 ord og hver etikett til 2–6 ord.
• Sikt på 25–80 ord per tekst; 120 ord er et absolutt maksimum.
• Bruk ett eller to korte avsnitt per varsel og ikke mer enn én kort intern lenke.
• Sett faktum eller betingelse først, dens konsekvens som nummer to, og handlingen sist når alle er til stede.
• Bruk parallell etikettgrammatikk: «Før lansering / Etter lansering», ikke «Før lansering / Hva administratorer bør gjøre senere».
• Navngi betingelser direkte. Skriv aldri «venstre», «høyre», «det andre alternativet» eller «boksen over».
• Match tone til bevis. Nøytrale parede fakta bør ikke arve grønn og rød behandling.
• La endrede påstander bære en dato, versjon, plan, jurisdiksjon eller kilde etter behov.

Sammenlignbar vekt betyr at begge meldingene fortjener samme øyeblikk i leserens flyt. Det krever ikke identiske setnings- eller tegnantal. Ikke put en sannhet for å matche en lengre. Hvis én tekst overstiger den andre med mer enn omtrent to til én, test om det større varselet trenger en egen seksjon, eller om det mindre varselet er en falsk motpart.

Aldri plasser en flertrinnsprosedyre, tabell, skjema, priskort, testimonial, salgsfremmende handlingsknapp, langt sitat, kodeeksempel, video eller nestet komponent inne i et varsel. Aldri bruk paret til å mildne juridisk, medisinsk, finansiell, personvern-, sikkerhets- eller destruktiv-handlingsveiledning. Ikke antyd at to betingelser er uttømmende med mindre innholdseieren har verifisert at ingen tredje tilstand eksisterer.

Posttyper som bruker det

postTypes-frontmatter-arrayet er kilden for denne tabellen. Inkludering betyr at elementet er tilgjengelig for et ekte to-varsel-tilfelle, ikke obligatorisk på hver side av den typen.

QA-sjekkliste

• Felles emne: Én nøyaktig tittel styrer begge varslene uten å strekke omfanget.
• Nøyaktig to varsler: Kilden inneholder to komplette oppføringer og ingen underforstått tredje tilstand.
• Ekte relasjon: Etiketter navngir en meningsfull kontrast, betingelse, målgruppe, status eller tidsgrense.
• Uavhengig mening: Hvert varsel forblir tydelig når det trekkes ut med den felles tittelen.
• Ingen falsk symmetri: Begge meldingene fortjener sammenlignbar vekt; ingen er fyll eller en nedgradert kritisk advarsel.
• Korrekt plassering: Paret følger sin kontekst og går foran handlingen eller detaljen det kvalifiserer.
• Trygge naboer: Det er ikke ved siden av en annen delt layout, tabell, fanekontroll eller to-kolonne CTA.
• Nyttige etiketter: Etiketter bruker parallell grammatikk og er aldri avhengig av venstre/høyre-posisjon eller farge.
• Lengdekontroll: Tekster holder seg innenfor ett eller to avsnitt og ikke mer enn 120 ord hver.
• Innholdsbegrensning: Ingen nestet prosedyre, tabell, skjema, media, reklame eller kompleks komponent vises inne i.
• Responsiv rekkefølge: Mobil-, tastatur-, skjermleser- og kopiert-tekst-rekkefølge samsvarer med den forfattede sekvensen.
• Tilgjengelig semantikk: En synlig overskrift merker forelderen; barneetiketter er overskrifter; statisk innhold bruker ikke alarmeroller.
• Toneintegritet: Stilsetting reflekterer den faktiske betydningen og gjør ikke nøytrale fakta til gode/dårlige vurderinger.
• Notasjonsparitet: Markdown, Hugo og WordPress bevarer samme tittel, etiketter, tekster, attributter og rekkefølge.
• Skjemabegrensning: Elementet skaper ingen uunderstøttet strukturert data.

Avvis elementet hvis kontrollene for felles emne, ekte relasjon eller falsk symmetri slår feil. Dette er redaksjonelle feil som en gjengiver ikke kan fikse. Omskriv innholdet som prosa, separate seksjoner, en frittstående advarsel, eller et annet formålsmatchet element før du justerer presentasjonen.

FAQ

Den strukturerte FAQ-en i frontmatter dekker implementeringsbeslutningene som mest sannsynlig blir misforstått: varslene trenger ikke være motsetninger eller identiske i lengde, mobilrekkefølge følger kilde-rekkefølge, alvorlige risikoer forblir frittstående advarsler, og elementet skaper ingen egen skjemamerking.