Category control needs its own entry point, independent of system mute

What it is

Category control must be independent of the system-level mute switch. The system switch expresses a global, momentary intent; in-app category settings express a durable choice about one class of content. The two cannot share a single state, or the act of muting erases the category choices.

Why it happens

The two controls differ in semantics and scope: system mute is temporary, global, and fast to toggle; category settings are durable, local, and reached inside an app. Coupling them produces errors in both directions—losing long-term preferences after a temporary mute, or changing system state while adjusting a category. Storing them separately also lets users toggle system mute without fear of overwriting settings. The implementation key is giving durable preference and temporary state their own storage and precedence.

Studying it

Design a state-transition study: have users set category preferences, then toggle system mute and restore it, and observe whether preferences survive and whether users notice a change. Measures include preference retention, accuracy in identifying which control is in effect, and post-restore behavior. Settings instrumentation adds a signal: users repeatedly reconfiguring the same category usually means state is being overwritten.

Where it stops holding

When the platform offers a unified per-app or per-category control surface, duplicating it inside the app creates two competing controls; the platform layer should own it, with consistent semantics. If a sound is designated non-mutable, the system switch should not remove it in the same way, and the exception rules on both sides must align.

Applying it

• Store durable category preferences separately from temporary system state so neither overwrites the other.
• Show inside the app which control is currently in effect—its own setting or the system switch.
• After system mute is lifted, return to the previously configured categories rather than defaulting everything back on.
• Verification: set category preferences, toggle system mute and restore, and check retention; then confirm the interface states the active source truthfully.

Related

• Within the group: D2.11.1 Users need to control sound by category rather than all-or-nothing · D2.11.4 Once sound is off, other channels must carry what was muted
• Adjacent: D2.04.3 Silent contexts need absolute silence, not reduced volume · D3.13.3 Users need separate control over whether haptics follow silent mode
• Search terms: per-app sound control · system mute · state persistence