Audit & reconcile main heading styles

[jenniferthibault]

We've generated a few page types that all use identical, or close-but-a-little different heading styles, that I think I can clean up. This will be a light visual lift and hopefully a light front end dependency.

On the following pages:

• Essentials pages
• Article pages (checklist items)
• AO pages
• Missive templates

After synthesizing the patterns, update the style guide with documentation when this moves to implementation.

[jenniferthibault]

While pairing with @adborden to set up the Advisory Opinion landing page and canonical page templates, we found some inconsistencies in how our h1 styles are designed, built, and implemented.

I hoped to improve these by auditing the styles in place, finding areas for refinement and simplicity, and (with front end help) possibly refactoring the page templates as needed to use fewer classes overall, by designing more common classes.

The timing for this is good now because the legal resources sections are growing into templates quickly, and the Press/news page templates are just about to be build. Refining the classes before those templates are built will help us nip this meandering pattern in the bud before it gets unruly.

There's a reaaalllly big imge of the audit below, where the first column shows the current design, the second shows the code classes applied, and the third shows a screenshot of me fiddling with design changes in the inspector, or some notes/questions.

Overall I notice two main patterns to our h1's:

1. When they are used as article titles (orange dots)
   • variation: followed by a subheadline
   • variation: used in a hero pattern for a section (red dot)
2. When they are used in data table results (blue dots)
   • variation: when they are used for search results (dark blue dot)

For all instances of scenario 1 , the most meaningful change I can see is to set one common font and line-height size for all of them. (I've recommended 3.6 rem).

I think there's a huge opportunity to refine our base pattern in these instances and reduce the number of modifying classes, but I'm not entirely sure what that approach is. @noahmanger and @adborden , what do you think we can do here to make these more efficient?

For scenario 2, I think it makes sense for these to remain a little smaller than scenario 1's (the current 3 rem is ok) because they are introducing tables or lists rather than articles. It seems like we could improve the formatting on the legal search results h1 here by making that format match the other table h1's. What do you think?

(I strongly recommend clicking the images to open them at full size in a new tab!)

[jenniferthibault]

Small update: on scenario 1 I found another instance of upcoming pages that rely more strongly on incorporating the icon with h1 styles: the data breakdown page templates:

With more real need for icons on these pages, I'd take back my earlier suggestion for removing them from the advanced data pages, and instead implement the pattern with more detail, as illustrated in this issues' screenshot of the design file:

• the underline should go under the icon, and be the full-width of the text container
• the icon should be at the vertical optical centered with the h1 text

[noahmanger]

This is awesome! Super thorough and really helpful to see. I'm sure we'll be able to reduce the styles into a few common ones. Sorry, nothing more to add.

[jenniferthibault]

I was thinking about how to move this forward, and I think I can do a little bit more to make sense of things before we move in to front end refactoring. I'm going to try to abstract out the basic templates with grids & markup. This won't take long, so I think that it and still move to front end implementation this sprint.

[jenniferthibault]

Alrighty, below I've identified our base pattern and the variations/add on items. (For my purposes, I've been thinking of "variations" as any time we treat a main page title's size or structure any differently; I've been thinking of "add ons" as any piece that is added on around the base pattern, but doesn't change it's structure or size. These probably have better terms in the front end cannon 😄 )

Mockup notes:

• The pink grid lines show the document grid
• The grey boxes behind the text show the container width in the grid

Base pattern: one line, multiple lines

Add ons

Sub-headline

Article Tag

Icon

Non-data table filter panel

Variations:

Data table:

• h1 reduces to 3rem
• top/bottom margin reduce

Is this a helpful framework?

[noahmanger]

This is great! Really helpful to document the vertical spacing like this. Only question I have is what font size things should be on smaller screens? We've been reducing the size of certain headings at smaller breakpoints.

[jenniferthibault]

Gosh, I can make up a number, but without looking at the whole system that's hard to say. (I didn't realize we were already doing this, since I remember that task being firmly ice-boxed. Exciting! But also makes me realize how far from the code I am.)

What exists already that could help make a more logic-based choice?

• Are there existing h1 mobile sizes?
• Are there existing h2 mobile sizes for comparison?

[noahmanger]

This can also be something we pair on, too. But FYI the code is all here. The default style is the mobile style, and then the sizes adjust at the $med breakpoint.

[jenniferthibault]

I think pairing together feels like the best way to make that size choice.

Ok to move this to implementation? We could keep this issue open, or close & start a new front end targeted issue.

[noahmanger]

Let's do it!

[jenniferthibault]

@noahmanger could I enlist your help making an implementation issue from this? I'm not sure I know how you'd approach it.

[jenniferthibault]

@noahmanger ping! I don't see any new issues connected to this for implementation, and I'm worried it might fall through the cracks. Don't need to implement it this sprint, but I'd like to make sure an issue is created so that it's tracked in our task list for an opening. I could take a crack at drafting, but I'd like to at least chat with you first about what approach you think it right.

[noahmanger]

Implementation issue is here! https://github.com/18F/fec-style/issues/490

I was going to get to this this sprint.

[jenniferthibault]

Omg I made it and everything. Hello brain. I really couldn't give it much detail for completion criteria, but if you know your approach and are't worried, then sounds good. Thanks!