Mixed usage of automatic saving for radio buttons might create a brittle user experience
Problem
Mixed usage of automatic saving for radio buttons might create a brittle user experience — as if anything can happen without warning
Origin
Follow-up from "adding radio buttons documentation" at https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/106#note_115355022
The question was: Should or should users not expect radio buttons to yield immediate results?
Further information
I made the case for them not to be (which is backed up by nngroup), but @tauriedavis suggested otherwise (which is backed up by existing UI in GitLab).
https://design.gitlab.com/foundations/saving-and-feedback comes into play here as it states we are anticipating saving by default as it has a positive impact on the perceived speed of the application. This is great but there is a potential discrepancies:
Documented safety measures only account for potential data loss. There is no documentation on how we handle feedback to the user that we will not auto-save data that might have a financial, security, or privacy impact before the user actually interacts with the element.
Illustrating situations
When using radio buttons as an action
graph LR
A[User clicks element]
C[System performs action and saving is implied]
A --> C
Radio button usage done as documented
graph LR
A[User clicks element]
B[System saves state]
C[System gives feedback]
D[System performs action]
A --> B
B --> C
B --> D
Same situation but now handles sensitive information...
graph LR
Z[user sees element]
X[user is unsure if information <br> is saved immediately yes or no <br> when using the element]
A[User clicks element]
B[?]
Z --> X
X --> A
A --> B
Quoted information from sources
from https://www.nngroup.com/articles/checkboxes-vs-radio-buttons
Use checkboxes and radio buttons only to change settings, not as action buttons that make something happen. Also, the changed settings should not take effect until the user clicks the command button (labeled "OK" for example, or "Proceed to XXX" where "XXX" is the next step in a process).
Conversely, violating the standards makes the user interface feel brittle — as if anything can happen without warning. Say, for example, that you assume you can click on a radio button without any immediate impact, and can thus consider your choices after making a selection but before hitting "OK." In such a case, it's jarring when a website violates this standard and unexpectedly moves you to the next page once you enter a selection. Worse, it makes you fear what may happen as you work with forms elsewhere on the site.
https://design.gitlab.com/foundations/saving-and-feedback
Never apply to whole forms (example: adding a personal access token needs a name, expiration date, and access scope; it doesn’t make sense to auto-save the token name field individually). The auto-save method should ideally be only used for data that affects the user editing it. Auto-saving shouldn’t be applied to data that might have financial, security, or privacy impacts, example: changing password or changing the confidentiality of an issue.
Instant feedback simply means that we show the expected result of a successfully saved change even before that change has actually been saved—we anticipate that the change will be saved successfully so we show it in the UI immediately. This has a positive impact on the perceived speed of the application. An example of a case when a successful result is expected is changing the assignee on an issue.
How does success look like?
We prevent the user interface from feeling brittle when using radio buttons — as if anything can happen without warning
Links/Mentions
@tauriedavis @matejlatin @pedroms (From prior discussion/involvement)