Aglet

Triage notification preference overload before adding controls

A settings page can offer control while still making every choice hard to evaluate. Triage the preference surface before adding another switch. Map events to channels and consequences, then identify where categories overlap or where a person cannot predict what muting a setting will do.

Establish what is happening

  1. Map the event inventory

    List notification events, channel, frequency, default, urgency, and user-facing label. Include one event controlled by multiple settings. Keep the resulting delivery behavior beside each control instead of relying on implementation names.

  2. Find the choice collisions

    Compare settings that mute the same event, use different words for one channel, or offer choices with indistinguishable outcomes. Note role and project context. A long form is not automatically overloaded if each choice has a distinct consequence.

  3. Set a simpler boundary

    State which categories deserve separate choice, which can be grouped, and what the fallback is when a person declines all optional updates. Preserve a useful control case. Stop when another reviewer can predict the effect of each setting.

What to carry forward

The triage output is a preference map with event, channel, frequency, default, and consequence. Stop when choices are distinguishable. If a setting’s effect cannot be traced, route the behavior question before designing a friendlier label.

Technical background: Apple developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow