Thinking Ahead for Emergency UI When Building a Website

Episode Summary

Executive Summary: The episode discusses how websites should be prepared for emergency or time-sensitive updates like snow days, pandemics, closures, and operational changes. Scott and Wes outline practical UI patterns—banners, pop-ups, alerts, dedicated pages, and delivery/scheduling options—plus the behind-the-scenes infrastructure needed so non-developers can update content quickly and safely without breaking design, caching, or deployment workflows.

Main Topics: Emergency UI / “Snow day UI”: The hosts propose that sites should be ready to communicate urgent updates through banners, pop-ups, or special pages when businesses or schools need to share rapid changes. Dismissible notices and persistence: They discuss how users should dismiss alerts once, how to store that state in cookies or local storage, and how to make dismissals content-aware so updated alerts can reappear. Design and content-editor guardrails: They stress that emergency content should still match the site’s design system and that WYSIWYG editors should be constrained so editors can’t create ugly or broken layouts. Page-level alerts and special informational pages: Beyond global banners, they cover per-page toasts/alerts and the need for clean, shareable pages with good slugs for detailed updates and public communication. Operational readiness and alternate channels: They emphasize having email newsletters, user dashboards, scheduling tools, and online ordering/delivery systems ready so businesses can pivot quickly during disruptions. Deployment, cache invalidation, and access preparedness: They highlight the need to document deployment steps, keep credentials accessible, know how to clear caches, and ensure clients can update sites without waiting on developers.

Key Arguments: Businesses should not need to contact a developer just to post emergency information; content editors need self-serve update paths. Emergency UI should be designed as a real product feature, not an afterthought, because bad mobile styling or hacked-in divs create a poor user experience. Dismissed alerts should persist locally, but the dismiss logic should account for changing content so outdated information can resurface when needed. Local storage is convenient for UI state, though browser behavior—especially Safari’s privacy restrictions—means teams should understand the caveats. Content editors should be constrained with styling and component defaults so urgent updates still look like part of the brand. Having pages with proper slugs, metadata, and clean markup improves discoverability and makes sharing urgent updates easier. Email is often a better emergency channel than social media because it reaches people who already opted in and avoids reliance on platform reach. Organizations should prepare adjacent infrastructure ahead of time—accounts, livestream tools, scheduling systems, online ordering—because emergency setup can take days or weeks. Developers should document deployment, cache clearing, and credentials so a panic update doesn’t fail due to forgotten setup or outdated tooling.

Data Points: Local storage retention in Safari: 7 days - Discussed as a privacy-related limit for some localStorage behavior in Safari, with caveats. Projector lifespan: 2,000–2,500 hours - Scott mentions typical bulb life when discussing a used projector purchase. Used projector price: $100 - A five-year-old 1080p projector was purchased inexpensively on Marketplace. Replacement projector bulb cost: $150 - Estimated replacement bulb cost exceeded the price of the used projector itself. Projector bulb hours remaining: 500 hours used - Seller reported only 500 hours on the bulb, implying substantial remaining life. Courses discount code: $10 off with code 'syntax' - Wes promotes his courses with a discount code. Level Up Tutorials promotion: 50% off - Wes mentions a 50% off subscription and store sale. Sentry promo code: 2 months free with code 'tasty treat' - Sentry sponsor offer mentioned during the ad read.

Pivotal Quotes: "how do we, when things go awry, especially our business that could be potentially closing down if we don't get enough sales, how do we access our audience much more easily?" — Wes Bos: Summarizing the central business problem: reaching users quickly during emergencies or disruptions. "you need some sort of unique identifier based on the content that is in that thing" — Wes Bos: Explaining how dismissible emergency banners should reappear when the underlying alert content changes. "don't give them the opportunity to have it look bad" — Scott Tolinski: Arguing for constrained editor tools and strong default styling so emergency content still matches the site design.

Implications: Web teams should treat emergency communication as a core capability: build reusable banners, alerts, pages, and workflows now, and ensure non-developers can update them fast. Preparedness reduces downtime, branding issues, and frantic deployment failures during crises.