[Wordcloud] Replace kibana tagcloud with es-charts

[stratoula]

Is your feature request related to a problem? Please describe.
I am currently working on replacing the kibana tagcloud viz with es-charts and I want to report some gaps that exist between the two implementations that need to be addressed.

• onElementClick: I want to be able to click on a word and get the clicked value. Right now I get:

{
    "smAccessorValue": "",
    "groupByRollup": "Word count",
    "value": 9,
    "sortIndex": 0,
    "path": [],
    "depth": 0
}

every time I click a word. I would like to get the clicked term. This is needed because we want to trigger the filter action every time a term is clicked.. Moreover, I see that the click event is triggered everywhere and not only when I click a term. (I am fine with it as soon as no term is returned when I click on a blank space).

• I need to be able to display/hide the label. This label comes from the configuration. It contains the bucket field, the ordering and the metric. I could construct it on the kibana side and just pass it as a prop to the chart. We can further discuss it.

• Functional tests. I need to check for the following conditions:
• get all the rendered terms
• get the font sizes per term
• be able to select a tag and click it (I can overpass it by clicking a hardcoded x and y but if we can have this info would be awesome)

Kibana Cross Issues
elastic/kibana#95539

Checklist

Delete any items that are not applicable to this feature request.

• 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

[monfera]

Thank you Stratoula!

1. Label
   @markov00 might have a different take, at the moment my preference would be that Kibana supply the chart label (I'd call it a title, but maybe there's a distinct chart title in Kibana above the chart?) because it probably needs application specific labeling (if at all), and its contents are also application specific (eg. should show some total count or not); also, this way there's clarity about internationalization. In fact it may even be preferable to overlay the chart with your own label, because then it'll be inherently part of the accessibility approach on the recipient page. There's also the question of handling text overrun (won't ever happen, let's not bother with it? or truncate with ellipsis? etc.). Looking for your and Marco's feedback on this.

2. Padding
   The placement of the label requires space, and assuming that the label render responsibility is with elastic-charts, it needs to set aside the appropriate area. It can be handled internally. Even then, is there expectation about leaving a gap of a specific pixel count or chart height ratio between wordcloud proper and title, and below the title?

3. Click event handling
   Does the functionality of clicking on a specific word, and getting a callback for just that word work in Kibana? I'm asking it because there are some intricacies. Examples:
   very small words might be placed in the crevices between letters of large words
   moreover, very small words can even be placed inside other letters, eg. in the letter O, u, etc. if there's enough space
   the click doesn't have unambiguous semantics: is it the text ink only? or, for better adherence to Fitts law, the bounding box? but in the latter case, bounding boxes may easily overlap even setting aside the above concerns, because the placement observes the contour of the text, not the bounding box
   is the current code doing something to handle overlaps (on the offchance it's not ink based or voronoi based), eg. returning an array of two or more elements?

[stratoula]

Thanx Robert for the reply!

About the title/label: I can share with you how it currently works. It is always on the bottom of the viz and is responsive. So here you can see a panel with the panel title at the top (this is irrelevant with the viz, it is configured by the dashboard) and the label/title on the bottom. (The warning icon informs the user that the container is too small and some tags are hidden)

This case seems a little bit unrealistic from my point of view but we could keep this approach. Ellipsis also seems fine to me as it depends on the users if they want to display this or not. Right now there is a padding-top of 16px from the viz wrapper (no padding at the bottom) which seems to work fine. Here is a video that demonstrates how the responsive works.

Another idea is to not be part of the chart and to be added from us on the kibana side. Wdyt? (In case a title prop doesn't make any sense)

About the click event, right now it works with adding a click event on each word. This works pretty well, I haven't found any case of overlapping as the words never overlap and have a space of some pixels between them.
But even if it returns an array of words, we could create as many filters as the words.

[stratoula]

Update: I implemented the chart label on the kibana side so no need to be supported on the chart.

[monfera]

Thanks, Stratoula! So the two pieces of work are, the click event handling, and the provisioning of data for test purposes in the data- attribute in the DOM. I'll discuss it with @markov00 next week. Btw. what target date are you looking for these two each, to be aligned with your and your team's priorities?

[monfera]

Btw. it's good to hear that the way you configure it in Kibana, there won't be word-in-word occurrence. (For an example of that, see the middle image in the PR from @Kati-dev-hu - there's text in the "o" of "xobni"). In this case, attaching standard mouse click event handlers on the DOM elements works well. It probably works for the text-in-text case too, as most likely the rendering is ordered in that the big word is layouted first, ie. rendered first, ie. the small item atop of it can still capture the mouse. The bottom right has other examples too. Though in general it'd be worthwile to use the added configurability at some point, to enable the denser look and angle variety seen in the PR.

[stratoula]

Btw. what target date are you looking for these two each, to be aligned with your and your team's priorities?

It would be awesome if wecould replace the old tagcloud with the es-charts implementation on 7.14 but it is perfectly fine if we merge it on 7.15.

[markov00]

my 2 cents:

1. chart title: my preference is to keep it at the moment outside the chart library. You have much more flexibility then having a prop + all the possible styling options in charts
2. click handler: if there is no word-in-word occurrences, then sorting first the rendering + attaching the DOM event to each element should work

[monfera]

Indeed, my understanding is that it's already ordered this way by the d3-cloud library, so I know of these two tasks:

-attaching the click event handlers onto the SVG <text> elements (now glad we went the DOM way on this chart)

• provisioning of data for test purposes in the data- attribute in the DOM

@rshen91 as the vis accessibility powerhouse, it'd be worth taking an initial look at it, as the ARIA-* labels can be directly used on each DOM element, if needed

[stratoula]

Another update about the functional tests. There is no need to provide me with all this info that I mentioned above. As wordcloud is based on svg I can access the elements and write the functional tests!
With that being said, the only thing that is missing is the click event per text node.