Updates to hero graphic guidelines

[nataliafitzgerald]

User story

As a Designer/Developer/Content person, I want the hero guidelines to be useful and up-to-date so that I can know my options and successfully implement the pattern.

Acceptance criteria

• Related tasks are completed
• Hero documentation is updated to include usage guidelines
• Hero documentation is updated to include all design options

Discussion (optional)

Related tasks:

• Update documentation of min and max character counts for hero graphics Update documentation of min and max character counts for hero graphics #460
• Remove the button and link options from the hero module Remove the button and link options from the hero module #454
• Add full bleed illustration option to hero graphic guidelines Add full bleed illustration option to hero graphic guidelines #462
• Add photo option to hero graphic guidelines Add photo option to hero graphic guidelines #464

[nataliafitzgerald]

I've been working on tackling all the tasks in this user story as part of a full update of the hero page. This update can be MVP and we can continue to make adjustments moving forward. My primary goals at this point are to:

1. Provide usage guidelines for members of D&D so they can successfully create heroes using the options that are currently available in Wagtail.
2. Provide editorial guidelines for content creators so they can create successful heroes that align with our content strategy/guidelines (character counts, tone, voice).

At this point I'm looking for a review from a few perspectives:

@Scotchester @jimmynotjim

• Review of the technical guidelines included as well as the functionality of the different types of heroes (standard, bleed, photo), sizing, breakpoints, etc.
• Later task: Check the specs versus what we built and make sure that things match up. I noticed some small inconsistencies between what was specified in the existing guidelines and what we built so I'll want to iron some of these things out. But, I'll create a separate task for this that can happen after we get these guidelines out.

@kurzn @jordanafyne @ielerol

• Review of the overall page structure
• Review of the content

Some questions to answer/address:

• Are we clearly communicating the strategic goals of a hero graphic and where the hero sits in the page hierarchy?
• Are we providing our content creators with the information they need to successfully create hero graphic content?
• I'm struggling a bit with the structuring of the "Style" section. There is a lot of information to include but I'm not convinced that my groupings are quite right yet. In the style section I'm including information on sizing of images based on the type of hero (standard, bleed, photo) and also stylistic guidelines based on the different breakpoints. I've included quite a few visual aids in order to help reinforce the ideas.

@huetingj

• Review of the page structure and content.
• From a designer perspective, does this page include the information you would need to create a hero graphic? Is everything where you would expect it to be? How is the structure working? Do you have any ideas on how to improve the structure of the "Style" section?

Here's a link to the page: http://nataliafitzgerald.github.io/design-manual/global-elements/heroes.html

If anyone would like to jump on Hangouts to discuss any of the specifics I've mentioned above I'm eager to push forward on this so I would be appreciative. Or, feel free to comment here. I'd like to get this MVP up as soon as possible so if I don't hear from people I'll start reaching out to others.

[nataliafitzgerald]

I spoke to @kurzn on Mattermost today. Here were some of her recommendations:

• Provide more direction in the content section
• Include guidelines about not putting CTAs or hyperlinks in heroes since the goal is not to move people away from this page

@jordanafyne has offered to take a look tomorrow morning and we will talk through any recommendations she has.

[jimmynotjim]

Overall looks really good and I appreciate how much detail you've included for situations like two line headings and the clear space between the text and photo content for the overlay version.

• Should we include some context on when to use each version? I still don't understand when to use the regular and full bleed options.
• Should the photos be 2x as well?
• Should the no bleed illustration be listed first since that's the default style with the other two modifications to it?

[Scotchester]

Reviewing now. Rather than post one giganto-comment, I think I'll do it piece-by-piece.

First:

Should the "Content guidelines" section include any explanation of the difference between a one-line heading and a two-line heading? It may not be totally self-evident.

• The two-line heading shows an example where the text has been forcibly broken onto two lines. Do the two-line heading guidelines apply when a single statement is too long for one line?
• Also, some one-line headings will become two-line headings as page width decreases. Are we making the determination about whether something is one-line or two-line at the largest breakpoint?
• Finally, pertaining to the discussion we had, @nataliafitzgerald, about enforcing character count limits on the back end, having two standards for character counts depending on whether a heading is one line or two will make implementing that pretty tricky.

