Browser Notifications — Permission UX and the Notification API

Notifications are powerful and universally abused. The API is easy; the UX discipline is the skill.

The API

// 1. check support + current state
if ("Notification" in window) {
  Notification.permission;   // "default" | "granted" | "denied"
}

// 2. request ONLY on user action (see UX rules)
const perm = await Notification.requestPermission();

// 3. show
if (perm === "granted") {
  new Notification("Streak saved! 🔥", {
    body: "Day 12 of DSA practice complete.",
    icon: "/icon-192.png",
  });
}

The UX rules that decide everything

• Never ask on page load. Users hit Block reflexively — and Block is nearly permanent (buried in browser settings to undo)
• Ask after a user action that implies wanting them: "Remind me daily" button → then request
• Explain the value first in your own UI, then trigger the browser prompt — double-opt-in doubles grant rates

Local vs push

The above = local (page must be open). True push-when-closed needs a service worker + Push API + a server holding subscriptions — a weekend project on top of the PWA basics. For a study-streak reminder feature, local notifications + a PWA cover a surprising amount.