Tooltip redesign

[nickofthyme]

Is your feature request related to a problem? Please describe.

As the chart functionality has grown over the past several months the current tooltip design has come to show its limitations for more complex charts.

Related to #580

Related issues/requests

• Expose tooltip z-index #922
• Order TooltipValues in CustomTooltip by distance to pointer #835
• Piechart tooltip shows field names #623
• Time offsets on tooltip #919
• Allow tooltip option for max number of items #872
• Click on point on chart so that tooltip stay visible and "sticky" at where mouse clicks #815
• Allow selection of single series from tooltip #562
• More TooltipTypes #655
• Band charts should show y0 value in tooltip, be treated as a single series #607
• Provide a way to pass a value to the tooltip header #296
• Allow the value part of the chart tooltip to be hidden #275
• Individual tooltip formatters within a series #241

Related to tooltip placement:

• Tooltip: fixed position instead of following mouse and improved line indicator #921
• Annotation tooltip position #297
• Tighten tooltip placement on single point charts #927

Describe the solution you'd like

The tooltip should be redesigned to handle all of the following use cases.

Multiple x or other values

Up until now, the tooltip is designed with the x value being constant for all values in the tooltip. This is no longer a valid assumption. Possibilities include a table style tooltip or indented values.

Table style

Indented style

The issue with the table style tooltip is that the field names for x, y, mark, etc. could be very long, creating a very wide tooltip that is less useful.

Aggregate values like min, max, etc.

When multiple values are allowed the logical progression would be to allow for aggregate values to be used per tooltip item. The indented files could be a better way to show this alongside the respective value, see mock up below.

Multiple values from the same series

Up until now, the tooltip would never have two of the same series in the tooltip with the exception of the banded values.

Having multiple values in the tooltip from series based on an extension of the current tooltip design would repeat the series name for each. This seems redundant and avoidable.

Upper and lower (aka banded) values

Currently, we support this style but the items are repeated for each series and the order is not configurable.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Checklist

• this request is checked against already exist requests
• every related Kibana issue is listed under Kibana Cross Issues list
• kibana cross issue tag is associated to the issue if any kibana cross issue is present

[nickofthyme]

Also thought about a collapsed mode where if multiple values are to be displayed, they only appear in detail when hovered over a point/bar. Otherwise, they would be a simplified item, similar to what there is now.

[nickofthyme]

@cchaos would be happy to get your insight on this whenever you have the time. Thanks!

[markov00]

I'd like to link this Kibana issue here so we can think of it when redesigning the tooltip elastic/kibana#60013 (comment)

[cchaos]

@miukimiu Could you help out on the design side for this?

[miukimiu]

Yes, I can help. 🙌

[nickofthyme]

Hey @miukimiu, any update on this design?

[nickofthyme]

To add to this issue.

I think we might want to separate the cursor/crosshair styles from the tooltip styles/options.

The cursor/crosshairs should look something like...

const CrosshairType = Object.freeze({
  VerticalCursor: 'vertical' as const,
  Crosshairs: 'cross' as const,
  Follow: 'follow' as const,
  None: 'none' as const,
});
type CrosshairProps = {
  snap?: boolean;
  type?: 
}

And the tooltip props should be something like...

type TooltipProps = TooltipPortalSettings<'chart'> & {
  type?: 'simple' | 'complex' | 'table'; // future tooltip types
  headerFormatter?: TooltipValueFormatter;
  unit?: string;
  customTooltip?: CustomTooltip;
};

Doing this could allow showing the crosshairs while hiding the tooltip and vice versa.

[miukimiu]

Hi @nich07as,

I'll prioritize this and I might have designs next week.

[nickofthyme]

Tooltip should pass original datum within the TooltipValue to allow for users to extend the tooltip with additional properties outside of just the y value.

cc: @smith

[nickofthyme]

@miukimiu any timeline on this yet?

[sorenlouv]

