dash.dare.co.uk — “View all” rotating-batch pattern for top-N card sections (parked 2026-05-19)
DARE.CO.UK · PARKED SKETCH · 2026-05-23
Mirrored from ~/.claude/.../memory/parked_sketch_dash_view_all_rotating_batches.md. This is a design sketch parked for future build — read for context, not as a current deliverable.
UI polish for dash.dare.co.uk’s top-countries + status-codes + top-paths card sections. Today they show top N (typically 5–10). New pattern: a “View all” link advances to the NEXT batch (e.g., #11-20), click again → #21-30, etc., rotating back to #1-10 at the end. Preserves at-a-glance vertical budget while still surfacing the long tail. Same pattern across all card sections with the same data shape (ordered list, top-N truncated).
Dan, 2026-05-19: “small nit-pick to park for later - small addition, build more cards using the existing pattern, when you select ‘view all’ it reveals the next batch of cards, and rotates through them until you return to the top countries, same for status codes.”
The pattern
Today’s behaviour on dash.dare.co.uk’s card sections (top countries, status codes, top paths, top user agents, etc.): - Card shows top-N entries (typically 5 or 10) - The rest are truncated, invisible
The proposed pattern: - Card still shows top-N entries by default - A “View all” link/button at the bottom of the card advances to the NEXT batch (positions N+1 through 2N) - Subsequent clicks advance further (2N+1 → 3N, then 3N+1 → 4N, etc.) - After the last batch, the link wraps back to batch 1 (the top-N) - A small position indicator (“11–20 of 47” or “page 2/5”) clarifies where you are in the rotation
Why this is the right shape (not “expand all” or “load more”)
| Pattern | Pro | Con |
|---|---|---|
| Expand all | Shows everything at once | Blows the vertical budget; users scroll past the rest of the dashboard |
| Load more (cumulative) | Shows more without losing context | Vertical budget still grows; long tails (47+ countries) become unwieldy |
| Rotating batches (instant swap) | Vertical budget stays FIXED; user can scan the whole list in N clicks | Slightly less discoverable than “expand” — needs a clear “page 2/5” indicator |
| Sliding carousel (animated horizontal slide) | Same fixed-budget win; the slide animation telegraphs “more exists” and gives the user spatial intuition of position-in-the-set | Slightly more JS; needs CSS transform/transition; horizontal scroll on touch devices is a known UX foot-gun |
The rotation pattern matches dash.dare.co.uk’s overall design philosophy: dense, scannable, no infinite-scroll, fixed vertical real estate per section. A reader who only ever looks at batch-1 (the top-N) sees the same as before. A reader who wants to see more can rotate through without leaving the page or losing the at-a-glance overview.
Sliding carousel sibling pattern (Dan-flagged 2026-05-19 from Cloudflare dashboard)
CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF’s own dashboard uses a [★] [+] [...] [→] icon row at the top-right of card strips — the → arrow slides the visible cards to reveal the next batch (visible=3, total=6, click → shifts 3 remaining cards over). Same UX goal as rotating-batches but with an animated horizontal slide instead of an instant swap.
Trade-off vs the instant-swap pattern already sketched: - Pro: slide animation gives spatial intuition — user feels position-in-the-set; cards entering from the right + leaving on the left reads as natural pagination - Pro: the arrow affordance is universally legible; “View all →” needs the “→” to be load-bearing anyway - Con: CSS transforms + transition timing; mobile touch users may try to swipe and trigger horizontal page-scroll instead of the slide - Con: harder to print (instant-swap just shows batch 1; slide mid-animation captures awkwardly)
Decision point at build time: instant swap is the safer default; sliding carousel is the polish-pass variant. Consider sliding when (a) the strip is wider than the viewport on desktop and the cards genuinely benefit from horizontal flow, or (b) Dan asks for it explicitly.
Card sections in scope (sharpened 2026-05-19 after screenshot review)
Two distinct shapes — the rotation pattern splits accordingly:
Shape A: rotation through batches of items — applies when there are many MORE items than the 4 visible: - Top countries — 4 visible (US/FR/SG/CA), long tail of 30+ (DE/UK/IN/AU/etc.). Rotation: batches of 4. - Top paths (when added to dash) — long tail of hundreds. Rotation: batches of 4-10. - Top user agents (when added) — long tail of dozens. Rotation: batches of 4-10.
Shape B: rotation through internal breakdowns — applies when the visible cards already show the full first-level set, but each card hides a deeper layer: - Status codes — only 4 categories total visible (2xx/3xx/4xx/5xx). No batch-2 of categories. But each card hides specific-code breakdowns: “200 dominant” actually contains 200/204/206/etc., “403 dominant” contains 400/401/403/404/451/etc. Rotation per card: summary view → specific-codes view → back to summary.
When implementing, both shapes share the “View all →” affordance but route to different cycle logic.
The “View all →” link ALREADY EXISTS in the rendered HTML (top-right of each section, accent red). The build is the rotation BEHAVIOUR wired to the existing link, not the link itself. ~30 LOC JS + ~15 LOC CSS + ~10 LOC per renderer (Shape A only — Shape B is per-card data restructuring).
Implementation sketch (when greenlit)
JS-light approach (no framework):
1. Each card section already has a <table> or <ul> with the top-N rendered. Server-side: render ALL items, then add data-batch="1", data-batch="2", etc. to each row. The CSS hides batches > current.
2. A small <button class="view-all">View all (1/5)</button> at the bottom of each card. Click increments the current batch via data-current-batch. CSS reveals only that batch’s rows.
3. After the last batch, the button cycles back to batch 1 + label resets.
4. Total addition: ~30 lines of JS, ~15 lines of CSS, ~10 lines per renderer to emit the data-batch attributes.
Print mode: show batch 1 only (the top-N) — matches existing behavior.
Resume conditions
Build when: - dash.dare.co.uk gains a visible long tail that’s currently invisible (e.g., the country distribution becomes interesting beyond top-10) - OR Dan asks for it explicitly (it’s already a nit-pick today; build when it actually surfaces in his use) - OR an audrey/dogwood dashboard inherits the same card pattern and wants this feature first
Until then: shape documented, decision-ready. ~half-day of work when triggered.
Sibling memories
feedback_report_granularity_inverse_to_health.md— same philosophy applied differently: site health uses 10 tripwires fixed; dash cards use top-N rotating. Both preserve attention budget.feedback_show_the_future_grey_it_out.md— sibling UI rule (if it exists) — surface what’s NEXT without committing the space yetparked_sketch_dashboard_audreyinc_com_ab_editorial_ads_2026-05-18.md— same parked-UI-polish queuefeedback_augmented_session_report_pattern.md— fixed vertical budget for high-signal surfaces is the same shape Dan likes in reports