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!