hackforla
Design: Create Style Guide Presentation (Radio Buttons/Checkboxes)
Dependency
- [ ] #1850 ( Waiting on Stakeholder decision of which column dropdown will be chosen)
Overview
The style guide currently does not mention any styling for radio buttons and check boxes. Add these to the Figma Design system and style guide presentation.
Details
The style guide does not explicitly address the styling for radio buttons, though the Example Modal Dialog on the "Dialog Boxes and Modals" page does implicitly show an example from the app.
However the example uses the "Navy Blue - Primary (#002E6D)" color for the radio buttons while the website uses the default browser styling for them. The default styling is used in several other UI elements such as checkboxes and dropdowns.
So we need to decide if we should change the styling of these elements to keep it consistent with the colors of the design system or keep it browser default since it's the style users would already be familiar with.
Action Items
- [x] Determine the styling for radio button, checkboxes and other similar UI elements:
- [x] Research examples where it has been changed or kept the same.
- [x] Decide on a style and create prototypes.
- [x] Add a section for these styles in the design system
- [x] Review with Product/ Dev/ Research and iterate if needed based on feedback.
- [ ] If the style is different than dev, open issues for dev to update the design.
- [x] Update the style guide to add the new design.
- [ ] Once finalized, get Stakeholder sign-off via the stakeholder meeting slide deck.
Resources/Instructions
09/25/2024 Iteration 1:
- Design on left is suggested design/ design based on other sections on Figma
- Design on right is current design on dev when viewing on a Chrome Browser on windows.
Image for Iteration 1
Feedback received:
- The "primary blue" used in dropdowns and checkboxes could make the page appear too busy with the same color section headers on page 4 of calculator.
Details
- Checkboxes and radio buttons should have similar appearances because they appear together on filters in my projects page.
Details
09/27/2024 Iteration 2:
- Changed the checkboxes and radio buttons back to dev styles
- Changed the dropdown color to dev style but kept the increased padding
Image for Iteration 2
Waiting on stakeholder feedback
Current slide is approved by stakeholders, but we might need to add a multi-select dropdown from the filters to this list based on whatever's finalized
Added the nested checkboxes from My Projects Page to the style guide presentation and design system on Figma:
Hi @NilakshiS. The nested checkboxes in the Dev site do not have horizontal scrolling. Should they? Or should we change the style guide to reflect the fact that the text within each option wraps to a second line when its length is longer than than width of the container?
@thetanmancan This issue has a 'waiting for stakeholder label' but the last comment you made is for NilakshiS. I see this issue is in the deck with an image with a horizontal scroll... so I am confused.
Hi @thetanmancan I referenced an old image for the design, but I see a horizontal scrollbar on the dev site. It's a bit inconsistent, there's one on the admin notes filter, however I don't see any on address filters. I can remove the horizontal scrollbar, but I'm not sure how we're planning on handling longer text, or do we not expect data longer than two lines?
Here's some examples from the dev site where the longer text wraps:
Horizontal scrollbar on the admin notes
The checkbox size is the same here, but the wrapped text is middle aligned to the checkbox
The checkbox is smaller here,
No scrollbar on address column
The checkbox size is the smaller here and the wrapped text is middle aligned to the checkbox
@NilakshiS I tested Admin Notes filter and did not see a horizontal scroll bar, even when I zoomed in on my browser.
Check it out
However, how the overlay behaves right now might not be a relevant conversation because I think how we're dealing with text strings in filter overlays is going to be changed. At least for some columns, there will be a 25-character limit in the width of the filter overlays according to #1651 , after which an ellipsis will be added and the rest of the text will be cut off. I will ask John at today's meeting about whether that limit is meant to apply to all column filters. If it is, the horizontal scroll bar won't be relevant, but even if it isn't, I think the text will still end up wrapping like it is now, in which case the horizontal scroll bar still won't be relevant, but I will have to confirm with John.
If we end up not having a horizontal scroll bar, we can remove it from the design system and I'll run that by the stakeholders in our next meeting. As for the vertical scroll bar, that's determined by the browser anyways, right? Or can our site dictate how that looks?
Hi @entrotech. At one of our meetings, Bonnie requested in #1651 that the overlay for the Admin Notes filter only display 25 characters for item names, followed by an ellipsis. Will that same logic be applied to all filters?
Hi @NilakshiS. Due to the advent of #2043, it seems like horizontal scroll bars will not be necessary for lists of nested checkboxes, so I removed the horizontal scrollbar from our design system mockup.
No horizontal scroll bar
I also noticed that the mockup includes dropshadow on the list of checkboxes, but the inclusion of dropshadow is inconsistent with the other components being shown in the same section on the style guide, and the doesn't seem to be included anywhere in the implementation of the list of checkboxes on the Dev site. Therefore, I'm removing the dropshadow unless you tell me that it needs to be there for some reason.
If you think the 25-character limit within lists of nested checkboxes is something we should include in the style guide, please let me know and I'll make an issue for it. Thanks.
Hi @NilakshiS. I noticed while testing these styles in the Dev site that we use two different colors for each of the components listed: one upon hover and one upon selection. This highlights a number of problems with our style guide.
- With the exception of dropdowns, none of the components in the "Radio buttons, checkboxes, and dropdowns" section of the style guide list a color for hover and a color for selected.
- The color "Radio button default" that we have in Figma is not listed in the color palette.
- The selection color for dropdowns is different than the one used for radio buttons and checkboxes. Is this inconsistency intentional?
Could you please reconcile these issues in the design system? I'll move this issue back to In Progress in the meanwhile. Thank you.
Hi @thetanmancan thank you for the updates and making those changes!
- I suppose the dropshadow got carried over from older designs and I didn't notice, thanks for catching that!
- About the 25-character limit, I know this number was discussed in the meetings but I do not see it anywhere on the dev issue #2043 . If we're sure that this will be the character limit for all the nested checkboxes displays, we can add it to the style guide. I don't think it needs a new issue, it's related to this issue so I'll add it once the limit is confirmed.
- About the different colors and hover styles for these components, these are the default dev styles and we decided they looked good as they are, instead of using the colors from the color palette. Check the comment here for more info. The reason why I added "Radio button default" was to match these styles, these designs are not custom and left to dev implementation, so I decided to not add this to our color palette.
However, now that I rechecked these, I realized that there has been a mistake, I was under the assumption that these are ReactJS styles (which would look the same across browsers) but instead these are browser native styles. The design as it currently looks is how it looks on Chrome Browser running on windows OS.
Radio Buttons and Checkbox on different browsers
-
On Chrome, Windows OS:
-
On Edge, Windows OS:
-
Note: Checkboxes have the same default color as radio buttons, so they are being hovered on to show the Hover state style
- The next steps could be either to customize these like how we did for dropdowns (that's the reason why they have a different selection color, check #1785) or remove these from the design system, since the design is dependent on the browser.
- On side note, you are right about missing hover state designs, they are in mockups but I missed adding them to the slide. If we decide to customize, I'll add the hover state design for all of them.
Hi @NilakshiS.
- In the comment section of #2043, I addressed John with a question about the specifics of the 25-character limit, which is detailed in the first comment of the issue. Once he answers, I'll let you know so that you can update the style guide.
- It seems pretty clear to me that we need to have a design for radio buttons and checkboxes across browsers, not only because it looks like radio buttons and checkboxes are grayed out when they are selected on Edge, but also because there should be some color consistency between dropdowns and radio buttons and checkboxes. Do you think this is something we need to run by production and development before developing mockups?
- I don't see any mockups for hover state designs in the Figma style guide, or at least not for radio buttons an checkboxes. Can you point them out to me?
To address the above comment:
- #2043 and #2063 will address the question of filter width. While filter width needs to be documented in our style guide, it is not within the scope of this issue.
- @NilakshiS: I will keep this issue open until the following two issues have been resolved for the radio buttons, checkboxes, and dropdowns in our design system:
- They do not take hover states into account.
- There is no color consistency across the different components.
@NilakshiS Now that we have clarified scope, please provide update
- Progress: "What is the current status of your project? What have you completed and what is left to do?"
- Blockers: "Difficulties or errors encountered."
- Availability: "How much time will you have this week to work on this issue?"
- ETA: "When do you expect this issue to be completed?"
- Pictures or links* (if necessary): "Add any pictures or links that will help illustrate what you are working on."
- remember to add links to the top of the issue if they are going to be needed again.
- Progress:
-
I created some mockups with different colors for radio buttons and checkboxes. We do not have a lot of choices for colors in our palette apart from greys and blues, both of which do not work well with these elements because it makes them look disabled or blends them with other UI elements on page. There's also green but it looks similar to the primary action buttons then.
Mockups with grey, blue, and green
-
The only other choice would be to use the bright blue that we already use for dropdowns
#1967D2, or stick to the blue that Chrome Browser uses#0075FF.Dropdown blue vs. Chrome Blue for radio buttons and checkboxes
-
I recommend using the blue we already use for dropdowns.
-
Created mockups for Hover states for checkboxes and radio buttons
Default and Hover states, the Hover states are on the right
Dropdown Blue: Colors used:
- Background: White
#FFFFFF - Default, unselected state outline: Grayscale/Gray
#939393 - Hover, unselected state outline: Grayscale/Black
#000000 - Default, selected state:
#1967D2 - Hover, selected state:
#1450A4
Chrome Blue:
- Background: White
- Blockers: No blockers, need feedback for the final color to choose
- Availability: about 6 hours this week
- ETA: 1 week
- Pictures or links* (if necessary): Link to these mockups on Figma
@Tristan Camacho and @NilakshiS re https://github.com/hackforla/tdm-calculator/issues/1839#issuecomment-2634753758
It looks like @NilakshiS is recommending the default blue for drop downs become the permanent check box and drop down color. I cant remember if we decided we were going to run this through research to have them get a preference test. Do you remember?
@ExperimentsInHonesty I don’t recall bringing up the need to run our designs by research, though we can if you think that’s prudent.
Product needs to make a dev issue to create a class for the check box and drop down selection color.
implement: make the default medium blue, therby making it the same for everyone, by specifying it instead of the current situation which is windows gets medium blue, mac gets gray.
@thetanmancan if design prefers the darker blue (I kind of like it but don't have a strong preference either way). Then the question is just is the darker blue more pleasing or does it make it easier or harder for people to use the selectors. And that can get answered by research doing a simple preference test through https://lysna.com/ and if we do go with the darker, then they would have to test it with users during normal usability testing once its in place. Does design have a preference for the darker and want us to do this?
25-02-05 Design meeting feedback:
The team prefers the bright blue used for dropdowns #1967D2. This is because the grey option appears disabled, the dark blue in our design system blends with the column header, and the green closely resembles the primary action button. Currently, the suggested blue and the hover state blue are not part of our design system.
-
Use this for all checkboxes, radio buttons and dropdowns Default and Hover states, the Hover states are on the right
Dropdown Blue: Colors used:
- Background: White
#FFFFFF - Default, unselected state outline: Grayscale/Gray
#939393 - Hover, unselected state outline: Grayscale/Black
#000000 - Default, selected state:
#1967D2 - Hover, selected state:
#1450A4
- Background: White
This is approved.
- [x] Dev will make an issue
- https://github.com/hackforla/tdm-calculator/issues/2111
- [x] Design will make an issue (or find one if its already made), and link it here and then close this issue
- https://github.com/hackforla/tdm-calculator/issues/1998