Already mentioned on Slack but posting for visibility: This is needed for elastic/kibana#88852 which is scheduled for 7.13 🙏

[ghudgins]

we're going to need the ability to have multiple actions on a selection or range selection of data because of these cases:

• filtering (most common case today)
• take selection "somewhere else" - in observability, for example, "open in APM"
• creating annotations (although, this could be handled with an authoring 'mode' on the vis editor side) CC @MichaelMarcialis

i've also added these to the requirements doc that mirrors this meta

[gvnmagni]

Hi all! I've been working on this tooltip redesign and I'll try to recap here the main aspects of the exploration I made.

Three important things:

1. This work is not final, it's the first step of a conversation that we all are going to have in order to find the best solution for our tooltip. The goal of this exploration is to start discussing around it, please feel free to comment or to contribute in any way.
2. I'm not fully respecting our design system, in parallel I'll be fixing this
3. This would not have been possible without the previous work made by @miukimiu who made a really great first exploration from which I took a lot

Let's now get into the main part.

Concept

The first step of complexity that I would love to introduce is the possibility for the tooltip to be different according to the element that triggers it. Datapoints and background can have different set of elements that appear within the tooltip.

To be sure that users will always be able to access the background we should introduce a little inner margin at the top of the chart, this concept will be useful for other purposes as well (overall look & feel, scale rounding to pretty numbers...)

Floating vs Sticky

Everything is debatable, but I'm afraid that if we want to solve for all the requested features and issues that we have, we can't avoid defining a behaviour that will make the tooltip to stick on the chart and to be clickable. (Long list of categories and therefore scrollable tooltip, possibility to select the categories that we want, copy-paste values...)
In this exploration the tooltip is floating when hovering elements and gets sticky once the users click.

Actions

The concept of introducing actions within the tooltip is not new, the Observability team has this in mind already and it could be really interesting for making the data exploration easier, faster and more impactful. Actions could differ according to the context but they can include things like:

1. Create a new annotation
2. Filter by time and by categories
3. Go back in time
4. Exclude non relevant points from dataseries

Possibilities here are endless and more important than this, it could be customised for all our different solutions.

Modular structure

The most important feature in this exploration is the tooltip flexibility, this would be granted by a modular structure able to accept different kind of elements according to the context. This way all the different teams will be able to customise how the tooltip behave following their needs. (eg. the same tooltip could be different in Observability and Discover, even if on the same typology of chart)

Tooltip Design & alternatives

The base design is quite simple, this new version includes the bottom bar with instructions on how to make it sticky.

These alternatives show how we can deal with different contexts and typology of information.

Behaviour

This is how we could make this to work. I'm posting here 3 animations (please consider that they are only prototypes made in Figma, they are not 100% what I'm envisioning but we are close). First of all let's start with the classic animation, when the users interact with a datapoint. The hover event shows the data values, the click event makes the tooltip sticky and allow the suers to interact with it.

NOTE: the proximity between the mouse click and the actions is crucial here, we'll have to be sure to position the tooltip correctly in order to minimise the users effort in activating these actions.

Second, here is what happen when the users interact with the background. There is already a little discussion about the data categories that disappear and it might be better to have them even after the click, this is exactly the kind of configuration that we have to talk about in order to find the best behaviour

Last one, the click & drag interaction. A bit more different to make in Figma but we can get the concept. While you drag the tooltip overview tells you how many elements have been selected and once you release the click you get the whole tooltip.

I know this get in conflict with the idea of panning along timeseries with the drag, we'll have to see how to make this work if we want to keep both functionalities.

Edge cases and exceptions

Few cases where we might want to create exceptions or at least to take in consideration how the tooltip should behave.

NOTE: please feel free to add any additional case that you have in mind, this is exactly the kind of issues that we have to solve! 🙂

