webdevpuneet.com

Related Snippets

144 in Dashboards category
52–57 of 60

Environment Switcher with Color-Coded Persistent Banner

Admin Impersonation Mode Banner — "Viewing As" with Safe Exit

Batch Operation Progress Panel — Per-Item Success/Fail Tracking

Deployment Pipeline Stage Tracker

Database Connection Pool Monitor Tile

Alert Rule Threshold Builder

Environment Switcher with Color-Coded Persistent Banner — Production, Staging, Development

Environment Switcher with Color-Coded Persistent Banner · Dashboards · Plain HTML, CSS & JS · Live preview

CategoryDashboards
TagsKeyboard NavigationSVGAccessibilityDeveloper ToolsDashboard UI

Copy & paste

Source Code

<div class="demo" id="envDemo" data-env="staging">
  <div class="env-banner" id="envBanner">
    <span class="env-banner-text">You are viewing the <strong id="envBannerLabel">Staging</strong> environment</span>
    <div class="env-select-wrap">
      <button class="env-select-btn" id="envSelectBtn" aria-haspopup="true" aria-expanded="false">
        <span class="env-dot" id="envDot"></span>
        <span id="envSelectLabel">Staging</span>
        <svg viewBox="0 0 24 24" width="12" height="12" fill="none" stroke="currentColor" stroke-width="2.5"><polyline points="6 9 12 15 18 9"/></svg>
      </button>
      <ul class="env-menu" id="envMenu" hidden>
        <li><button data-env="production">🔴 Production <span class="env-menu-sub">Live customer data</span></button></li>
        <li><button data-env="staging">🟡 Staging <span class="env-menu-sub">Pre-release testing</span></button></li>
        <li><button data-env="development">🟢 Development <span class="env-menu-sub">Local/dev data</span></button></li>
      </ul>
    </div>
  </div>

  <div class="app-shell">
    <header class="app-header">
      <span class="app-brand">Console</span>
    </header>
    <main class="app-main">
      <p>The environment banner's color and label update instantly — production is intentionally the most alarming color to make it hard to run a destructive action there by mistake.</p>
    </main>
  </div>
</div>

Extend with AI

Take This Snippet Further With AI

The AI prompt for this one is for Patreon supporters ($3 a month, 7 days free), along with a site with no ads. Supporters enter the passcode once and it is remembered in this browser.

· Become a supporter

What's included

Features

Color-coded banner escalates from green (development) through amber (staging) to red (production), mirroring real risk level
Switching specifically into production requires an extra explicit confirmation step; switching out of it does not
Banner label and dropdown selector label are always updated together from one shared source of truth, never independently
Standard accessible dropdown pattern — aria-haspopup/aria-expanded, closes on outside click and Escape
Persistent banner stays visible above the app content at all times while a non-default environment is active
Each environment option in the dropdown includes a short descriptive subtitle clarifying what that environment represents
Asymmetric friction design deliberately targets the actual risk (accidentally ending up in production) rather than uniformly slowing every switch

About this UI Snippet

Environment Switcher — Color-Coding Risk and Adding Friction Where It Matters

Screenshot of the Environment Switcher with Color-Coded Persistent Banner snippet rendered live

Internal tools and admin consoles that operate against multiple environments (production, staging, development) create a real, recurring risk: an engineer or support agent forgetting which environment they're currently pointed at, and running a command or clicking a button that was only meant to be safe in a test environment. This snippet addresses that with two coordinated pieces: a persistent, unmistakably color-coded banner, and *asymmetric* friction on the switch itself — specifically harder to move *into* production than out of it.

Color escalation mirrors actual risk level, not arbitrary branding

The three environments use green (development), amber (staging), and red (production) — deliberately following the same "escalating alarm" convention used in traffic lights and hazard warnings, not a neutral or brand-driven color choice. This isn't just aesthetic: a user's peripheral vision registers a shift toward red far more readily than a shift between two similarly-saturated brand colors would, which matters because the entire point of the banner is to be noticed *before* an action is taken, not just to be technically present somewhere on screen.

