Expandable sections

[mebates]

Design and content for the Expandables page, edited from the DPG content. Sending source file to @iuloshi. Design or content critique welcome!

[mebates]

Hey @iuloshi - Took a look at the page. I was imagining the live example in the 'Style' section and static images in the 'States' section (just the bars).

[iuloshi]

Since we show the different Links, Buttons, and Forms states as coded examples (as they also exist in Capital Framework), I'm inclined to say that we shouldn't use images to illustrate the examples in the UI toolkit. The coded examples on the other pages set the expectation that all of the UI elements are interactive and I think it would be frustrating/confusing to the user if some were arbitrarily images. I was going to try to hack the code so that the Hover state example was the correct hover color for the expandable.

[himedlooff]

Add the class "open" to .expandable-header. That should give you a live example of the expandable with the hover state active.

<div class="expandable">
    <header class="expandable-header open">

Although I'm noticing that there is a hover for both the expandable header bar and a different one for the show/hide link.

[iuloshi]

Hey thanks @himedlooff!!

• Content audit/review

[mebates]

Hey @iuloshi - I just reviewed the page and it looks good. Closing!

[benguhin]

Re-opening this guy because of the awesome work that Owning a Home and Flapjack teams have done with expandable sections in the past year. Here's a screenshot from the about site of a two-column list section that becomes expandable on the smallest breakpoint:

@stephanieosan I think y'alls we also working on spacing rules?

[stephanieosan]

Linking off to this gray issue: #295
If we're changing to 5% grey instead of 10% to make links accessible, we should definitely do the same for expandables, since they include links. The other question I see, is whether we should include rules above or below or both on grey expandables.

[stephanieosan]

Another topic: what about the black-lined expandable table pattern that Flapjack and Owning a Home have been using recently? Is that considered an "expandable" or is that style part of a different bucket of patterns?

[stephanieosan]

@benguhin I will assess what we've been doing about spacing.

[Scotchester]

@stephanieosan We call those "expandable groups". Groups that only allow one to be open at a time are given the additional descriptor of "accordion-style". Code-wise, they are a part of cf-expandables, as they merely style combinations of multiple single expandables.

[duelj]

I will say I prefer the grey lines on all expandables as we do not use full black lines in other areas of FJ (tables, rules, section dividers, etc.) not really sure how the black lines got in there. As for the type, I know we modified ours a bit for a FAQ section and bumped it up to h4 to create better hierarchy with the answers, but had been using the link style for most.