In the end, as you can see there is a lot to work on! Hopefully the base concept behind this exploration should be good enough to solve most of the problems that we currently have or at least to be the starting point for that. As I said my goal is to start a conversation so please feel free to contribute, to comment and to add any kind of issue/feature that I might have forgot, I'm sure there is a lot of them! 🙂

[miukimiu]

Thanks, @gvnmagni. This is looking great!

I'm not fully respecting our design system, in parallel I'll be fixing this

Let me know when you reach the point of using Elastic UI, and likely, we can share some UI patterns. As @ryankeairns pointed out in the Product Requirement doc there are some designs patterns for actions inside the popover that we can reuse to have some consistency (filter in, filter out..): elastic/eui#5132.

[ryankeairns]

@gvnmagni great writeup, very thorough! The examples and prototypes paint a clear picture of where things are heading and leave me feeling excited for this to develop. Providing contextual data/actions based upon where you hover or click is resonating with me as is the scalability of the popover design you've put forth.

I look forward to participating in discussions, running through some use cases, and collaborating with the DataViz, Obs/Solution, and EUI teams.

[markov00]

Linking this other interesting requirement: elastic/kibana#124034 add charts in tooltip

[chandlerprall]

Been wanting to add a couple anecdotes & POCs for a while, finally found some time to put the examples together.

Pinnable

First up is tooltips that stay open indefinitely when pinned. On hover, the tooltip displays and the user can interact with any elements in the tooltip itself. To remain open when the anchor+tooltip is no longer under the user's cursor, each tooltip can individually be pinned open.

https://codesandbox.io/s/tooltip-exploration-pinning-2mdqc?file=/src/App.js

tooltip_pinnable.mov

Delayed-sticky

This is a pattern I came across while playing Crusader Kings III. Tooltips open on hover but aren't interactive until some period of time expires (3s in my demo). I hate this pattern (as do others), and it took me an embarrassing amount of time to understand what caused a tooltip to remain open or not. Including here because it's a pattern in the wild, with an ask that we don't do anything like this 😅

https://codesandbox.io/s/tooltip-exploration-timed-fr8xe?file=/src/App.js

tooltip-delayed.mov

As it works in Crusader Kings, note the spinner in the top-right of the popovers to indicate time remaining in the delay.

Crusader.Kings.III.2022.02.10.-.14.28.25.00.mp4

[gvnmagni]

Thank you Chandler, I really appreciated the two examples, let me add a couple of considerations.

Pinnable

This option got me really interested because it would reduce the number of clicks required to get to interact with the tooltip and we will definitely have to take this in consideration. The only downside that I see is that moving through very close data points could be difficult if the tooltip stays on the interface, in your example the tooltip will cover the datapoints that live above the hovered one and to get to them we would have to move around to make the tooltip disappear and then get to the desired datapoints. This could became frustrating really fast

Delayed-sticky

I promise we won't do anything like this 🙂
Even though got me questioning myself why they did something like that, it really doesn't seem a good choice but there should be a reason

[cchaos]

My 2 cents on these types of interactions:

Creating a new convention around the interaction of tooltips/popovers is tricky and would need to be fully tested. I would honestly advise against it because our products need to be fast to learn and quickly aid in the user's task vs needing to learn a new interaction. I think there's a very simple solution/guideline we can adhere to that would mostly solve this issue for all usages.

Interactive vs non-interactive tooltips:

A. If the anchoring element is interactive itself (button, link), the tooltip cannot contain any other interactive contents. This enforces the primary action to always be the interaction of the anchor and keeping the tooltip contents as strictly extra guidance that is not necessary for usability.
B. If the anchoring element is not-interactive itself, but is strictly to open the tooltip/popover, then the tooltip can have interactive contents. This does not mean that they have to click to view the tooltip, it just means that the interaction on the element forces focus onto the element which would also render the tooltip. If the user's focus then transfers to the tooltip contents, the tooltip continues to remain visible.

These guideances are very similar currently in how we differentiate between tooltips and popovers (the components themselves), with the exception of allowing popovers on hover or tooltips to contain focusable elements.

