[ML] Add responsive layout to Index data visualizer, fix doc count chart margin

[qn895]

Summary

This PR addresses #137257 and better handles the layout when the screen width decreases. Changes include:

• The css is now updating based on the body content width (which window's width - side bar navigation's width).
• The link cards are shown in the bottom instead of on the right side when the content width is smaller
• Refresh button will only show the refresh icon when the size is small
• Fix the doc count chart margin too big causing the chart
• Fix wide time range display with sparse data

For reviewers:

• kibana-design: 2 .scss files were deleted

Before

After

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space.	Low	High	Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks.	High	Low	Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled.	Medium	High	Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[qn895]

@elasticmachine merge upstream

[mdefazio]

Hi @qn895, just a few notes:

Looks like the top section goes outside the page a bit as we go to lower breakpoints. This might be as simple as removing the min-width on the data view title—I think the breakpoint kicks in before that condenses too much.
I would also recommend putting in some margin between the data view button and the 'use full data' button. I'd suggest 16px to denote that these are different sections, and keep the 8px spacing between items in a section. Tiny nit, but it does clean it up.

Not sure how much we should concern ourselves with this small of a breakpoint, but as the table switches to the mobile view, seems like there's some oddities in the order of things. Perhaps something worth exploring separately depending on the need?

Should we consider truncating the name to avoid simply cutting off the text? Possible that this could look like a shorter field name that it actually is.

I think we could decrease the size of these icons to give the text more room. Again, a tiny nit and not a blocker, but would help clean this up a bit.

---

I will mark this as a blocker, but acknowledge not all of these are required and primarily suggestions. The first point is probably the highest priority IMO. But happy to discuss these further.

[peteharverson]

@mdefazio @qn895 do you think the narrow view would benefit from having bigger padding below the main panel and 'Explore your data', to show that the title and cards belong together?

[peteharverson]

For a user without Discover access or the ability to create ML jobs, when there are no available actions, we still leave space on the right for the sidebar. Can the main panel go full width:

[mdefazio]

@peteharverson I agree and thanks for adding/catching these!

[peteharverson]

This behavior isn't from your changes here, but wondering if we should change it as part of this PR. The 'Explore your data' title is tied to the visibility of the Discover card, and isn't shown if just the ML cards are shown. I'm thinking we should show this section title if any of the cards are visible:

With Discover plus ML write access:

Without Discover access:

Thoughts @qn895 @mdefazio ?

[peteharverson]

Gave this another test and all the layout fixes look good. The only issue I'm still seeing is where the date picker doesn't update with 'Use full data' for users without access to Discover.

[mdefazio]

Took another look and everything is looking good! Thanks for making those edits!

[qn895]

@elasticmachine merge upstream

[darnautov]

Some observations regarding the visual part:

1. Search bar doesn't fit the panel for some breakpoints

2. Probably has to be fixed on the EUI side, but placeholder content is wrapping occasionally

3. Not sure about the "Explore your data" section for smaller screens. Did you consider displaying them inline? cc @mdefazio

[darnautov]

could you please create an issue in the elastic-charts repo and mention the link in the comment?

[darnautov]

do we actually need a default static value?

[peteharverson]

Fix for the Use Full Data button looks good, and rest of the changes to fix the responsive layout LGTM

[darnautov]

LGTM

[qn895]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: dac85b0

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
dataVisualizer	309	301	-8

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
dataVisualizer	24	25	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
dataVisualizer	530.1KB	380.0KB	-150.2KB

Unknown metric groups

API count

id	before	after	diff
dataVisualizer	28	29	+1

ESLint disabled in files

id	before	after	diff
osquery	1	2	+1

ESLint disabled line counts

id	before	after	diff
dataVisualizer	45	46	+1
enterpriseSearch	19	21	+2
fleet	61	67	+6
osquery	109	115	+6
securitySolution	436	442	+6
total			+21

Total ESLint disabled count

id	before	after	diff
dataVisualizer	45	46	+1
enterpriseSearch	20	22	+2
fleet	70	76	+6
osquery	110	117	+7
securitySolution	512	518	+6
total			+22

History

• 💛 Build #96188 was flaky 38b8a06
• 💚 Build #95765 succeeded 1a64c1b
• 💚 Build #95477 succeeded 57fcb2e
• 💚 Build #93884 succeeded ab349bf
• 💔 Build #93442 failed 6766635
• 💚 Build #93322 succeeded 1fc4100

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @qn895