E6.02.2stacked bannersdesign

Stacked banners squeeze content

Aliases: alert stack · multiple banners · banner pile-up

What it is

Once banners persist, each one takes a fixed strip of height from the content. Stacking is several banners occupying that slot at once, pushing the main content, a table’s first row, or a filter bar below the first viewport. The issue is not whether a banner should stay; it is how many may stay at the same time. One expiry reminder is tolerable. License, read-only, sync failure, and trial expiry stacked four deep means people must clear notices before they can see the table they came for. The status channel becomes a navigation obstacle.

Why it happens

Viewport height is a hard budget. A banner injected at the top of the flow shifts every pixel below it. On a phone, with system chrome and an app bar already present, two or three banners can push the first item past the fold. People arrive looking for content, not for notices. When content is displaced, banners become the only visible objects and reading order inverts: digest exceptions first, start the task second. Worse, banners often come from separate subsystems with no coordinator—whoever returns first claims a layer. Dismissing one reflows the rest, the list’s scroll offset jumps, and people think they lost their place. The cost of stacking is not only missing content; it is spatial control lost to reflow.

Where it stops holding

Different phrasings of the same situation should not each take a row—“offline” and “saves will fail” are one fact, and merging them does not lose information. When a page-level banner and an app-level banner describe the same scope, keep the wider one. Dashboards and monitoring walls whose content is status strips are a product shape; “don’t squeeze content” cannot cut them away. On a narrow screen a single long banner wrapping to three lines is visually a stack even with one object. A banner inside a full-screen dialog can push that dialog’s buttons out of reach, which is worse than squeezing a list.

Applying it

  • Cap how many banners may be visible at once, usually one, two at most; fold extras into “n more” or a single summary that expands to detail.
  • Merge same-source or same-scope messages before they enter the slot; do not let the license module and the sync module each post the same restriction.
  • When a banner appears or leaves, lock the content’s scroll anchor so closing one does not jump the list.
  • Verify on a real first viewport: overlay every status that can be true at once. If the first content row or the primary action is gone, stacking has already failed.

Related

  • Within the group: E6.02.1 A banner stays until it is handled or dismissed · E6.02.3 A banner must state its scope of impact
  • Adjacent: E6.04 Global status messages · E6.11 Badges and dots · E4.01 Cards
  • Search terms: stacked banners · viewport budget · layout shift

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E6.02.2