Notification: Two Columns — Rules and Examples

A two-column notification places two short, labelled notices under one shared subject. The notices may contrast actions, explain two conditions, or distinguish related states, but each must remain accurate and useful when read on its own.

This rendered element works because “Draft page” and “Published page” are genuine conditions, not cosmetic headings. The shared title defines the decision, each notice supplies a complete instruction, and neither asks the reader to infer meaning from color or horizontal position.

Why this element matters

Readers often encounter guidance while scanning for the condition that applies to them. A long paragraph that says “drafts may contain labelled examples, whereas published pages require verified values” makes the reader hold one clause in memory while testing the other. Two bounded notices reduce that work. The labels expose the branch first, so a reader can identify the relevant condition and then read its instruction.

The psychological benefit is selective attention. People do not always need both messages equally; they need confidence that they noticed the right one. A shared title establishes the question, while distinct labels make the available states visible. Side-by-side presentation also makes a meaningful contrast obvious without overstating it as a winner and loser.

That benefit disappears when the author forces false symmetry. False symmetry occurs when layout implies that two ideas have equal scope, importance, or validity even though the content does not. A one-sentence reminder beside a six-step safety procedure is not a pair. Neither is a required legal restriction beside an optional productivity tip. Equal-width columns can make unequal messages look interchangeable, which is precisely the wrong signal.

Machine extractability is the ability of software to isolate content while preserving the relationships that make it accurate. A typed two-column notification exposes one parent subject and two labelled child notices. Search systems and AI agents can recover “For a published page, use verified values with a source and checked date” without guessing which heading governs which sentence. Explicit labels, source order, and self-contained bodies survive responsive stacking and text-only extraction.

Follow the element writing rules before choosing this component. Purpose has precedence over appearance. A severe risk remains a warning box , a behavior-by-behavior correction remains a do’s and don’ts block , and two facts do not become notifications merely because a design can put them in columns.

When to use it

Use this element when one shared subject has exactly two short notices and seeing both at once helps the reader classify, compare, or avoid confusion. Appropriate relationships include:

• Two conditions: signed in versus signed out, draft versus published, before migration versus after migration.
• Two audiences: account owner versus invited user, as long as both receive guidance about the same event.
• Recommended and discouraged behavior: only when each side is a short notice rather than a list of matched behaviors.
• Available and unavailable states: when the labels state the conditions that produce each state.
• Current and upcoming behavior: when dates or version boundaries are explicit.

All of these tests must pass:

1. One heading can accurately introduce both notices.
2. Exactly two conditions or messages exist; the source is not hiding a third case.
3. Each notice has a specific label and a complete consequence or action.
4. The pair can be understood in source order on a narrow screen.
5. Neither notice requires a nested procedure, table, form, or long qualification.

Near misses reveal misuse. Use ordinary prose when the second statement merely continues the first. Use a comparison table when readers must assess several criteria. Use a decision tree when more than two conditions branch or when one answer leads to another question. Use a standalone warning when missing the message could cause harm, data loss, legal exposure, or an irreversible action. Use do’s and don’ts when several wrong behaviors each need a corresponding correction.

Do not invent a counterweight. If the honest instruction is “Back up the database before migration,” adding “After migration: keep working” creates symmetry but no value. Likewise, do not split one notice into “Important” and “Also important.” Labels must name real conditions, states, audiences, or positions.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

Place the element immediately after the paragraph that defines the shared situation. Readers must know what decision or state the notices qualify before they encounter the branches. When the pair precedes an action, put it before the first step that changes data or commits the reader to a choice.

Exact position rules are:

• Put a two-condition pair after prerequisites and before condition-specific instructions.
• Put a pre-action contrast before the control, command, download, or step it qualifies.
• Put a result-state pair after the result has been defined and before troubleshooting details.
• Keep evidence or a source inside the relevant notice when it supports only that notice; place shared evidence immediately after the complete pair.
• In repeated documentation sections, use the same source order so recurring states do not swap positions.

The element may not sit beside another two-column component, comparison table, tabs control, pricing grid, or split call to action. Adjacent grids make boundaries ambiguous and can imply a four-way choice. It may not separate a claim from its citation, a step from its required warning, or a form control from its label. Do not place it inside a numbered step: the nested branches can make sequence and responsibility unclear.

Never put a severe warning in one column beside routine advice in the other. The equal geometry reduces the warning’s dominance and suggests that readers may choose between the two. Promote the risk to a standalone warning before the relevant action, then use this element later only if two safe conditions still need clarification.

Anatomy