The example @benguhin on the about the bureau page (http://beta.consumerfinance.gov/the-bureau/) with the blue text is also a bit of a fluke as we are moving towards using black title text as the default I believe. The History section (http://beta.consumerfinance.gov/the-bureau/history/) also makes use of the grey background style expandable (this one would need to updated to the 5% grey as @stephanieosan mentioned).

[duelj]

I wanted to add another example of a custom expandable situation we have in flapjack to see if there is a way the default expandable might be used to make it more consistent. The "show 40 contacts" expands to reveal an expandable table style with all the contacts. The button format was used to help differentiate it from the contact expendables, but we would like it bring it more in line if possible.

current style	attempted design manual style (w/ 5% grey)

[benguhin]

@stephanieosan I think we should definitely consider the "black-lined expandable table pattern" and "background gray expandable" styles at the same time – it can make sense for them to be styled differently because they're used for different purposes, but we should (a) try to make them as similar as possible (b) update the guidelines based on the more advanced amounts of content that you guys have been expandifying and (c) provide more guidelines about how the patterns should adjust for responsiveness and accessibility

As @Scotchester mentioned, we already have versions of both in cf-expandables:

http://cfpb.github.io/cf-expandables/docs/#recommended-expandable-pattern

@duelj I am also torn about those options. The button is so much cleaner.

[duelj]

Things we could leave open?

Two tweaks that I would propose we maintain as "designer discretion" would be:

• ability to remove the stroke between header and content in the expanded version. I think sometimes it makes sense to include but other times it doesn't help the hierarchy and adds visual clutter (on both grey and white versions).

• Ability to use grey lines on the white background version (also in example above). I think this helps to reduce complexity in a long list of expandables. We also haven't used many full black lines in Flapjack (most are 50% grey) and it would be nice to be able to do this to maintain consistency.

Questions

• Do we think there is a case where it would be ok to have the plus/minus minicon in the expandable format without the "show" or "hide" text? I know it is preferred for accessibility but we have found instances on mobile where having it makes headings break into multiple line prematurely, and looks very cluttered.

with show text	w/o show text

• Are there other instances people have like the example of the button expand that differ from that standard styles but seem like they have valid user cases?

[duelj]

Trying to bring this to the finish line and it seems really close, this is my understanding of where things stand:

• Content for DM page has been created and agreed upon. Content can be found here
• There are a few design questions that are in the content doc that we need to settle before design approval @nataliafitzgerald does this sound correct?
  • Do we need a title text options other than Avenir paragraph or H4?
  • Do we need a white and grey version?
  • Will there actually be 15px of space under the label text? Is this because of how space is measured?
  • Do we need the option to have a rule line under title in the expanded state?
• After design approval is given DM page should be ready for coding.

If there are any other outstanding design questions that aren't listed above please add by the morning of Friday 2/19/16 as I plan to move on to addressing questions and prepping page on Friday

[nataliafitzgerald]

@duelj
Thanks for reaching out! Glad we're working to wrap this one out and incorporate it into the DM. I went through the remaining open questions and commented below. Regarding style options, we should define the proper use cases for the different options. The more consistent we can get with this pattern the better.

1. Do we need title text options other than Avenir Next paragraph or H4? I gathered up some use cases and they seem to all be using either H4 or Paragraph Medium. Are there use cases for Paragraph Regular? I don't know of a need for any other title text options.

• Numbered list of steps (uses H4)
  http://www.consumerfinance.gov/owning-a-home/process/prepare/
• Numbered list of key facts (Paragraph Medium)
  http://www.consumerfinance.gov/know-before-you-owe/real-estate-professionals/learn-what-changed-about-mortgage-process/
• Filtering (Paragraph Medium)
  http://beta.consumerfinance.gov/blog/
  
  

2. Do we need a white and grey version?
Are the two coloring approaches (gray versus white) unique in terms of their intended usage or are they merely stylistic options? If they have unique use cases let's be sure to define these use cases in the DM. If they are merely stylistic options, we should narrow this down to one or the other.

Here's one possible way to define these (what do you think @duelj?):

• Single expandables have a gray background and a 50% gray stroke all around (example: http://beta.consumerfinance.gov/blog/)
• Multiple expandables have a white background and a 50% gray stroke above and below (example: http://www.consumerfinance.gov/owning-a-home/process/prepare/)
  
  

3. Will there actually be 15px of space under the label text? Is this because of how space is measured?
I talked this over with @Scotchester and it sounds like we are using 10px of padding above and below based on the new spacing. We've used the new pattern in some of the recently built intermediaries pages. Does this align with what's happening on the V1 build side? @jimmynotjim

4. Do we need the option to have a rule line under title in the expanded state?
Instead of making this optional, let's make it the standard.

Additional edit

• Remove the black stroke option for the rule line above and below. The 50% gray line above and below should satisfy our needs.

[duelj]

I was looking at updating the documentation for this today and came across a couple of things that felt like they needed to be sorted before updating the page.

1. Do we need title text options other than Avenir Next paragraph or H4?
Looking at removing the Avenir paragraph title because it is not differentiated enough from the expandable content.
Originally we had talked about moving away from the Avenir medium because it wasn't part of our type hierarchy but as @nataliafitzgerald pointed out it is being used and seems to be working well. Here is the comment where this is discussed.

2. Do we need a white and grey version?
I think there is a case to be made for a white and grey version at least for individual expandables. The use case would be like the filter (as mentioned on V1's blog page) where you want to highlight the expandable from the page's background color. When expandables are used in a group it makes sense to have them match the pages background. I have crafted some text around this in the page mock up I will post.

3. Will there actually be 15px of space under the label text? Is this because of how space is measured?
V1 is using 15px of space (top and bottom) for our atomic expandables. I cannot speak for other projects, but according to our FEWDs there are three expandables in existence: CF expandables, atomic expandables, and the filter expandables (on blog, etc.), which is like a modified CF expandable." The last example exists since blog pages are not atomic because they were build before V1's Wagtail CMS was put into place. If they get moved over they would match the atomic expandable style (when they get moved is TBD).

@nataliafitzgerald - You mentioned the 10px was due to updated spacing, but I am not sure i understand that reference, could you elaborate? If you are referring to the header spacing, my understanding was that the header spacing would only impact flowing passages of text not spacing in or between components. So the space between the expandable header and description copy should follow these guidelines but I didn't think they would influence space between the header and stokes or other elements. Maybe this isn't the spacing updates you were referring to though.

4. Do we need the option to have a rule line under title in the expanded state?
I do not think they are necessary but could be a useful option. In past conversations the general impression was to get rid of them as shown below.

@nataliafitzgerald - curious on your answer about this one, in the content doc you said lets get rid of them but on your last comment it sounded like you wanted to keep them. Just wanted to double-check where you landed on this.

[duelj]

Here is an updated DM expandable page mock up reflecting some of the adjustments mentioned above

[Scotchester]

Re: item 2: Do we have a clear use case for when a single expandable should have a white background? If so, can we specify that in the DM page?

Re: item 3: The spacing issue is about the top/bottom padding in the collapsed state. The spacing update that Natalia is referring to is the shift from discussing vertical padding with respect to the cap height and baseline of a line of text, to discussing it with respect to the CSS line-height of that line of text (so that the padding values in our design specs match what we're actually coding in CSS).

From your latest page mockup, it looks like the design intent is 15px from top to cap height, and from baseline to bottom. In which case, we'd need to code it in the CSS as about 10px. If that's the case, we should update the spec here to be 10px, and adjust your bracket diagram accordingly.

[duelj]

It could have a white background if it was on a grey well to stand out as a highlight. I felt the choice of when to use a contrasting background could be left to designer discretion.

If the the 10px is the best way to represent our current spacing that works for me. The spacing thing confuses me, is it that in code 10px is used to mimic what 15px looks like in illustrator? Wouldn't the increment we choose cater to either devs or designers if that's the case?

[Scotchester]

Ah, expandable in a well. That makes sense.

Yes, 10px in CSS approximates what 15px from baseline to cap height (between two lines of text) would be in Illustrator. It's true that it will cater to one or the other, in a sense. But we did, in the course of the big spacing overhaul, determine that it was best for our design specs to match how they are implemented in code.

To remember why we made this decision, think of a large running text field scenario. If you have two paragraphs of text in the same frame in Illustrator, and you use Space After on the first to give them some separation, that value in Illustrator will match what you want the value in CSS to be, because each line of text will also have a little built-in line height. It's only in scenarios like this one, where you're lining text up against a border or some other kind of structural boundary, that it's more natural for you to manually line it up x pixels from that boundary.

[nataliafitzgerald]

@duelj
In our updated character and paragraph style palettes for illustrator (which I will be adding to the master web template file) we are using space after values that match the code values. So, this will be consistent.

[schaferjh]

This is all looking great to me, and since it is only the UI approval label on it, I suspect I have been a blocker. Apologies.

The interaction and UX look good to me. My main edit to the way you're presenting the information is that I suggest calling the "Types" section "Interactions" to differentiate from the "Styles" section above and more clear identify the information about default vs. accordion behaviors. (I would also be up for "Behavior" as the label).

With that change, I approve!

@caheberer Etiquette question: do I wait to see the change before removing the UI approval tag?

[caheberer]

@schaferjh I'll leave that decision to the approvers. Whatever you feel comfortable with works for me.

[duelj]

Below are adjustments made after feedback from the design meeting (green text shows content updates and is not part of design)

1. Updated text for when to use background color on individual expandables

2. Update spacing for top and bottom of expandable section

3. Add content and example for title stroke

4. Update section heading from "Types" to "Interactions"

[schaferjh]

Looks great. Tag removed!

[jimmynotjim]

@Scotchester from what I remember about our discussions, we were going to just match what designers spec'd, even if it didn't match exactly visually. So if it looks more like 10px in CSS, we'd ignore that and still code it to the spec'd 15px, because trying to make things match perfectly is nearly impossible in Ai (other apps like Sketch handle text more like CSS)

[duelj]

Following up:

@nataliafitzgerald is the design end of the this good to go? @Scotchester and @jimmynotjim - where do you think we should land on the spacing thing? I will admit I understood the spacing discussion differently after the header spacing adjustments, but am happy to include what ever spacings the rest of the DM is using in their specifications. Just want to make sure I have the right measurement.

[Scotchester]

@jimmynotjim Yep, that's essentially what I was saying.

@duelj Looks good to me, now!

[duelj]

notes from DM meeting 3/21/16

• DM page design needs sign off
• Expandables are mostly in Capital Framework but updates/additions have not been made by V1 devs.
• Blocker: V1 devs do not have time available to make updates to DM page before regroup due to Project demands.
• Availability of V1 devs to code DM page is TBD.

[nataliafitzgerald]

@duelj
This is looking good!

Just a few final tweaks to the Design Manual page mock-up and we should be all set.

• For the "Expanded" examples, can you check the padding on the left and make sure it's set to 15px?
• In the "Group H4 with title stroke expanded state" what is the padding under the rule line? It looks like we could afford to tighten that space up a bit.
• In the "Individual" section the expandable headings are Avenir paragraph. Should they be Avenir paragraph (medium) instead or is there a use case for Avenir paragraph (regular)?
• In the "Specifications" section, change Avenir medium to Avenir paragraph (medium).

[duelj]

@nataliafitzgerald - I have made the updates you suggested and have noted the changes below. You can see an example of the full page here.

For the "Expanded" examples, can you check the padding on the left and make sure it's set to 15px?
Adjusted spacing on expanded group to 15px

In the "Group H4 with title stroke expanded state" what is the padding under the rule line?
The space was set to 30px but I have revised it to match the 10px from the collapsed state.

In the "Individual" section the expandable headings are Avenir paragraph. Should they be Avenir paragraph (medium) instead or is there a use case for Avenir paragraph (regular)?
Good catch! Yes they should be Avenir paragraph (medium) I have update the titles.

In the "Specifications" section, change Avenir medium to Avenir paragraph (medium).
Updated the wording in the specification as well as the wording in a couple of the example titles.

[nataliafitzgerald]

@duelj
This looks good to go on the GD side. Make sure to add the 2 new sections to the jump link menu at the top (Interactions and Accessibility). Thanks!

[duelj]

Ready to build Expandables page with updates to jump links as mentioned by @nataliafitzgerald

[stephanieosan]

This is soooooo done!