Context within the field · inline origin chips

Source · Dan, 2026-06-04

"Not sure how this was encoded into the json, BUT it's a worthy pattern — you added where the traffic is originating. Very nice touch — helpful, and it's context-specific, within the field."

The problem

A diagnostic row that shows what happened — path · count · status codes — leaves the next obvious question, where from?, to be answered by a click, a panel switch, or a fresh query. By the time the reader navigates to a separate "by country" or "by user-agent" view, they've lost the row that prompted the question. The cost is small per row and large across a dashboard that has dozens of them. The pattern applies beyond analytics too: any field that names a quantity or a claim can embed its origin inline rather than forcing a detour to find it.

The element, in-page

The live copy below runs in a sandboxed iframe (the pattern-preview primitive). It shows a realistic probe-analytics table where each row earns a sub-row of inline origin chips — country codes and scanner UA labels scoped to that row's data. Chips appear directly beneath the parent row; no new panel, no click required. Hover any chip to see the lift; the parent row carries the "what", the chip strip carries the "where from".

Where it applies

Probe / diagnostic surfaces on dash.dare.co.uk where "who's poking this?" follows immediately from the count — /ip, /cf, /trace, healthchecks, sandbox endpoints.
WAF / firewall rows where the country + bot signature is the actionable context — not a separate panel.
Email and webhook delivery dashboards — a failed-delivery row earns a chip showing the recipient domain or retry-source UA.
Any table where the parent row is a category and the chips name the actors inside it, whenever the actor breakdown fits in a handful of pills.
Skip it when every row in a 200-row table would get chips — pick only the rows where origin earns its space, and let page-wide breakdowns handle the rest.

Reusable elements

Country chip — .chip.chip--country: cream field, green border, mono font. Carries an ISO-2 code + hit count. Top-8 per row keeps the strip scannable.
Scanner / bot chip — .chip.chip--bot: warm amber tone distinguishes non-browser callers from geographic origin. Populated by a small UA-pattern dict (HeadlessChrome → headless-chrome, python-requests, curl/, etc.).
Chip separator dot — .chip-sep: a plain · between the country group and the scanner group; absent when either group is empty.
Hover lift — translateY(-1px) + box-shadow on :hover: signals interactivity without adding click targets (chips are informational, not navigational).
Sub-row layout — a second probe-data-level block immediately beneath the parent row, sharing left-gutter padding so chips read as belonging to that row, not the table body.
Scoped fetch — the GROUP-BY query is filtered to probe paths only; browsers (no UA match) drop out so the chip strip shows only meaningful signal.

Reference

Source: Dan, 2026-06-04 — spotted during a dashboard iteration: "you added where the traffic is originating — context-specific, within the field."
In use / example: dash.dare.co.uk — "Diagnostic probes" section, chips on /ip / /cf / /trace. Implementation in dare_cf_analytics.py: fetch_probe_origins(), _SCANNER_UA_PATTERNS, probe_origins_row().
Reusable elements: Country chip · scanner/bot chip · separator dot · hover lift · sub-row layout · scoped GROUP-BY fetch (listed above).
Origin: dare.co.uk analytics dashboard, 2026-06-04 · dare-pipeline dare_cf_analytics.py.