Recent Changes to Help Text in Screen Components

This is a memo from the Flow product team.

Some customers have noted that, for some screen components, the behavior of the help text button recently changed from “hover to see help” to “click to see help”. Here’s some background behind that change.

Originally, all Flow screen components supported formatting, embedded images, and embedded links in their helptext. They were written in Salesforce’s older Aura framework. They always required a click to open. Here’s the familiar UI that allows customers to create elaborate help content for each screen component:

Over the last 2 years, we have been converting the Aura components to use Salesforce newer and recommended Lightning Web Component framework. There are a lot of reasons to embrace the latest core Lightning technology like this, but sometimes there are side effects if the behavior of the new ‘base’ components provided by the framework doesn’t match the older behavior, and this is what happened with Help behavior. In LWC, the base help system uses tooltip semantics, causing the invocation to be on a hover but lacking support for rich text, embedded images, or embedded links. So for the last year or two, some screen components have had help bubbles that activated on hover.

After a few of the screen components were converted, some customers reported in that their investments in rich help were getting lost because the new hover text couldn’t show anything beyond plain text. Part of that is a mechanical limitation: with hovering behavior, if the hover text bubble has a link in it, you can’t click on that link because as soon as your cursor moves off of the triggering icon, the hover text goes away.

As a result, the Flow team has changed the behavior of its LWC screen components to use a popover. As part of this design, the popover is implemented with a click. While it’s possible to enable the popover to be implemented with a hover, we’d have to put a button next to the help icon that would enable users using screen readers and/or keyboards to have something to focus on, and so having to have two different visual elements side by side seemed unnecessary.

However, if there are users out there who really prefer the hover behavior, we’d like to hear more about that.