Kibana: [APM] Design improvements for UI Filters

[sqren]

UI Filters are currently based on EUISelectable. There are a couple of drawbacks with it and we might either take ownership of it and fix those, use another component (EUI Combobox?) or build something from scratch. The things we have talked about are:

• show the top 5 terms directly in the sidebar
• Get rid of the pop-over and show the suggestion input directly in the sidebar (only if there are more than 5 terms)
• Remove animation when selecting an item (only relevant if the EUI popover is kept)

[elasticmachine]

Pinging @elastic/apm-ui

[dgieselaar]

My preference would be: show the top 3/5 terms as buttons below the filter title, if there are more than that, add a button (9+ more options) that opens the popover.

[sqren]

@dgieselaar Good idea. Would make it much simpler to filter by transaction result that most only has a couple of options (2xx, 3xx, 4xx, 5xx).

[formgeist]

@katrin-freihofner Unless you have already started on this, I can jump on this. Just wanted to make sure that the description contains all the feedback/changes that we wanted to make for upcoming release before I start making the design changes. @sqren @dgieselaar Should we have a talk soon just to get aligned?

[sqren]

@sqren @dgieselaar Should we have a talk soon just to get aligned?

Yeah, that might be a good idea. With the first iteration we constrained ourselves to what was possible with the existing EUI components. For the second iterations I'd like to see what we can come up with without this constraint.

[formgeist]

I've invited the usual suspects to a call tomorrow about this. I agree that we need to take a look at what can be achieved without the specific components restraints, but perhaps also some assumptions were made about the filters and their cardinality that might be looked at differently now. Let's talk it out 😄

[formgeist]

Notes from our Zoom meeting;

• We agreed that we should pursue a design that involves removing the popover for each filter option selection and instead show the filter options inside the panel.
• Also agreed to remove the option to filter via input. Currently this option filters the values already rendered in the options, doesn't do a backend search, which the user could use the query bar instead. We opted to show 5 upfront with an option to show i.e. 20 more in the panel. By default 5 is typically enough to select the most common values especially for status codes.
• We will attempt to remove the apply button and instead let the selection update the data accordingly. It's important to note that selecting a value in a filter doesn't filter its own values by selection.
• We will explore how we might elevate the transaction type selector to its own component instead of it being a filter per se. It feels like more like a large dataset switch than a simple value-based filter.
• Convert the EuiSelectable component to a simple EuiForm checkbox component instead.

[sqren]

Closed https://github.com/elastic/kibana/issues/45501 since this will make it obsolete.

[formgeist]

Updated design proposal

I've put together new screens that will show off the redesigned filter UI. In this design I've made the following changes and additions;

• Changed from the EuiPopover to using the EuiForm checkbox for the immediate selection of filter values per filter.
• Option to "show more" which adds another 10 values to the values list (if available).
• Option to expand/collapse the filters
• It's proposed that i.e. the host filter is expanded, while container ID and pods are collapsed. This is a simple measure to save height on the panel itself.
• The transaction type is switched from a select input to be a section as a link in the left sidebar. It's only shown when there's more than 1 transaction type. Additionally, the reason why we'd move away from the select input is that it feels like a larger dataset switch since the types most likely are very separate from each other. We've previously rendered the types as their own overview pages in a previous design.

@elastic/apm-ui @elastic/observability-design @roncohen @nehaduggal Thoughts on the design updates?

[dgieselaar]

Looks great! I like the proposal for transaction type as well. Couple of questions:

• Do you mean that there can only be one filter open at any time, like a harmonica? Or are they collapsed by default?
• When a filter is collapsed, do we (should we) show the selected/available options in the title? It might be nice for the user to not have to expand the filter to see what options are selected and/or available.
• Do we need some kind of explainer that the user should fall back to the Query bar if they are looking for an option that is not listed (e.g. #21)?

[formgeist]

Do you mean that there can only be one filter open at any time, like a harmonica? Or are they collapsed by default?

No, they can all be open at the same time, but we default to collapse i.e. select filters like container ID and pods. It's not critical to its implementation, but a nice-to-have.

When a filter is collapsed, do we (should we) show the selected/available options in the title? It might be nice for the user to not have to expand the filter to see what options are selected and/or available.

Agreed, we can add a selected values indicator in the title. Something like;

Do we need some kind of explainer that the user should fall back to the Query bar if they are looking for an option that is not listed

I can look at adding some info text at the bottom of the panel when expanded with 15 values. Is that what you mean?

[sqren]

This looks great! Good job 👍
From an implementation perspective I think I'd make sense to separate the transaction type changes from the ui filter changes.

[formgeist]

From an implementation perspective I think I'd make sense to separate the transaction type changes from the ui filter changes.

Makes sense - if we agree on its design, I can create a separate ticket for it.

[katrin-freihofner]

@formgeist great work! 🤩

[roncohen]

hey! Sorry to drop in. I understand the facet count shows number of transactions. I think it could be confusing. To know that, users must intuitively know that the data shown in the rest of the view is based on transactions - and i don't think they are conscious about that. Something else: have you considered lots of people might have millions of transactions there? what does the UI look like when the count is huge?

[sqren]

I understand the facet count shows number of transactions. I think it could be confusing. To know that, users must intuitively know that the data shown in the rest of the view is based on transactions - and i don't think they are conscious about that

For pages with lists it is not the number of transactions but the number of "results". So on the service overview page the count shows the number of services, on the transactions overview page the count denotes the number of transaction groups. Error overview page: number of error groups.

It is only on the details pages that we end up counting documents. So on transaction details page it'll be number of transactions and error details page it'll be number of errors. For those pages we could hide the count, since that is not that useful. But I think we should keep it for the "list pages".

Btw. this seems like a separate discussion since none of this is being changed here (this is a purely design change) so perhaps we can discuss it in a separate issue?

[sqren]

@formgeist should we get started with this for 7.6? From your comments in above the design looks fairly finished, and implementation-wise the effort-to-impact ratio should be pretty good.

[formgeist]

@sqren I think we wanted to wait a couple of cycles to see how the current design would get adopted and get some customer feedback on it first. Mostly to see if there was any other feedback or suggestions we'd consider implementing around the same time. cc @nehaduggal

[sqren]

Ah okay, I thought we agreed to push it to 7.6 but I'm probably misremembering.

[formgeist]

I don't think that was a wrong assumption, but I don't think we've focused on getting the feedback we wanted yet. Perhaps @nehaduggal can weigh in on the priorities. I would like to note that I believe the design updates we'd be making would vastly improve the UX of the feature.

[sqren]

I would like to note that I believe the design updates we'd be making would vastly improve the UX of the feature

Totally agree! Which is why I'm eager to get started. I agree it's better to get feedback on the current design if possible though.

[formgeist]

We've decided to convert the proposed design solution into an implementation issue so it's ready to get picked up when we've received from customer feedback and are ready to start on it.

[formgeist]

@roncohen As we're moving this design into implementation, I just wanted to follow up on your comment and perhaps get your thoughts on @sqren's reply ^ https://github.com/elastic/kibana/issues/45503#issuecomment-534490123

Do you think we should drop the counts and facets entirely in the upcoming redesign?

Thanks

[formgeist]

Opened an implementation issue for the design enhancements showcased above https://github.com/elastic/kibana/issues/49153

[roncohen]

hey! We don't have to drop those now. Let's keep discussing separately as @sqren suggested. Thanks for asking 👍

[formgeist]

Closed in favor of https://github.com/elastic/kibana/issues/49153