Switching into production gets one more step than switching out of it

The click handler on each environment option checks specifically whether the *target* environment is production and the *current* one isn't — only in that specific direction does it insert a native confirm() prompt before proceeding. Switching from production back to staging or development requires no extra confirmation at all. This asymmetry is deliberate: the actual risk in this pattern isn't "switching environments" in the abstract, it's specifically *ending up in production without having meant to* — so the friction is placed exactly where the risk is, rather than uniformly slowing down every switch regardless of direction.

The banner label and the dropdown's own label are always the same source of truth

setEnvironment() updates both bannerLabel.textContent and selectLabel.textContent together, in the same function call, from the same ENV_LABELS lookup — there's no separate state tracked for "what the banner shows" versus "what the dropdown button shows." This guarantees the two can never disagree with each other, which matters specifically because the banner's entire job is to be a *trustworthy* indicator of the current environment; if it could ever show something different from what the dropdown itself reports, its value as a safety mechanism would be undermined.

A standard accessible disclosure pattern for the dropdown itself

The environment picker follows the same conventions as any accessible dropdown: aria-haspopup/aria-expanded on the trigger button, closing on an outside click, and closing on Escape — nothing about the environment-specific logic (the color coding, the confirmation gate) needed to compromise on these baseline accessibility behaviors.

Step by step

How to Use

  1. 1
    Observe the current environment bannerIts background color and label reflect the active environment — amber for staging in the initial state shown here.
  2. 2
    Click the environment selectorOpens a dropdown listing all three environments, each with a color-coded dot and a short description of what that environment represents.
  3. 3
    Select "Development" or "Staging"Switches immediately — the banner color, label, and dropdown label all update together in one atomic change.
  4. 4
    Select "Production" from a non-production environmentA confirmation prompt appears specifically for this direction of switch, requiring explicit confirmation before proceeding.
  5. 5
    Switch away from ProductionNo extra confirmation is required — the friction is intentionally one-directional, applied only when moving toward the highest-risk environment.

Real-world uses

Common Use Cases

DEVOPS
Internal admin consoles and ops tools
Any internal tool that can act against multiple environments benefits from making the active one impossible to overlook.
Database or API explorer tools
Query and data-browsing tools where running a mutation against the wrong environment could cause real, hard-to-reverse damage.
FEATURE
Feature flag and config management UIs
Tools managing feature flags or configuration across environments benefit from a clear, hard-to-miss indicator of which one is currently targeted.
SUPPORT
Support and debugging tools
Support agents troubleshooting across environments need a constant, unambiguous reminder of which one they are currently operating in.
Related: Idle Callback Task Scheduler
See the Idle Callback Task Scheduler for a related dashboards pattern worth pairing with this one.

Got questions?

Frequently Asked Questions

The actual risk this pattern protects against is specifically ending up in production without meaning to — not "switching environments" in general. Placing friction only on that one direction targets the real risk directly, rather than uniformly slowing down every switch regardless of which way it goes.

The escalating-alarm color convention is more immediately legible, especially in peripheral vision, than a shift between similarly-saturated neutral colors would be — and the entire point of the banner is to be noticed before an action is taken, so a more visually urgent color scheme for higher-risk environments directly serves that goal.

No — both are updated together inside the same setEnvironment() function call, reading from the same ENV_LABELS lookup, so there is exactly one source of truth and no code path where they could independently drift out of sync.

The environment does not change, and the dropdown menu closes — the banner and selector remain showing whatever environment was active before the switch attempt.

Swap the window.confirm() call for opening your own modal component, and move the setEnvironment(targetEnv) call into that modal's "confirm" button handler instead of the synchronous flow shown here, since a custom modal's confirmation is inherently asynchronous.

Add a new <li><button data-env="qa">…</button></li> entry to the menu, an entry to ENV_LABELS, and a new [data-env="qa"] .env-banner CSS rule with an appropriately risk-scaled color between staging and whichever environment it sits closest to in risk.