[ObsUx][Infra] Add collapsible sections in the overview tab

[jennypavlova]

Summary

We want to make the overview tab sections within asset fly-outs/detail views collapsable to make better use of screen space and reduce overwhelming users with detail.

Design

https://www.figma.com/file/XBVpHX6pOBaTPoGHWhEQJH/Infra-Obs---Flyout-designs?type=design&node-id=1585%3A135948&mode=design&t=PmXdnVkdPzJFe4ka-1

Telemetry

Section	Attributes	Common Attribute (all sections)
Metadata	data-section-id='metadata'	data-section-state="collapsed/expanded" changed to data-section-state="open/closed" to match accordion terminology data-test-subj="infraAssetDetailsCollapseExpandSection"
Alerts	data-section-id='alerts'	data-section-state="open/closed" data-test-subj="infraAssetDetailsCollapseExpandSection"
Metrics	data-section-id='metrics'	data-section-state="open/closed" data-test-subj="infraAssetDetailsCollapseExpandSection"
to be added later:
Services (⚠️ Not implemented yet)	data-section-id='services'	data-section-state="open/closed" data-test-subj="infraAssetDetailsCollapseExpandSection"

AC

• Add an option to collapse sections
  • We can use EUI Accordion to implement that
• Make sure that the sections are visible by default and collapse on click
• Add the telemetry attributes

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[jennypavlova]

Update:
Telemetry: @roshan-elastic I checked the structure of the collapsible elements and we have a button to click when showing/hiding the section and the content (title in our case) next to the button (can be also used to do the same) so the attributes will look like this:

selectors_extra_attributes.mov

• fieldset element with data-section-id="alerts" data-section-state="open" data-test-subj="infraAssetDetailsAlertsSectionExpandButtonSection"
• legend with data-test-subj="infraAssetDetailsAlertsSectionExpandButton"
• legend OR button click can be tracked: [aria-controls*="alerts"]/ [aria-controls*="metadata"] / [aria-controls*="metrics"]

  • Example:

    selector.mov

In this case, I think we should rather get the count of how many users see the state to be open/close based on the section-id.
Regarding the clicks: maybe a good way to track the clicks is the unique count of [aria-controls*={SECTION_ID_HERE}] - this generic selector includes both the title and the button and should be good for our case as it shows how many times the section is opened (no matter how exactly which element was clicked).

Do you think this will work?

---

Alerts (the closed section content):
I saw that currently, we don't show anything if there are no alerts and with the message when the section is closed (if we show a "no active alerts" message there we should also show it in the section when it is opened I think 🤔 )- so I added the message there as well - here is an example:

• 1.

  alerts_collapse.mov

Another option is to not show any message when there are no alerts and leave it empty also when the section is collapsed (keeping it simple) and show the message only when the user closes the section and has 1 or more alerts:

• 2.

  no_alerts_blank.mov

Wdyt - Which one is better -1. or 2.?

cc: @crespocarlos Just FYI: I saw that you are working on the alerts section as well this change can be a conflict probably.

[roshan-elastic]

Hey @jennypavlova,

Do you think this will work?

Thanks for this. Just trying to get an understanding of what the data would look like. Could we break down the data like this with your proposal?

Clicks on the expand/section button/legend
e.g. data-test-subj="infraAssetDetailsAlertsSectionExpandSection"

