Finalize tooltips style + functionality

[mebates]

Backlog item, for a future date post-release.

137

128

• [ ] edit content
• [ ] design pages
• [ ] develop visuals or link to Capital Framework code (if it exists)

[jenn-franklin]

@caheberer @nataliafitzgerald @stephanieosan @mebates

Regarding tooltips, OaH is currently using black with white text on our loan comparison tool, which is on build here: http://build.consumerfinance.gov/owning-a-home/loan-comparison/ We took this pattern from HMDA:

We explored using a light grey background but felt it didn't stand against the grey of our tool well enough.

And a different color, such as green, is too similar to our green education notes, which we want to be visually differentiated.

Thoughts re: whether our use of this is further solidifying black with white text as a design standard? Or should the design standard be further explored and our use of this style be considered a special case situation due to the visual needs of the tool?

[jenn-franklin]

Also--- perhaps with the black background we should take a look again at whether or not it should be transparent.

[jenn-franklin]

Update: our design on build is actually not currently transparent. Here are some screenshots for comparing.

OAH LC on build:

HMDA:

[mebates]

I've always been against the black background, because I think a big block of reversed-out type is hard to read. There is lengthy discussion of this on our internal github, search "modals" and its the first to pop up (specifically, issue 78 in the digital-product-guide repo).

I also think we need to standardize the size and shape of the arrrow that comes off of the modal. I've always used our caret minicon as a starting point.

[benguhin]

I agree that the reversed-out type seems harder to read but it does help create clearer contrast between the tooltip and the rest of the page. Yet the heavy weight of the dark background doesn't seem to match with the rest of our styling.

Some questions in addition to style:

• How do we determine and/or designate whether the caret should point left, right, top, or bottom?
• Should the tooltip appear on hover?
• Should the tooltip have a close button?
• How does it appear on mobile?

Adding the 508 tag for @JenniferHoran as we'll need to make sure that these are accessible for keyboard controls and screen readers.

[stephanieosan]

Okay, I'm splitting out tooltips and modals, because they're two separate elements and it seems like modals may have previously been finalized (at least in terms of styling). But as far as I can tell from the previous issue in the digital product guide, styling (and behavior) of tooltips requires a little more consideration.

Modals now live here: https://github.com/cfpb/design-manual/issues/325

[stephanieosan]

Recommendations for visual style:

• Blue question mark icon in a circle is the tooltip indicator
• Tooltips have a fixed width of 250px, height adjusts based on length of copy
• 15 px of padding around type
• Avenir Regular
• Caret shape is based on our caret minicon, and is 15px wide.

Recommendations for behavior:

• Tooltips appear on hover for desktop
• Tooltips appear on click for mobile—click on the tooltip to close
• Tooltip and caret center over the tooltip icon on desktop, on mobile the caret position and tooltip adjust to fit, like so:
• Position of tooltip: Tooltips should appear above the tooltip icon. To the left or right wouldn't work on mobile, and having a tooltip appear below could cover up the form fields when form labels and fields are stacked (which could occur on desktop and always occurs on mobile). This doesn't seem ideal. See below.
• To play with these behavior suggestions, check out /owning-a-home/loan-comparison on build. Ignore the styling.

---

Visual styling decisions still to be made:

1. Font size: 14 or 16? Most of our current implementations use 14, but 16 is more standard for us. All screenshots below use 14.
2. Color of background and stroke: Should we favor readability within the tooltip (light background) or contrast against the rest of the page (dark background). See below ideas.