There are other ways to allow quick access to functions that may have normally been the anchor's primary action, like allowing a specific key+click combination.

The trouble with "pinnable" tooltips, is that the user still has no control over the position of this element which means it's pretty unuseful when you have multiple that overlay each other.

To circle it back to charts specifically, if we're relying on tooltips for users to see the raw values of several points at once, we're using them wrong.

[markov00]

To circle it back to charts specifically, if we're relying on tooltips for users to see the raw values of several points at once, we're using them wrong.

Hi @cchaos can you please expand on this?

[cchaos]

Mainly that if they only way that user's can compare the data values is by needing to open several tooltips, then we're overcomplicating what a chart is (which is usually a quick summary to visualize patterns) and we should be allowing user to view the raw data instead through some other mechanism / drilldown.

[markov00]

Totally agree. pinnable tooltips should not be considered (at least within charts).
I think we agree that the design proposed by @gvnmagni goes in the direction of B with a single tooltip/popover instance open at a time.

B. If the anchoring element is not-interactive itself, but is strictly to open the tooltip/popover, then the tooltip can have interactive contents.

I'd like to know your opinion @cchaos about the use of right-click when the anchoring element is interactive itself, like for HTML links where you can right-click and open in new tab.

[cchaos]

Right click action should be used sparingly and only as another means to the same action. It alienates touch screen users and has low discoverability. So as a shortcut to certain actions, sure, but not as the only way to that action.

[gvnmagni]

Thank you Caroline! Just wanted to confirm that it's not planned to allow users to open up multiple tooltips on the same chart, values that can be compared will take place within the same tooltip (single categories of a stacked barchart, for example).

[ghudgins]

for custom tooltip patterns, there's a request for new line character support on TSVB today elastic/kibana#66088

[sorenlouv]

Another use case for having custom tooltips is in APM where the comparison features enables the user to compare two timeseries (related issue)

Current tooltip

Suggested tooltip

[gvnmagni]

Thank you @sqren, we are considering this kind of cases as well. The images you posted show the problem we had in mind at the beginning and the solution you propose is actually my favourite as well, elegant and perfectly clear to read.

Unfortunately this could get more complex. In your example all data series plotted refer to the same metric (Average latency) in two different moments in time. This make it easier to handle, we can move the label Average Latency to the header and just display the datetime next to the colors.

A more flexible solution should consider other potential data series plotted that are not related, in that case in order to be exhaustive within the tooltip we have to be a little more verbose. (see the following few images as example of tests that we are doing)

Said that, I just wanted to let you know that we are considering this and we are trying to find the best solution, thanks a lot for reaching out, if you have any suggestion please feel free to add them! 🙂

[sorenlouv]

Said that, I just wanted to let you know that we are considering this and we are trying to find the best solution, thanks a lot for reaching out, if you have any suggestion please feel free to add them

@giovanniblanco I realised I never replied. Thanks for the reply and it's great to hear you are thinking about how to solve this. I can see why you'd like to verify a possible solution against several use cases to make sure it's generally useable. That being said, I hope we can land on something sooner rather than later. Don't hesitate to reach out if you want to hear more about our use case.

[gvnmagni]

Hello @sqren , we actually have an interesting update! Apologies for not getting back here to notify that... we realised that the solution for this problem comes from the intrinsic modular structure of the new tooltip. In case of a timeshift, the best solution would be (from my point of view) to rely on a double header so that we can be explicit on what's represented.

In the following image you can see that approach (two ways, according to what you prefer to be your preferred dimension) applied to a case that is slightly more complex than yours since we considered 2 classic series and 2 timeshifted series, but I hope this could help you.

This is already available and you can proceed using that, I'm tagging @markov00 that is way better than me in helping for any technical matter

[sorenlouv]

This is already available and you can proceed using that,

Ahh, this is definitely a huge improvement over what we display today. I'll look into using the double header. Thank you!