1. Shared heading: names the one situation or decision governed by both notices.
2. Notice container: groups the pair as one editorial element without implying that it is a single alert.
3. Notice label: names a condition, state, audience, or behavior in 2–6 words.
4. Notice body: states the relevant fact, consequence, and next action in that order when all three are needed.
5. Optional icon: reinforces a visible text label; it never carries the distinction alone.
6. Optional source note: supports a changing, regulated, or externally defined claim within the notice it qualifies.
7. Source order: determines screen-reader, copy, and mobile order; visual styling must not reverse it.

The author supplies the shared heading, two labels, two bodies, tone, and any sources. The renderer supplies the responsive grid, spacing, visual emphasis, semantic container, and decorative icon treatment.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

These are the complete supported variants. Variants change labels and emphasis, not the two-notice data model.

Contrasting actions

Use for one recommended and one discouraged action when there is only one message on each side. State the action and its reason; do not expand this variant into matched lists.

Conditional states

Use when the correct instruction depends on a mutually exclusive condition such as “Existing account” and “New account.” Name the condition in each label and put the most common or prerequisite state first.

Paired clarifications

Use when two related facts prevent different misunderstandings but are not opposites. Apply neutral styling to both so the design does not invent approval, severity, or preference.

Compact status pair

Use for short status consequences after the states have already been explained. Each body is one sentence. Do not remove labels or reduce the bodies to unexplained values.

Stacked mobile pair

All variants stack at narrow widths. Keep the first notice immediately before the second and retain the shared heading. Do not create a swipe interaction or tabs, because hiding one notice defeats the element’s purpose.

Parameters

“Source” identifies where an adapter obtains each value. The body mapping deliberately stores two complete notice records rather than two visually positioned columns.

The parent body’s first heading maps to title. Each nested item maps its first heading to label and everything after it to content; notice attributes hold tone and icon. The renderer must reject one, three, or empty notice items rather than silently filling or dropping a column.

Syntax and code examples

All formats preserve the same title, notice order, labels, bodies, tones, and sources. “Column one” and “column two” are presentation terms, not field names.

Portable Markdown directive

:::notification-two-column{variant=conditional}
## Choose the instruction for your publishing state

::notice{tone=neutral icon="draft"}
### Draft page

Use sample values only when they are visibly labelled as examples. Remove or replace every sample before publication.
::

::notice{tone=caution icon="publish"}
### Published page

Use verified values with a source and checked date. If verification is incomplete, withhold the claim.
::
:::

This element overrides the generic nested-item name with notice because the records have notice-specific tone behavior. The first parent heading supplies the shared title; each notice’s first heading supplies its label.

Hugo shortcode

No current production shortcode implements this exact paired-notice contract. Until an adapter exists, use semantic HTML like the rendered example. The intended Hugo notation is documented as:

{{< notification-two-column variant="conditional" >}}
## Choose the instruction for your publishing state

{{< notification tone="neutral" icon="draft" >}}
### Draft page
Use labelled sample values only, and remove them before publication.
{{< /notification >}}

{{< notification tone="caution" icon="publish" >}}
### Published page
Use verified values with a source and checked date.
{{< /notification >}}
{{< /notification-two-column >}}

The slash-comment form prevents this specification example from invoking a shortcode that does not exist. A future adapter must validate exactly two child notifications and render them in source order.

WordPress block

<!-- wp:amicited/notification-two-column {"variant":"conditional"} -->
<h2>Choose the instruction for your publishing state</h2>
<!-- wp:amicited/notification {"tone":"neutral","icon":"draft"} -->
<h3>Draft page</h3>
<p>Use labelled sample values only, and remove them before publication.</p>
<!-- /wp:amicited/notification -->
<!-- wp:amicited/notification {"tone":"caution","icon":"publish"} -->
<h3>Published page</h3>
<p>Use verified values with a source and checked date.</p>
<!-- /wp:amicited/notification -->
<!-- /wp:amicited/notification-two-column -->

A WordPress editor should present two fixed notice slots, allow reordering, and prevent publication when either label or body is empty. It must not let authors add a third notice merely because the grid block supports more columns.

Examples

Good: two real conditions with complete actions

Before importing
Download the current records and note the export time. The copy gives you a recovery point if field mapping produces an unexpected result.

After importing
Compare the imported record count with the source count, then inspect at least one record containing every mapped field. Counts detect omissions; the complete record detects shifted values.

This pair has one subject—safe import verification—and a genuine time boundary. Each notice names an action and explains what failure it catches. The second is longer because it contains two related checks, but both sides carry comparable responsibility and remain understandable when stacked.

Bad: false symmetry that demotes a risk

Helpful tip
Rename the export so it is easier to find later.

Important
Importing with “Replace all” permanently deletes existing records and cannot be undone. Back up the database, confirm the target, obtain approval, and schedule downtime before continuing.

The first notice is optional housekeeping; the second describes irreversible data loss and several prerequisites. Placing them in equal columns implies equal weight and makes the critical message look like one of two alternatives. Move the data-loss notice into a standalone warning before the control. Keep the filename suggestion as ordinary supporting prose.

Schema markup and accessibility

A two-column notification has no dedicated Schema.org type. Its content remains within the enclosing Article, TechArticle, or WebPage. Do not emit ItemList, HowToStep, Question, or Answer merely because two bounded records exist. If a notice contains content that independently qualifies for structured data, the enclosing post type’s schema rules decide the mapping; this element adds none by itself.

Use one labelled section when the pair belongs to the main explanation, or a labelled aside when both notices are complementary. Each child may be an aside or section with a real heading at the correct document level. Do not use ARIA alert or alertdialog: those roles announce dynamic, time-sensitive changes and are inappropriate for static editorial guidance.

The accessible name comes from the visible shared heading through native heading structure or aria-labelledby. Each notice label must be text. Color, border style, position, and icons can reinforce tone but cannot define it. If an icon is decorative, hide it from assistive technology; if it communicates information not present in the label, rewrite the label instead of relying on alternative text to repair the design.

DOM order controls meaning. Screen readers and mobile layouts must encounter the first notice and then the second. Do not reverse the visual order with CSS. At 200% text zoom and narrow widths, notices must stack without clipping or horizontal page scrolling. Links need descriptive labels, and multiple links must not be compressed into an unlabeled row of icons.

Writing rules

Write the relationship before writing the notices: “The reader needs two messages because the correct guidance changes by ___.” If the blank cannot be filled with a concrete condition, state, audience, time, or behavioral contrast, use prose.

• Use exactly two notices under one shared title.
• Keep the title to 3–12 words and each label to 2–6 words.
• Aim for 25–80 words per body; 120 words is an absolute maximum.
• Use one or two short paragraphs per notice and no more than one short inline link.
• Put the fact or condition first, its consequence second, and the action last when all are present.
• Use parallel label grammar: “Before launch / After launch,” not “Before launch / What administrators should do later.”
• Name conditions directly. Never write “left,” “right,” “the other option,” or “the box above.”
• Match tone to evidence. Neutral paired facts should not inherit green and red treatment.
• Make changing claims carry a date, version, plan, jurisdiction, or source as appropriate.

Comparable weight means that both messages deserve the same moment in the reader’s flow. It does not require identical sentence or character counts. Do not pad a short truth to match a longer one. If one body exceeds the other by more than roughly two to one, test whether the larger notice needs a separate section or whether the smaller notice is a false counterpart.

Never place a multi-step procedure, table, form, pricing card, testimonial, promotional call to action, long quotation, code sample, video, or nested component inside a notice. Never use the pair to soften legal, medical, financial, privacy, security, or destructive-action guidance. Do not imply that two conditions are exhaustive unless the content owner has verified that no third state exists.

Post types that use it

The postTypes frontmatter array is the source for this table. Inclusion means the element is available for a genuine two-notice case, not mandatory on every page of that type.

QA checklist

• Shared subject: One accurate title governs both notices without stretching scope.
• Exactly two notices: The source contains two complete records and no implied third state.
• Real relationship: Labels name a meaningful contrast, condition, audience, status, or time boundary.
• Independent meaning: Each notice remains clear when extracted with the shared title.
• No false symmetry: Both messages deserve comparable emphasis; neither is filler or a demoted critical warning.
• Correct placement: The pair follows its context and precedes the action or detail it qualifies.
• Safe neighbors: It is not adjacent to another split layout, table, tabs control, or two-column CTA.
• Useful labels: Labels use parallel grammar and never depend on left/right position or color.
• Length control: Bodies stay within one or two paragraphs and no more than 120 words each.
• Content restraint: No nested procedure, table, form, media, promotion, or complex component appears inside.
• Responsive order: Mobile, keyboard, screen-reader, and copied-text order match the authored sequence.
• Accessible semantics: A visible heading labels the parent; child labels are headings; static content does not use alert roles.
• Tone integrity: Styling reflects the actual meaning and does not turn neutral facts into good/bad judgments.
• Notation parity: Markdown, Hugo, and WordPress preserve the same title, labels, bodies, attributes, and order.
• Schema restraint: The element creates no unsupported structured data.

Reject the element if the shared subject, real relationship, or false-symmetry checks fail. Those are editorial defects that a renderer cannot fix. Rewrite the content as prose, separate sections, a standalone warning, or another purpose-matched element before adjusting presentation.

FAQ

The structured FAQ in frontmatter covers the implementation decisions most likely to be misunderstood: the notices need not be opposites or identical lengths, mobile order follows source order, severe risks remain standalone warnings, and the element creates no schema markup of its own.