A—10% grey with 50% grey stroke, black type B—Dark grey with white type (I know people have cited lack of readability, but tooltips are supposed to be very short pieces of content, so maybe this is worth it?) C—10% grey with 50% grey stroke, black type, flat black 25% opacity "shadow" to give the tooltips more visual separation and contrast from the page (I realize I'm opening up all kinds of blashemy here!)

Other questions

Another thing I've come across while pondering tooltips:

• Should we allow tooltips to have links in them (if so, the hover behavior wouldn't really work)?

[sonnakim]

Recommendation: move to popovers instead of tooltips

(and add a close button for mobile users)

Currently, on desktop, the tooltip disappears when the user's mouse moves away from the tooltip icon. See www.consumerfinance.gov/hmda for an example. This is a persnickety interaction—the hit area for that tooltip icon is pretty small. I think we want to make this less frustrating for users, by transitioning to popovers.

With popovers, the information stays visible as long as the user's mouse is hovering over the popover. This makes it possible to include links. See below examples. Also, Bootstrap has some specifications for popovers here.

User can click links in the popover:

---

Recommendation: Add a close button to the upper right hand corner of the popover

I'd recommend adding a close button in the upper right-hand corner of the tooltip for mobile users. This seems the lowest lift approach to translating popovers to mobile.

So, if we are implementing the Bootstrap popover component, it should be modified with a close button.

[jenn-franklin]

I showed these during Graceland's session yesterday. Here are a handful of thoughts:

• For color, try a blue outline and/or light blue background. This may connect it better to the blue question mark minicon.
• Try the shadow in option C as a solid 100 percent line instead of at 25 percent transparency.
• Overall, designers preferred the light background with dark text to the black background with white text.
• Liked the idea of popovers and being able to include links (but would use links sparingly).
• Discussed top vs. side vs. bottom placement and arrived at the idea that top seems best, at least in terms of LC's layout.

[ascott1]

Can we add a solid triangle to the icon font? That will make implementing this much easier.

cc: @Dnpizarro

Thanks!

[Scotchester]

I could make an argument for implementing it other ways, but we could use solid triangles for other reasons, too, so might as well.

[ascott1]

I'd be curious how else you'd implement that triangle (other than an image?). Maybe an inline SVG in the CSS?

[Scotchester]

Yeah, I was thinking maybe inline SVG with PNG fallback. The main question in my head was, "Considering this as a component standing alone, do we really want to add a cf-icons dependency just to get that shape in there?"

[ascott1]

I think that's a good point. I'd argue for SVG data uri with no PNG fallback (do IE8 users really need that caret?).

[Scotchester]

Probably not :)

[mistergone]

Ah, are you guys not aware of the Magical CSS Triangle? :triangular_ruler:

The little triangle is actually really easy to implement, and it's mostly cross-browser compliant. Just Google "CSS Triangle." There's even a generator! Well, several, actually... here's one - cssarrowplease.com

I've done it with tooltips in Paying for College, and in some upcoming releases. It's a neat trick.

[Scotchester]

Can you pull off a rounded point with that?

[mistergone]

Hrm... well, essentially, you're making a zero pixel element with large borders, and all you see is the border, which would normally be trapezoidal, but instead ends up being a triangle because the top of the trapezoid is 0 pixels wide. Here's a fun experiment! If you use small triangles, like 5px wide, you can create the illusion of rounding by making the zero-pixel element into a 2px wide element!

Experiment 1, 5px arrow, 2px element

At larger sizes, the illusion still works okay (note: I am not currently on a retina display, so it might look crap on that):

Experiment 2, 15px arrow, 3px element

As it gets bigger, it feels to me like the illusion breaks down:

Experiment 3, 25px arrow, 3px element

I wonder if there's some trickery that could be done with border-radius, but uh... I'm not going to try that experiment right now.

DISCLAIMER: The pollen count is very high, my eyes are watering constantly, and thus my vision may be blurred... so maybe every angle looks rounded to me. Other, less allergic eyeballs may need to be consulted. :bouquet: :bee: :joy:

[stephanieosan]

That first one looks pretty round. I'm also hearing an undertone of "maybe we shouldn't have a rounded triangle because it's way fussier to implement."

[Scotchester]

It's a liiitle bit fussier, but not that much. Both techniques (SVG/image-based and Magic CSS Triangle) are fussy in different ways. Neither is rocket science. Whatever Design prefers is fine, IMO.

[ascott1]

+1 to what @Scotchester said. It just comes down to considering the best way to implement it.

[mebates]

@stephanieosan and @huetingj any updated visual changes after the working session Jen mentioned 19 days ago? Can we close this out by Monday?

[marteki]

For awareness and completeness of examples, here's Claiming Social Security. We use tooltips in many places, including in paragraph copy.

Around labels, tooltips unactivated:

Around labels, tooltip activated:

In paragraph body copy, tooltips unactivated:

In paragraph copy, tooltip activated:

[stephanieosan]

Here are visual iterations based on above feedback:

[designlanguage]

In a couple of the instances @marteki posted, the blue color for the tooltip seems a little distracting. I understand that we use blue consistently to show something can be activated, but should we consider toning down the impact?

When used inline with text, it can disrupt the flow, as I think @benguhin mentioned in a working session. Would gray or a lighter blue solve that and still maintain accessibility?

This may be an edgecase, but when it's inline with radio buttons, it might seem at first glance like an additional option:

[Scotchester]

I agree with @designlanguage's concerns. Did the SSA team consider following the example of eRegs for indicating words for which definitions can be retrieved (a simple underline with a background color change on hover)?

@designlanguage On using a lighter blue: White is only accessible on full-on Pacific Blue. The question mark would have to change to black to use a lighter blue.

[benguhin]

@designlanguage I think for the inline usecase we may be better off underlining the term in a way that distinguishes it as a defined term but doesn't look like a standard hyperlink. This is sort-of what eRegs does for defined terms, though the interaction doesn't yield a tooltip:

I think the underline is probably best for inline tooltips for two reasons:

1. There's less visual noise with chunky circles breaking up text
2. The tooltip is often referring to a term that involves multiple words, and an underline can make it clearer to the consumer which words are being defined/tooltipped

---

Overall, we should emphasize that it's best to use the paragraph text itself to explain what terms mean (and for form labels, we should use helper text that's shown by default to clarify things that aren't clear). There will often be edgecases and technicalities that are best communicated in a tooltip, but I think we want to avoid a future world in which we use confusing terms in the default view and assume that folks will read the tooltips when they get confused.

[caheberer]

I'm wondering how successfully users can determine the difference between a blue underline and gray underline (and their expected behavior).

I agree a plain language approach to the actual content is ideal.

[mebates]

Once we resolve the color issues, we are going to move to publish. @marteki, would you be willing to pull the in-line definition issue into a separate topic? We want to get this one sealed up for tooltips that aren't in-line.

• [ ] Add to the Design Manual
• [ ] Update Capital Framework
• [ ] Update .ai template(s) to reflect new standard

[marteki]

Can do!

[Dnpizarro]

I know we deviated a little, but I just wanted to circle back. @huetingj and @stephanieosan has there been any updates for this issue?

[marteki]

We have a first pass at tooltips, for group review: http://caheberer.github.io/design-manual/ui-toolkit/tooltips.html

The examples given there are in image form, so not functional or even coded. We chose to incorporate recommendations for inline tooltips as well, as discussed in #335.

We've shopped this around to various design working sessions, but further feedback is greatly welcome at this point. What have we maybe missed, or what else should we maybe be thinking about?

[Scotchester]

I suggest removing the final section on "Icon labels". I'd prefer not to canonize this kind of usage. If it needs to be used, someone should have to make a strong case for an exception to do so.

[Scotchester]

Some thoughts on states:

• We need to define hover, focus, and active states for the standard question mark icon. (Particularly if we're using click-only activation.)
• Are inline tooltips also click-only? The depiction of the hover state shows the tooltip text.
• We need to define focus and active states for the standard question mark icon.

[Scotchester]

In seeing the image of a tooltip over some text:

I submit that it would be nice if the design of the tooltip could set it off a little more from the page below it. It's not bad in the earlier examples, when it's just sitting on white, but when it's sitting on content, it feels a little messy to me.

[marteki]

Lots of good feedback from the Aqua Baobab working group on 9/2!

• "Icon labels" should not be canonized as a best practice, despite their use on several of our websites currently
• Make it more explicit that we're not to put essential content inside a tooltip container. Describe what essential vs non-essential means, through examples. Provide alternatives to tooltip usage.
• Add more context to the examples, including showing the tooltips in place on example pages and over form fields and the like. Perhaps show examples of what is not recommended practice.
• Add more rules around the placement of tooltip icons next to the phrases they're defining. What side of the word do they appear on, how far away is the icon from the phrase, is the word also clickable, etc.
• Add a linespacing spec anywhere that font size is defined.
• :+1: to the character max. The number 250 felt a little arbitrary, so we might want to explain more why the number was chosen.
• Need to define rules around the inclusion of links within tooltip containers (as used on OAH), and determine any impact on the interaction of engaging with the link or closing the container.
• Should it be actionable only on click everywhere, or should hover be supported as well on non-touch devices? (Note: hover-only interaction on desktop tested poorly for OAH pages.)
• if there will be a cursor change on hover, explicitly state so and what it would be.
• When should tooltips be used in forms instead of helper text? Maybe explicitly define when. (And consult with @stephanieosan's team, who are currently looking at form fields?)
• Consider making the tooltip container width based on column width, so it aligns with the grid at whatever screen width.
• Will tooltip containers always be above the icon? It's not stated on the page. There was some concern about tooltip containers overlaying form fields. Request made for examples in visual context.
• Do we know whether or not the eRegs tooltip format is usable? Has it been tested? Maybe we should look at the analytics for them, if available. We could compare them to the HMDA tooltip format.
• Maybe display what happens to an inline tooltip that wraps over two lines?
• Bootstrap has two patterns for what we call tooltips: tooltips and popovers. Maybe gain insight from them?

[ielerol]

Sorry, jumped over to the inline tooltips issue before I saw Marteki's comment that you're working on them both here. My comment: We do have an outstanding issue in eRegs to differentiate the underlines for definitions from the underlines for links. It wasn't a high enough priority to make it into the changes that will be rolled out in the next month, so we haven't done a lot of exploration, but the initial thought was to change the definition links to a dotted underline style. Which only works in this case because the eRegs unvisited hyperlinks are solid rather than dotted.

Although eRegs might not be the ideal model currently, I do think some kind of text-based visual distinction is less obtrusive than the minicon icons, when inline in text paragraphs. We've discussed also adding a faint background gray to the defined terms, lighter than the hover state gray.

[ielerol]

I have a monthly analytics report from eRegs as well, that doesn't really show any interactions with the definitions links, but I don't know right now if that's because no one's using them, or the current code doesn't track those interactions.

eRegs is also a highly specialized tool with an unusual user group, so I don't think I'd rely on data from it to make decisions about broader consumer-facing designs.

[nataliafitzgerald]

Visually, I prefer A and C that @huetingj posted a while back.

A) This one is nice and simple but does get a little lost amidst the other page elements.

C) I'm leaning towards a preference for this version. The "drop shadow" does help the tooltip to come off the page a bit. For the shadow, make sure to use a solid gray (no transparency) and offset it more to the right (imagine the light coming from the top left).

[caheberer]

@Scotchester I was planning to follow our current standard for buttons for the icon hovers, but I noticed you mentioned on our tables issue that white on Pacific 80 isn't accessible. Do you know if our button standard will be changing?

[Scotchester]

@caheberer That's a great point... it probably should.

We didn't assign Buttons to anyone because I guess we figured it was pretty well covered already. (Is that right, @benguhin?) But perhaps we should reopen them and discuss.

Off the cuff, I'd suggest changing the hover state to the newly-proposed darker version of Pacific, as long as the active state (Navy) is different enough to be noticeable when hovering and then clicking. An alternative would be to make the darker Pacific the normal button state, and shift to regular Pacific on hover.

[caheberer]

Get your tooltips recommendation here! After incorporating feedback, our recommendation is ready for review by approvers! NOTE: this is a use case and style review, not a code review.

Please take a look at: http://caheberer.github.io/design-manual/ui-toolkit/tooltips.html

Approvers: @nataliafitzgerald @benguhin @Scotchester @JenniferHoran

Please post your comments by Wed. Sept. 16th. Thanks!

[KimberlyMunoz]

For the inline tooltips, would it make more sense to use something that we could base off of the <abbr> element. Hover links are difficult to make accessible, but <abbr> has that built in. We should be able to style the way the links look, but we might not always be able to style tooltip itself since it is browser/OS dependant.

[benguhin]

This is great. On the UI front y’alls are totally approved!

Some granular notes as you finalize all the details:

• The example of why helper text is best for the the complaint form question is great, as we’ve seen dozens of usability testing participants benefit using that additional text to help them choose an option. If you end up keeping this specific example, make sure to remove the red “required” asterisk from the question label, as we’re recommending against the use of asterisks in our form field standards.
• The last bullet under ‘Do not use when’ reads “The tooltip is in a hero,” which is a bit confusing because it’s recommending that the tooltip shouldn’t be in a hero. I recommend changing to something like “The content is in a hero”
• It’s not clear whether the max for content is 225 characters or 5 lines (you should pick one). A character limit is probably the best way to go, as it doesn’t vary based on screen size and zoom level. Due to the inevitable curiosity of future staff and stakeholders, you should also document why 225 was decided as the max (it doesn't need to be on the Design Manual page, though; including the reasoning in this issue is fine).
• I love the rule for how the tooltip aligns to the closest edge of the element being tooltipped in cases when it can’t be centered.
• The decision to use the pointer for standard tooltips and the question mark cursor for inline tooltips makes a lot of sense (the standard tooltips already have a question mark in the default state, so another one in the cursor would be overkill, and using a pointer over the inline tooltips might make them look like they’re actually hyperlinks). That said, it still seems a unnecessary to have different cursors for the same interaction, and I don’t think the question mark cursor gets much use elsewhere on the internet (so users might not understand what it is). I think what you have here is great and I’m happy to move forward with this as the standard in the DM and Capital Framework, but we should make sure to pay attention to how it performs in upcoming usability tests.

[Scotchester]

Style

• Include an image of the default question mark icon, or expand the text to the full width of the section.
• I feel like the name of this section doesn't accurately describe the content it contains. It's more like behavior and placement guidelines. I don't have a better suggestion, though.

States

44px radius around icon containing no other actionable items, to avoid target issues on touch devices

Any example of a tooltip next to a form field label will violate this rule. Maybe change the wording to say that this is preferred but not always practical?

New accessible Pacific 80 color (specify)

Should be something like "Dark Pacific", as it's darker than regular Pacific.

Navy 80% background color

Should be full Navy? Might depend on how much both colors contrast with Pacific and Dark Pacific.

2px Gray 50% bottom and right border

Probably clearer to call this "solid drop shadow" rather than border. The whole box already has a 1px border.

If container cannot be centered above icon because of proximity to either page margin, caret moves left or right accordingly. In this instance, the edge of the tooltip container should align to the right or left margin closest to the icon.

This sounds lovely, but difficult. I look forward to seeing how your Cat and Virginia handle it :)

Inline

• Not related to my approval from a FEWD POV, but the 50% gray dotted underline seems way too subtle to me.

Other than those items, all looks good!

[caheberer]

Transferring @nataliafitzgerald 's comments to this issue:

DM Styling edits:

• For content under the H3's, the width of the content should be 560 px (to match the DM styling). Update intro paragraph under "Style", "Special cases..."Inline" (also, it looks like you have skipped a header level here, was that intentional?)
• The space under the rule line that comes after "Style" should be the same as the space under the rule line that comes after "Use".
• How are you aligning the images that come to the right of the bullet lists? It looks like some are top aligned to the header for that list and some are lower down. For example, "hover" (top aligned) versus "activated" (lower down).

[caheberer]

Thanks for the feedback, I’ve compiled a revision list that I’m working on to complete approval.

• [x] Remove red asterisk from first example
• [x] Change “The tooltip is in a hero” to “the word or phrase needing to be explained is in a hero”
• [x] Remove “5 lines” from character max
• [x] Expand “Style” and “Inline” subhead text to full width
• [x] Add that 44px radius around icon is preferred whenever possible…
• [x] Change text ‘bottom and right border’ to “solid drop shadow”
• [x] Update Pacific and other colors once new palette is decided
• [x] Check/fix spacing after “Style” rule line

Other notes: @natalifitzgerald The alignment of images are all top-aligned, the image in “Activated” only appears lower because the tooltip is part of the image. (These are not coded.)

Max character count of 225 was chosen based on a sampling of explanations and definitions that currently exist and to not exceed 5 lines on large screens.

[caheberer]

@Scotchester @benguhin @nataliafitzgerald

Following the new palette, I'm proposing the attached for the tooltip icon states, which I also think we should use as our button standards. This change will make our buttons 508 compliant, because as @Scotchester mentioned, our current white on Pacific 80 isn't accessible. I've attached an image with the new hex/named values.

[JenniferHoran]

This is great, thank you all!

[marteki]

Pinging @benguhin @nataliafitzgerald @Scotchester -

Can each of you give a :+1: or otherwise comment about changing the tooltip icon hover/focus/active state colors and matching our new color palette? It's our only thing left to figure out for this!