-
-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI exploration: consistent UI pattern for user confirmation #1683
Comments
Just discussed this with @shalver-tp in person: we’ll do a time-boxed UI exploration here (~½ day) to make this topic more concrete and tangible, and to have a better basis for a discussion. The result of this exploration should include a brief summary of the current situation, a few graphical mock-ups to compare various options of UI patterns, and some thoughts and ideas how we could potentially consolidate the patterns that we have in place currently. Based on that, we can see and decide whether and how we move forward with actually working on this. |
I don’t think we follow a deliberate pattern in the UI as to when we require confirmation after button clicks in dialogs. E.g.:
<security-dialog>
component, we have a confirmation prompt when toggling off the auth requirement.Not having any confirmation for these kinds of operations actually makes me feel slightly uneasy. (I’m not sure how e.g. customers feel about that, though, or whether we have ever received “angry” feedback about this.)
In any event, I think we should define our desired UX pattern for user confirmation in the style guide, and then roll out the rules in the entire UI.
UI-wise, there are different patterns for user confirmation. Apart from the aforementioned separate confirmation step/prompt, there are also more light-weight patterns we could consider.
The text was updated successfully, but these errors were encountered: