-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
[UX] Toggles #14147
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
[UX] Toggles #14147
Conversation
Go to Forms > New > Toggle the option Kiosk mode
Go to Segments > New > Toggle Visible for other users > Check the label for No (Only me)
Go to Points > Point Actions > New > Toggle Is repeatable? and see two different labels
Go to Reports > New > Toggle Visible for all logged-in users to see the No label
Go to Custom Fields > New > Toggle the Indexable field
Go to Custom fields > New > Check tooltip for Unique identifier
This reverts commit 14187a4.
This reverts commit 4c0285b.
|
@LordRembo I investigated a bit more of my history, we had an accessible version in this commit using the button idea the issue is that it would cause an absurd effort to fix all JS functions that depends on this radio structure used over the years and might not generate a stable result (e.g. we might miss some functionalities along the way that will just break for the end user) I'm avoiding this kind of change tbh, but I can give access to my fork if you see an easy way to do it Checked these: Tested adding to Twig and this to JS, but it'd need further validation What do you think? |
42caa79 to
1fbc44f
Compare
1fbc44f to
ca64d8e
Compare
|
@abhisekmazumdar new test failing here |
|
@andersonjeccel I fixed the tests in #14157. Please review. |
|
@abhisekmazumdar so probably no fix needed here anymore |
kuzmany
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did basic tests, and works for me.
Description
Switches are going to replace the Yes/No buttons, keeping the same backend way to handle data saving to ensure compatibility with absolutely all existing functionalities and JS code.
This PR also features a mini toggle where space is an issue, when you're adding them to tables or Reports filter rows.
Have a look at this example (not a real implementation, just made it look small to show). The "Use theme style" field is using a small toggle when compared to the others.
The beauty here is the UX improvement, as it allows to have custom labels according to the field status. THey help to understand the consequences of each state. Look at the status labels for the Kiosk mode:
In many cases, they can replace tooltips.
These custom labels are set using the existing PHP functionality. We have a class for the Yes/No buttons that provides a default value for no_label and yes_label (below):
The custom labels can be set when adding fields to the builder, providing a new translation string for each:
📋 Steps to test this PR: