Vega-lite: Support Tooltip of All Fields

[domoritz]

See https://github.com/vega/vega-tooltip/issues/188

[kanitw]

The old Vega-Tooltip show all fields in VL by default. However, the new tooltip mechanism requires users to specify the tooltip field.

To show all fields, In Vega, tooltip = {signal: 'datum'} can be specified. But there is no way to do the same thing in Vega-Lite yet.

• [ ] Design a syntax to support tooltip = {signal: 'datum'} in VG

• [ ] Should this be the default? If this is the default, then we don't need a special syntax for it. And just need to support tooltip: {value: null} to disable it.

• [ ] (later) deal with bin (we used to combined bin_start and bin_end into one field),

[kanitw]

Looks like applying {signal: 'datum'} is not that good yet as time data will be shown as timestamp.

[domoritz]

My suggestion is to support the following

• Manually specify the tooltip (we have that)
• Option to show tooltips for all fields known to Vega-Lite (using the right formatting and what not)
• Option to show all tooltips. To go around the problem you mention, I suggest that we merge the object from the second option into the datum object.

[kanitw]

What should be the default? I guess "nothing" is a safe default, but showing all fields in encodings might be a better one? Voyager did the last one though.

To go around the problem you mention, I suggest that we merge the object from the second option into the datum object.

There is no extend/assign in Vega expression. So we can't do this yet.

[domoritz]

We should add Object.assign to Vega expressions as assign then. It's an easy enough change if we agree that we want it.

[kanitw]

Option to show all tooltips. To go around the problem you mention, I suggest that we merge the object from the second option into the datum object.

Yeah but the date can still be bad if you don't include them in the field. I wonder how Vega-Tooltip previously knew that something is a date.

I also wonder if we better just drop this option and just have Voyager augments tooltip fields from its schema for raw plots. (No need to do the same thing for aggregate plots.)

[kanitw]

Suppose we drop "Option to show all tooltips" as there isn't a good way to achieve it yet.

Here could be a reasonable behavior:

1) By default, show tooltips for all fields in encoding.

2) If tooltip channel is specified, then respect it and use only the specified tooltip.

• Users can disable the default by setting markDef.tooltip = null or encoding.tooltip = {value: null}

3) The question is what if users want to use tooltip channel to augment more tooltip fields (in addition to everything else in encoding). What do we do? If we want to support this, we have to add a new property somewhere.

One possibility would be adding a tooltipIncludeAllFields: boolean property to the mark definition and mark config. (But I don't like the name here yet.)

Another possibility is to say we don't support this case.

If people agree that showing all encoding fields is good default, we can implement that first and worry about 3) later.

[domoritz]

I think we can add some reasonable date formatting in Vega tooltip if the data is a datetime (as possosed to a timestamp). I think it would be good to have e the option to see tooltips for all fields.

I'd say the default should be no tooltips.

I'd also say that we should not support augmenting I'm Vega-Lite to make things easier.

[kanitw]

I'd say the default should be no tooltips.

Why? I'd say that "show tooltips for all fields in encoding" is a better default for two reasons:

1) To support EDA, having some tooltip is better than nothing and VL normally provides reasonable defaults.
2) Having this as default requires no additional syntax (as tooltip = null can be used to disable it.) If this isn't the default, then we need additional syntax to enable it.

I'd also say that we should not support augmenting I'm Vega-Lite to make things easier.

I agree.

[domoritz]

I don't know how tooltips conflict with interactions and so I want to be careful (cc @arvind). I agree that it is useful in many cases, though.

Having this as default requires no additional syntax (as tooltip = null can be used to disable it.) If this isn't the default, then we need additional syntax to enable it.

If we implement option 3, we need additional syntax anyway. However, I see your point.

[kanitw]

I don't know how tooltips conflict with interactions and so I want to be careful (cc @arvind).

Good point.

If we implement option 3, we need additional syntax anyway. However, I see your point.

I thought we agree we wanna drop option 3.

[domoritz]

I thought we agree we wanna drop option 3.