[nataliafitzgerald]

@jimmynotjim

• As far as I've seen, the decision between the standard and the full bleed are purely an aesthetic decision, based on the illustration that is created for the space. Perhaps we can consider whether there are use cases we can pull out for each.
• I spoke to @Scotchester and he preferred that the photos not be 2x since those images could get quite large. What do you think?
• Listing the no-bleed / standard option first sounds good to me. Maybe I can somehow indicate that it is the standard approach.

[nataliafitzgerald]

@Scotchester

• Yes, the two-line heading guidelines apply when a single statement is too long for one line
• The two-line determination is based on the largest break point
• Within Wagtail could we possibly have different input fields for the one versus two line options?

[Scotchester]

OK, I would suggest adding some copy to make those first two points clear.

We could have two heading input fields, but the Hero module is already insanely complex to handle all of the different stylistic options, so I hesitate to make it more complex. I guess we can cross that bridge if we ever get to experimenting with back-end character limiting.

[Scotchester]

I agree that the "standard" (or most common, at least) style, the no-bleed illustration, should come first, and I agree with the suggestion to add some language about when to choose other styles.

[nataliafitzgerald]

@Scotchester - As part of our Platform team work @ielerol will be working on improving the experience and guidance for users within Wagtail so perhaps we can take a closer look at the complexity within this module. And, we will consider this when we (hopefully) visit the backend validation approach.

[jimmynotjim]

We could have two heading input fields

Oh please let's never do this. It'd probably be better to check the length of the title field and update the text field max characters with some JS than to provide users duplicate fields.

[Scotchester]

Oh please let's never do this. It'd probably be better to check the length of the title field and update the text field max characters with some JS than to provide users duplicate fields.

That doesn't work if there's a manual break in the heading, though, as the two-line example on Natalia's page show.

[jimmynotjim]

That would be a <br> in the text input right? We could include that in the character test.

[jordanafyne]

This looks great, and I think having character counts defined for the content is valuable.

• Agree with @kurzn on copying over (or linking?) guidance from the style guide on voice and tone. Also on capitalization in headlines.
• Regarding headings, if it's a two-line heading it should be intentional and not due to an orphan carry-over.
• Do we need to describe when and how to include a link to the page in Spanish?

[nataliafitzgerald]

@jimmynotjim @Scotchester
I'm fine with whatever solution works from a dev perspective as long as it achieves the goal of alerting Wagtail users of character limits and accounts for the two variations (one line versus two line).

[nataliafitzgerald]

@jordanafyne

• Because the future editorial guidelines will be on our internal GH and the Design Manual is on our external public-facing GH, we can't actually link between the DM and the future editorial guidelines. But, perhaps we can pull in some key ideas.
• I think that you could have a two line heading that isn't created intentionally with a <br> but I agree with you that we want to discourage orphans.
• At this point in time we are removing any links or buttons within the hero graphic. Up until now we've been mostly linking to Spanish pages at the top of the sidebar. I imagine that in some future state you may be able to toggle between English and Spanish within the header at the top of the page. But, since we really don't have a parallel Spanish site at this point, we don't do that. Here's one approach that we're currently using to link to Spanish pages from webpages: https://www.consumerfinance.gov/mortgage/ The inconsistency in how we link to Spanish pages is something that I have flagged and that we should definitely look at on the Platform team.

[Scotchester]

Image sizing

• Confirming that I think doing photos at 2x resolution will probably be too large for the quality benefit, but my mind could be changed with some testing.
• Unless you found a reason for the extra size on the large photo after we talked about it, @nataliafitzgerald, reduce that to 1230x285.
• I think the small image sizing recommendations for both photo heroes and full-bleed heroes should be less prescriptive. At minimum, I would indicate that that's a maximum height guideline. If others agree, I might go so far as to recommend they be as short as possible.
• It should maybe also be explicitly called out that the small image for photo and bleed heroes can have a totally different composition than the large version?
• The height recommendation for the large bleeding image should be a minimum of 610px, to ensure that it continues bleeding as the image width shrinks all the way down to 601px screen widths.
• Sizing for the no-bleed illustration should indicate that that's a maximum in both dimensions. The image can be shorter or wider as appropriate for the composition.