A single attribute/value which indicates an collapse/expand (regardless of whether it was the legend or the text. I don't think it's worth differentiating between the legend vs the button etc so perhaps it's best to just have a single value for both to simplify things?

Did the user expand or collapse a section?
e.g. data-section-state=collapsed or data-section-state=expanded

I suppose we'd need to correlate the current state of the section with data-test-subj="infraAssetDetailsAlertsSectionExpandSection" to infer if someone collapsed or expanded a section?

Which section was it?
e.g. data-section-id="alerts"

Is it a fly-out or detail page?
e.g. data-component-name="infraAssetDetailsFlyout"

What type of asset was it?
e.g. data-asset-type="host"

[roshan-elastic]

Wdyt - Which one is better -1. or 2.?

Hey @jennypavlova - thanks for thinking about this...I hadn't thought about this!

I'm wondering whether we could do something like this?

Collapse by default

No alerts found (but rename to 'No alerts found')

Alerts found

Then, when you expand, we show the proper alert counts and table (see issue for alerts table)?

Expanded alerts

This could be a good use of real-estate?

[jennypavlova]

Hi @roshan-elastic, Thank you for having a look!

Clicks on the expand/section button/legend
e.g. data-test-subj="infraAssetDetailsAlertsSectionExpandSection"
A single attribute/value which indicates an collapse/expand (regardless of whether it was the legend or the text. I don't think it's worth differentiating between the legend vs the button etc so perhaps it's best to just have a single value for both to simplify things?

In order to get clicks on both elements (so if we don't want to have a separation between buttons and legend clicks) we can use a selector like [aria-controls*={SECTION_ID_HERE}] ( [aria-controls*="alerts"]/ [aria-controls*="metadata"] / [aria-controls*="metrics"]) so we capture all clicks. Otherwise, if we put a test subject we can't select both the button and the legend with a single subject ( like data-test-subj="infraAssetDetailsAlertsSectionExpandSection" ) as their parent wrapper may include other clickable components:

Did the user expand or collapse a section?
e.g. data-section-state=collapsed or data-section-state=expanded
I suppose we'd need to correlate the current state of the section with data-test-subj="infraAssetDetailsAlertsSectionExpandSection" to infer if someone collapsed or expanded a section?

Yes, I looked at this again and I changed the naming a bit to make it easier to navigate (and to avoid the double "section" like in infraAssetDetailsAlertsSectionExpandSection) but that's the idea. So we will have:
data-section-state=open or data-section-state=closed
and section id will be: data-test-subj="infraAssetDetailsMetricsCollapsibleSection", data-test-subj="infraAssetDetailsMetadataCollapsibleSection", etc

And yes to all other points, so the only change will be:
Clicks on the expand/section button/legend (per section)
e.g. [aria-controls*="alerts"]/ [aria-controls*="metadata"] / [aria-controls*="metrics"]
(sum of all for total clicks if needed)

Did the user expand or collapse a section?
e.g. data-section-state=open or data-section-state=closed
and use data-test-subj="infraAssetDetailsMetricsCollapsibleSection" to find out which section is selected

---

Alerts:
So what I used to check the alerts is the active alerts count only, I probably misunderstood the idea here at the beginning. I was thinking that we want to highlight the active alerts only in the closed section. So if there are no active alerts the message (No active alerts) will appear. So basically if there are no active alerts the message will be displayed even if there are alerts with a different status (I see now that that's not what we want):

no_active_alerts.mov

I got your point about showing the same widget with the alert count but we can't control the styles (as we just use the alerts widget here) so it will look like this:

alerts_widget.mov

[jennypavlova]

Update: I checked and I can also get the recovered alerts count so we can have the total first similar to the alerts widget:

• Closed

  

• Open

  

What I don't like about this is that we are basically creating the same component as the provided alerts summary widget (if we add the closed content above with some styling)

[roshan-elastic]

Hey @jennypavlova,

Yes, I looked at this again and I changed the naming a bit to make it easier to navigate (and to avoid the double "section" like in infraAssetDetailsAlertsSectionExpandSection) but that's the idea. So we will have:
data-section-state=open or data-section-state=closed
and section id will be: data-test-subj="infraAssetDetailsMetricsCollapsibleSection", data-test-subj="infraAssetDetailsMetadataCollapsibleSection", etc

Could we decouple the section from the action of clicking on the collapse/expand and just have the data-section-id=SECTION specified in the parent element?

I'm pretty sure that the telemetry will automatically inherit the data-section-id from the parent element if it's specified there.

For example, here is a sample event where you can see that properties.target contains everything from the element back to the DOM:

Could the data-test-subj just be infraAssetDetailsCollapseExpandSection and then if I wanted to break that down by which section and whether it was an expand/collapse I would just break down by data-section-id and/or data-section-state?

[roshan-elastic]

Alerts:
So what I used to check the alerts is the active alerts count only, I probably misunderstood the idea here at the beginning. I was thinking that we want to highlight the active alerts only in the closed section.

@jennypavlova - You know what, that's probably a better idea. So in summary, we could do something like:

• Collapse alert section by default if no active alerts are found:

• If active alerts are found, expand the alert section and show the alert counts/table expanded?

I like this because you would see no 'red' unless there are active alerts (and in that case, it'll be expanded so you can see the problems at a glance).

That would limit customisation to a minimum? I think it's a good assumption you have that users don't care about alerts if they're not active (at least not enough for to push them in the UI).

Is this more what you had in mind?

[crespocarlos]

@jennypavlova do you think it would be possible for the component above, could send via onLoaded event the count information so that we can decide when to expand or collapse the section? If we could avoid an extra API call for that, it would be great.

[jennypavlova]

do you think it would be possible for the component above, could send via onLoaded event the count information so that we can decide when to expand or collapse the section? If we could avoid an extra API call for that, it would be great.

@crespocarlos I am trying to understand the suggestion here. So I am dropping the alerts count in the closed state if there are active alerts, keeping only the content when there are no active alerts and set open/closed state only after we load the widget, is that the idea?
So what I tried is: inside the MemoAlertSummaryWidget I can get the alerts count using the hook and there I can pass from the parent a setter for the variable deciding if we should keep the section open and close by default and in the use the setter as part of the onLoaded of the AlertSummaryWidget (I don't see any way to get the count from the widget directly - onLoaded accepts a function and don't give us any alert information). So then I am checking for the open/close changes inside the section component so basically the section will load and after it is already loaded we will leave it open or close it based on the result because we want to show only the closed section text in case of the closed on default section (is this correct?):

alerts_only_no_alerts_collapsed_1080.mov

With this change we are still doing the http request I don't see an option to skip it 🤔 The benefit is maybe that we set the 'open'/'closed' state open by default and change it to closed after we load the section.

I am thinking now that we can only try to get alerts count with the hook inside the parent and if there are no alerts at all to not render the alerts widget and to close the section (so we will do the request to get the count only and we won't render theAlertSummaryWidget if the total count is zero), also we can show the active alerts count that way in the closed section as I did before, wdyt?

Edit: Added a commit to show the change so we can discuss further [WIP version until we decide is we want to keep it]

[crespocarlos]

Hey @jennypavlova

onLoaded of the AlertSummaryWidget (I don't see any way to get the count from the widget directly - onLoaded accepts a function and don't give us any alert information)

My first idea was to see if the onLoaded event could return the counters object. With that, we wouldn't need to use the useAlertsCount. At the moment, the widget doesn't support that, so I was wondering if this would be a good idea. Without deep knowledge about the widget, I don't see any reason for it not to make the counter info available via the onLoaded event.

So then I am checking for the open/close changes inside the section component so basically the section will load and after it is already loaded we will leave it open or close it based on the result because we want to show only the closed section text in case of the closed on default section (is this correct?)

Yeah, this sounds correct :)

I am thinking now that we can only try to get alerts count with the hook inside the parent and if there are no alerts at all to not render the alerts widget and to close the section (so we will do the request to get the count only and we won't render theAlertSummaryWidget if the total count is zero), also we can show the active alerts count that way in the closed section as I did before, wdyt?

We would still make a second request when opening the section. I'd expect to be able to make a single request if the alerts widget returned the counter. The same flow that you've already put together in your draft PR would remain the same.

What I'm thinking that we might be able to do, provided that the onLoaded event can return the counters is:

1 - Open the flyout
2 - The alert widget starts to load - the alerts section is open at this point.
3 - When the widget finishes loading, we will have a callback for the onLoaded that will control the open/closed state based on the counter.
4 - Collapse or keep the section expanded

Wdyt?

[jennypavlova]

My first idea was to see if the onLoaded event could return the counters object. With that, we wouldn't need to use the useAlertsCount. At the moment, the widget doesn't support that, so I was wondering if this would be a good idea. Without deep knowledge about the widget, I don't see any reason for it not to make the counter info available via the onLoaded event.

That would help a lot but I don't think we can do that - maybe we can check with the team who owns the widget and see if we can have something like that (maybe a separate prop because I saw that onLoaded is used in some places to execute different action after the component is loaded so I guess this one should remain a void function to avoid breaking the existing functionality).

We would still make a second request when opening the section. I'd expect to be able to make a single request if the alerts widget returned the counter. The same flow that you've already put together in your draft PR would remain the same.

That's true, we need the request now because we don't have the count returned from the widget - I also checked if there is a function providing the count inside TriggersAndActionsUIPublicPluginStart but I couldn't find anything we can use.

@crespocarlos I am not sure if I should split this actually and keep a PR for the basic section implementation and investigate this alerts widget further: so we won't have the text when the section is closed and the section will be open by default so we can avoid having the second request in the first PR and I can add a followup issue for this as it's not something we can do directly on our own. Wdyt?

[jennypavlova]

@roshan-elastic I can change it from a section specific like this:

to this (same id for all sections):

I wasn't sure if that is useful but as you said you can have the id of the section and the state together with the generic data-test-subj and combine them to get the results

Edit: Updated the telemetry section in the issue description as well

[crespocarlos]

so we won't have the text when the section is closed and the section will be open by default so we can avoid having the second request in the first PR and I can add a followup issue for this as it's not something we can do directly on our own. Wdyt?

Sounds good @jennypavlova! We could also timebox this investigation so we don't spend too much time on it.

[roshan-elastic]

I wasn't sure if that is useful but as you said you can have the id of the section and the state together with the generic data-test-subj and combine them to get the results

Hey @jennypavlova,

This looks perfect:

data-test-subj=infraAssetDetailsCollapseExpandSection gives us all interactions with it
data-section-state tells us if someone expanded or collapsed
data-section-id allows us to break down which section it was
data-asset-type allow us to compare different asset types
data-component-type allows us to compare the fly-out vs detail page

This is really nice!

[jennypavlova]

Sounds good @jennypavlova! We could also timebox this investigation so we don't spend too much time on it.

@crespocarlos Good idea: I added an issue (#175989) and a ❓ next to the timebox, feel free to update the description if you have some ideas (also for a reasonable timebox for the investigation)