I don't know whether we want to drop it completely. It still seems useful and many people have asked for it so I want us to have the option of adding it.

[kanitw]

many people have asked for it so I want us to have the option of adding it.

I don't remember anyone asking for it except me asking for it for Voyager, but I can make Voyager auto-generate it too. (But if you see it then it's fine.)

I agree that it's useful, but I don't want to implement a low-quality one (still problematic with date time).

[domoritz]

At the workshop, people asked about showAllFields from vega-tooltip.

[jakevdp]

I would prefer to have tooltips off by default. Particularly with wide datasets, they become pretty distracting.

That said, by far the cleanest solution as far as the schema goes seems to be show all by default, and use encoding.tooltip = null to turn them off if desired (additionally, perhaps have a config.tooltip.showAllFields setting to control the behavior in a theme?)

I really don't see any perfect solution here unfortunately...

[kanitw]

I would prefer to have tooltips off by default. Particularly with wide datasets, they become pretty distracting.

Yeah, I think we should not show all fields in the data by default. (But showing all fields in encoding shouldn't be as problematic as people won't plot too many fields anyway.)

In terms of schema, I think we can make tooltip property of mark property and mark config support the following (instead of the tooltipIncludeAllFields flag suggested above):

tooltip?: string | {fields: 'encodings' | 'data'} 

1) string for tooltip mark property would be used directly (but overridden by tooltip channel)
2) if mark tooltip is {fields: 'encodings'}, then all fields in encodings will be used.
3) if mark tooltip is {fields: 'data'}, then all fields in the underlying data will be used.

4) (Added after comments below) if tooltip encoding channel is specified, it will override any mark property's tooltip.

I think 2) should be the default as it's often handy to see values of all fields specified.
If users want to use only tooltip specified, they can set the mark tooltip to null. (In a way, I can see adding {fields: 'tooltip-encoding'} for this purpose but it's more typing to be done anyway so maybe not adding it is simpler.)

Note that I have also checked if tooltip interfere with selection but it seems fine.

[jakevdp]

If users want to use only tooltip specified, they can set the mark tooltip to null

I don't quite understand... would the tooltip encoding channel not override the mark tooltip setting?

[domoritz]

In Vega-Lite, we keep track of what fields were explicitly specified. So even if the default in a higher-precedence location is different, it will work. Explicit values override implicit defaults at a higher precedence location.

[kanitw]

I'm glad @jakevdp brought up the questions.

Actually it is better to always respect the tooltip encoding, so encoding always have higher-precedence than mark and config. If tooltip encoding is specified, let's just use the fields/value specified.

Users can still augment existing encoding fields in the tooltip when mark tooltip = {fields: 'encodings'} by adding the desired fields to detail channels.

[kanitw]

Fixed in https://github.com/vega/vega-lite/pull/3991

[kanitw]

@domoritz suggests another alternative.

Basically, use tooltip: {encodings: true} and tooltip: {data: true} instead.
This way, we can extend the support to tooltip: {encodings: ['x', 'y']} as well.

[arvind]

Or, a minor tweak to make it more consistent with selection projection: encodings and fields?

tooltip: {encodings: true} -- show all encodings
tooltip: {fields: true} -- show all fields
tooltip: {encodings: ['x', 'y']} -- show specific encodings
tooltip: {fields: ['price', 'symbol']} -- show specific fields

[kanitw]

I like the fields suggestion a lot on at first glance.

However, thinking a little bit more. It might introduce inconsistency to our prior policy for mark and encoding. Basically, mark would only supports static properties, but it doesn't support mapping to specific data fields. (That's encoding.)

By adding tooltip: {fields: ['price', 'symbol']} to mark, this is no longer consistent with this prior rule. Also, this also introduces two ways of doing the same thing as users can do encoding.tooltip = [{field: 'price'}, {field: 'symbol'}].

I agree that the latter is a bit verbose, but I wonder if we should solve that the verbosity problem with other solution instead (such as supporting encoding.tooltip = ['price', 'symbol']).