[Scotchester]

Whoops, forgot one for image sizing:

• Small screen image for bleeding hero should be 570px wide (1140 at 2x).
  • Yes, the prepaid page's small image is not currently wide enough for screens 520–600px wide. I'll fix that when I also fix the fact that they're not high-res 😳

[Scotchester]

Text styling

901px and above

• Mention that the text should be centered vertically within the hero.

601–900

• I think I miiight remove the term "Lead paragraph" here and just say "Avenir Next Regular, 18px/22px), because it has a different breakpoint for sizing down than normal lead paragraphs. But maybe that's too much nuance to worry about.

Accessibility

• It seems superfluous to mention text contrast accessibility. It's no different for heroes than our basic foundational rules. Maybe it would be worth mentioning that special care should be paid to this issue when using photographic heroes, which can't have their contrast ratios mathematically determined.

[ajbush]

Hey this is looking good @nataliafitzgerald the only thing I think we should reconsider is the limits on the amount of content in the "Two line heading" heros subheading. I understand it is done to try and keep the heros a consistent height at desktop but I feel like the current suggested limits in this screen shot are too restrictive for our content needs.

I'd strongly recommend we instead have the same maximum character count of 185 for both subheadings...

One line heading

• One line heading at largest breakpoint
• Heading: 43 characters (maximum)
• Subheading: 165 characters (minimum) / 185 characters (maximum)

Two line heading

• Two line heading at largest breakpoint
• Heading: 40 characters (minimum) / 86 characters (maximum)
• Subheading: 25 characters (minimum) / 185 characters (maximum)

---

Other question
Also what was the thinking behind the lower 25 minimum characters for the Two line heading? Is there an existing use case you're accounting for?

[nataliafitzgerald]

@ajbush

Thanks for your feedback!

My goal with this next release is not to change what we've been doing but to document it with more detail. For example, our existing hero standards state that the heading should be "25 characters maximum, including spaces" and subheadings should be "185 characters including spaces." What this means is that as far as our existing guidelines (and Wagtail helper text) are concerned, the two line heading isn't even possible. Additionally our existing guidelines include no mention of bleeding heroes, photo heroes, sizing for images, etc. My goal at this point is to get the DM up to speed so that we all know what it currently possible and how to accomplish it.

Yes, maintaining a consistent height for heroes is important to the visual hierarchy (and is one of the goals of having max character counts). But, an equally important factor that goes into the character counts is to ensure that hero content serves to introduce and orient a user in a concise way without overwhelming them with a lot of text right out of the gate. Since our web pages are incredibly text heavy heroes serve an important role; a respectful resting point where a user can determine whether this is a page that they want (or dare to) to dive deeper into.

