Pair to Define Toggle Control

[mcharg]

This will be a test for processes for creating new visual design.

[jenniferthibault]

Last sprint, we found that the component we thought was an existing toggle was actually a tab in disguise. We also identified styling new things as an area of low confidence on the team in last sprint's workshop, so this makes a great opportunity to work on both areas.

The upcoming disbursement data wireframes incorporate toggle components, so Shannon and I will pair through styling a new toggle component for the site together.

[mcharg]

@jenniferthibault Now that we've defined what the toggle should look like, what's the next step to getting it in the style guide?

[jenniferthibault]

Next steps would be to:

1. Capture the design in this github issue to document for the rest of the team where we landed on the first draft, and get the chance for quick feedback, if there is any at this point. Capture:

   • parameters that informed our design choices
   • examples of default styles
   • examples of interaction states
   • examples of responsive state changes

2. Create a new issue for building the component in code. Completion criteria might include:

   • building the master CSS/HTML style classes
   • pair with designer to check styles
   • add component to mockups or prototypes (if ready)
   • adding component to the style guide (this could theoretically be separate, but I like to do it all in one to make it part of the regular process)

I often find that it's helpful to have whoever styled the thing pair with whoever is building the thing in code to look at an example of the component when they're nearing a first draft, but before filing a pull request. This helps make sure you're both on the same page, and is a good chance to make sure everything looks and works like you expected it to early on.

3. Create another new issue for writing notes and documentation for how this component is used that will fill in the style guide notes tab.
   • Optionally, this could be included in the first or second issue, but I find it's helpful to separate content tasks from code-based implementation tasks. And often, the team members capable/responsible for each will be different people. It's likely that the notes/documentation content for a component might need slight updates over time as the component is used in more places, and you have a firmer understanding of the site's guidelines.

---

This is how I've done it before, but of course you all will find what works for you.

@mcharg are you up for updating this issue with the items from step 1? I'd also be glad to give it a first pass if you'd rather see an example first.

[mcharg]

@jenniferthibault Yes, I can do #1.

[mcharg]

Parameters that informed the design choices

• Match to existing patterns
• Match to known use cases
• Used styling to go with secondary and tertiary buttons

Default States

Desktop

Mobile

Images instead of text

Prototype for interactivity

Desktop: https://ofxchl.axshare.com/#g=1&p=toggle&view=default
Mobile: https://ofxchl.axshare.com/#g=1&p=toggle&view=a

Specifications

• 5 px corner radius on the left and right (or top and bottom on mobile) buttons.
• 0 px corner radius on center buttons.
• Selected button color and font match the styling for tertiary buttons.
• Unselected button color and font match the styling for secondary buttons.
• When the screen hits the mobile breakpoint where surrounding content changes to a mobile view (usually 768 px or 600 px) they switch to the mobile display with stacked buttons.
• When stacked on mobile, the pixel height increases to 40px per button and the width of the screen minus margins.
• Button width should adjust to fit the text on the button with a minimum width of 40 px and a max width of 300 px.
• The max width for a set of toggles is 768 px.
• Toggles should accept icons as the content, instead of text in some instances.
• Labels on toggles should not wrap or truncate. If labels are too long, we should shorten the labels or use a different control.

[jenniferthibault]

@mcharg this is great, especially how you're showing interaction prototypes and referencing other patterns that set the styles for this one. One way to make that stronger would be to link references to those patterns to their pages in the style guide.
For example:

• Selected button color and font match the styling for tertiary buttons
  

The only parameter I'd add is that we also need this toggle to accept icons as the content, instead of text in some instances. I'd add that to the list with an example prototype or screenshot.

@master12 as the receiver and user of these notes, is there any info missing or anything you'd do differently?

[mcharg]

Created #2911 to address step 2 above.

[mcharg]

Created #2918 to address step 3 above.

[mcharg]

@master12 Do you have any feedback on the specifications?

[master12]

A couple questions:

1. Is there a max width or min width?
2. For mobile we may want to set a breakpoint for screen width
3. If we use text do the buttons wrap if they stretch to far? Or we switch to mobile?
4. If we set max width what happens to the text inside the button? Wrap? Clipped?

Thats what I have so far.

[mcharg]

1. Min width: 40 px, Max width: 300 px per button and 768 px for a set of toggles.
2. Mobile: Breakpoint is 768 px
3. Switch to mobile. We should aim for short labels.
4. We create a shorter label, so it fits.

[master12]

I will check what the breakpoint is we use now and go with that. There are general guidelines so I assume we are using that.

[jenniferthibault]

Your breakpoints are defined in the .scss here: https://github.com/18F/doi-extractives-data/blob/dev/_sass/_grid.scss#L8

// Breakpoints
$tiny: em(480);
$small: em(600);
$medium: em(768);
$large: em(900);
$huge: em(960);
$huge-plus: $huge + em($max-vw-margins);
$jumbo: em(1500);
$massive: em(1800);

[mcharg]

@jenniferthibault Is there a rough translation for how many pixels = an em?

[jenniferthibault]

@mcharg to answer your question, I've been digging myself into a rabbit hole on this and could use some help from @mentastc . In the expressions copied above, does em(480) = 480em?

Sharing my reading list:

• All your base, are belong to us — or what base size do em-based media queries use? by Stephanie Rewis, March 2015
  • This has the answer to your direct question, that in this case, since it's a media query, 1em=16px unless the user has permanently overridden those settings in their browser But in other scenarios, 1em can = other px dimensions. So layout changes are determined by the line length, not the number of pixels.
  • This is also what makes me suspect that the two expressions above (em(480) and 480em) are not exactly the same
• REM vs EM – The Great Debate Zell Liew, Feb 2016
• PX, EM or REM Media Queries? Zell Liew, March 2016

[brentryanjohnson]

@jenniferthibault and @mcharg I believe you're looking at Sass em() function declarations that accept pixel values and convert them to ems in the CSS output.

The values you see in the Sass file should be pixel values. I checked this out and found an obvious breakpoint at 768 px, which is declared as a breakpoint in the stylesheet.

[mcharg]

I updated the specs to reflect the 768 px breakpoint.