A user told us one of our Windows settings did not support their laptop. That report changes what I want from a settings screen: before asking whether a tweak is on, the UI should establish whether it belongs on this machine at all.
A toggle has two positions. Applying a system setting has more than two possible outcomes.
“Unsupported” and “failed” need different next steps
Unsupported means the app has enough information to know it should not attempt this operation on the current system. Failed means the operation was eligible, but an attempt did not complete as intended.
If both become a red “Something went wrong”, the user has no useful choice. Retrying an unsupported operation will not create the missing capability. Hiding a genuine failure behind “not available” loses information the developer needs.
There is also an unknown state. A capability check that could not run is not evidence that the hardware lacks the feature.
These are design rules I would use for a Windows settings tool, rather than a claim about how every setting in our app currently behaves.
Describe what you have actually confirmed
I would give each state a specific meaning:
| State | Evidence | What the user sees |
|---|---|---|
| Checking | Capability query is running | “Checking support…” |
| Unknown | Support could not be determined | “Couldn’t check support. Try again.” |
| Unsupported | A required capability is absent | The missing requirement and a disabled Apply button |
| Ready | Requirements are met | Current value and the proposed change |
| Applying | The write is in progress | A busy state that prevents duplicate requests |
| Verifying | The write returned; readback is pending | “Checking the saved value…” |
| Pending restart | The setting is saved but activation needs a restart | Saved value plus the restart requirement |
| Applied | The verification available for this setting passed | The value that was confirmed |
| Failed | A check, write or verification failed | The failed step and a useful recovery action |
“Applied” needs a definition per setting. Reading back a stored value may confirm persistence; it does not prove that a running game is already using it, or that performance improved. If activation cannot be observed, say “Saved” and explain the next step instead of implying more evidence than you have.
Keep capability separate from preference
I would store the user's desired value separately from the observed value and the support result. Otherwise a checked box can quietly stand for three different things: “the user asked for this”, “we wrote it”, and “we confirmed it”.
For a settings tool, those distinctions matter more than a satisfying green animation.
A support reason should also be specific to the setting. “Laptop” is not a useful universal rejection rule. The relevant requirement might concern a device capability, a Windows feature or an available backend. The UI should explain whichever requirement it actually checked.
Test the paths that cannot end in green
For this design, I would start with four cases: the capability query fails; a required capability is absent; the write succeeds but readback disagrees; the value is saved but needs a restart.
Each case should produce a different visible result. The unsupported case should never call the write operation. A duplicate click should not start a second write while the first is pending. A failed verification should not display the desired value as a confirmed value.
That laptop report is a useful reminder: a good settings UI helps a user understand why a change cannot happen. The Apply button is only one part of that job.
Top comments (0)