Up until this point, our main struggle has been with users exceeding the 185 max character count with subheading text in one-line heroes. Two line headings are actually not at all common on our site, there are currently only two live examples, Planning for Retirement and Owning a Home. On both of these, there is a forced break in the heading to separate the product name from a description. I suspect that this has something to do with users not knowing what product names mean (something that's been flagged a lot over the years).

In terms of the minimums in general, they were inspired by our work on Consumer Credit Trends where the content was cut in such a way that the content strategy goals and design goals of the hero graphic were no longer being met (recapping for the benefit of others). After that experience, @marteki and I realized that it would be helpful to document minimums so that content writers are clear with where they will want their content to be, when they don't have the luxury of testing things out in Wagtail like we do. In terms of the 25 character minimum for subheadings under a 2-line heading, I was trying to establish the point where anything less would create an imbalance between heading and subheading. There wasn't a specific use case so if you have any recommendations as to what that minimum count could be, let me know.

[nataliafitzgerald]

@jimmynotjim @Scotchester
Looking back through the feedback, I think that documenting use cases for the different types of heroes (standard illustration, bleed illustration, photo) is a very good idea. But, I'd like to do this as part of a second push (to directly follow this one). As a graphic design team we've talked about the use cases for using photography versus illustration but it would be good to revisit and talk through these. We've talked about photography being a better option than illustration for more serious subject matter, for example. The use cases for bleed versus no-bleed illustration seems more compositional than anything else but a larger discussion may bring out some other thoughts.

[nataliafitzgerald]

@ajbush
I'm double checking the counts and the minimum of 40 characters for the 2-line heading seems like a typo on my end. I'm going to look at that one again. 43 is the max for a 1-line heading so that is the point where it breaks to the second line. I suppose we could remove the minimum for the two line heading and just indicate that creating an orphan at the max width should be avoided. That could work.

I'll consult with @jordanafyne today to see what she thinks would be most useful for our content writers/templates.

[jimmynotjim]

I'd like to do this as part of a second push (to directly follow this one)

That sounds good to me. We definitely need to get better at pushing incremental changes rather than holding up a change to be absolutely perfect.

[nataliafitzgerald]

@ajbush @jordanafyne
I double checked the hero content lengths by testing things out in Wagtail here: http://build.consumerfinance.gov/hero-content-test/.

Our grid changed recently (just a change to match our intended grid) so some of the counts were off because of that. I think what was happening with that 25 character count for the subheading after a two line heading was actually a typo. The 1 was missing at the beginning (125). Thanks for catching that!

Based on this experiment, I've made some tweaks:

Heading

• One-line heading: 41 characters maximum
• Two-line heading: 82 characters maximum

Subheading

• Subheading after one-line heading: Between 165 and 186 characters
• Subheading after two-line heading: Between 108 and 124 characters

@jordanafyne - Could you take a look at this Wagtail mock-up next week and make sure the counts look correct? Do you know of a more fail safe, precise way to test this?

[jordanafyne]

@nataliafitzgerald I got very slightly different counts, which, as guidelines, I don't think matters very much, but if these numbers are going to be input into a Wagtail character counter plugin, then it may make a difference. Should probably set that hard limit at the lower number, if choosing between the two.

That Build demo is great -- I hope you're able to incorporate those images into the documentation.

Heading

One-line heading: 41 characters maximum
Two-line heading: 83 characters maximum

Subheading

Subheading after one-line heading: Between 168 and 198 characters
Subheading after two-line heading: Between 109 and 130 characters

[nataliafitzgerald]

@jordanafyne
I figure when we (hopefully) build out the backend validation we can test out our counts to be sure our counts are right on the money. I'm ok with going with the lower numbers between yours and mine. The good news is that they look pretty close.

[nataliafitzgerald]

@Scotchester @kurzn
Can you do one more full review of the hero page updates?
Updated page layout: https://nataliafitzgerald.github.io/design-manual/global-elements/heroes.html

Also, @huetingj - Can we meet in the next couple of days to talk through the page?

[nataliafitzgerald]

@jimmynotjim @kurzn
Also, as a part of this update, I'd like to suggest that we move the hero out of "Global patterns" and into "Page components."

I'll probably also open an issue so that we can start talking about the sections of the page, specifically "Global patterns" which seems to mostly contain page types and "Page components" which could be renamed "UI elements" or "UI components."

[ielerol]

We discussed this in a meeting, but I'm documenting here for the record that the original plan with the IA was that within global elements there would be a "page intros" subsection that contained heroes, text introductions and item introductions, since every page should have one of those.

Also, as a team we need to do some more explicit thinking around when a landing or sub-landing page should have a hero vs. a text introduction, which we ultimately want to document on this page. But that shouldn't hold up the work Natalia has already done.

[jimmynotjim]

I brought this up in chat, but is there a reason not to organize the DM by atomic type to keep the language consistent? That was the main reasons we decided to use Atomic Design to begin with, but it seems we're holding out within the DM itself.

[nataliafitzgerald]

I shared the hero page in my Platform team ("Remember the humans") meeting and got some valuable feedback. Thank you @ielerol!

• Add "When to use" vs "When other options are better" section within "Use case." Specifically help a user differentiate when they should use a hero versus a text introduction.
• Add use case for photo vs illustration. Could link to the photo and illustration pages within the "Style" section. Eventually we will want to be sure that those sections can answer these questions, however.
• I received feedback from @ielerol on the question I had about moving the hero section into "Page components." She said that the original IA intent was to have a section under "Page components" called "Page introduction." Under this umbrella we would have: Hero, Text introduction, Item introduction. This makes sense to me and was the missing piece to understanding what was going on. Do we have an upcoming task for adding secondary navigation items (the way we currently do on our website?

I also met with @huetingj to go over the full page, doing a deeper dive into the "Style" section which is really graphic designer focused. She felt that this is a good step in the right direction. As she works through hero graphics as part of her project work we may learn more about what we'd like to think about stylistically and practically as we build photo heroes.

[nataliafitzgerald]

I shared this in my Design Working Session and received some additional feedback. Next, I'll map out what I'll tackle as part of this initial release and what I'll line up for the next release.

Here's the feedback I received:

• In the "Content guidelines" section, add a note/reminder about orphans and that we should avoid them
• In the "Content guidelines" section, add the expected behavior for a one-line and a two-line heading/subheading counts at desktop - i.e. The expected behavior: one-line heading has a maximum of 3 line subheading, two-line heading has a maximum of 2-line subheading - at the largest breakpoint)
• Add a bullet for the photo and the bleed heroes that a user will need to create 2 images, one for large and another for small screens.

@marteki @Dnpizarro @huetingj - Let me know if I missed anything.

[nataliafitzgerald]

Remaining tasks

This week's release

• In the "Content guidelines" section, add a note/reminder about orphans and that we should avoid them @marteki @jordanafyne
• In the "Content guidelines" section, add the expected behavior for a one-line and a two-line heading/subheading counts at desktop @marteki @jordanafyne - Please review. I had to play around with this because I didn't want the character counts to get buried. I may still have to iron this one out.
• Add link to the photo and illustration pages within the "Style" section ("Component parts")
• Fix jump link to "Content guidelines"
• Incorporate content additions and edits provided by @sarahsimpson09
• Add "When to use" vs "When other options are better" section within "Use case." Specifically help a user differentiate when they should use a hero versus a text introduction. @sarahsimpson09

Next release

• Determine whether going with 2X sized photo to accommodate retina displays is feasible (will be confirmed through dev testing)
• Add use case for photo vs illustration. I have linked to these DM sections from within the "Style" section. Eventually we will want to be sure that those sections can answer these questions, however.
• If one does not already exist, add task for adding secondary navigation items (the way we currently do on our website. @ielerol confirmed that the DM IA intent was to have a section under "Page components" called "Page introduction." Under this umbrella we would have: Hero, Text introduction, Item introduction.

If anyone has anything to add that isn't captured in this list or reflected on the page, let me know or post below. I have pushed some additional updates live this evening: https://nataliafitzgerald.github.io/design-manual/global-elements/heroes.html

[sarahsimpson09]

@nataliafitzgerald here is some Use Case language. Happy to tweak as needed! I'm also working on the updates to the 'no links in hero' language we talked about.

Use Case

WHEN TO USE
 When orienting a user to a new section or topic.
 The page operates mostly as a navigation tool with general information about a subject with links to lower-level pages with more specific information.

WHEN OTHER OPTIONS ARE BETTER
 When introducing a specific piece of content, like a blog, press release, or other lengthy or detailed content.
 When creating a lower-level page, like a learn or browse page.

[nataliafitzgerald]

Ok, I added your proposed updates @sarahsimpson09.

Here's the updated page: https://nataliafitzgerald.github.io/design-manual/global-elements/heroes.html

[kurzn]

Could be good to add examples of good headings/subheadings used in existing heroes as well. Something to consider down the line.

[nataliafitzgerald]

@kurzn
Yes, I think that would be helpful for sure. I'll add it to the list of things we'd like to iron out/add next.

[jimmynotjim]

Should we add print rules for future work as well or should that go in it's own "we need to update everything for print" issue?

[Scotchester]

@jimmynotjim Did you mean to post that in a data viz issue? Or are you talking about how a hero prints if someone prints a page that has one?

[jimmynotjim]

The later