Think through the Elements tab

[mariusandra]

Is your feature request related to a problem?

The new filter has a tab called "elements":

As the 4th tab it makes the tabs themselves scroll a bit. If we add an "All" tab the problem will be compounded.

Describe the solution you'd like

• Smaller tabs?
• Rethink if we need this tab? Map out all uses of the property filter and see if it makes sense. E.g. maybe we don't want it in the global filters. I removed it from breakdown for example (as it wasn't working there).

Describe alternatives you've considered

Leave as is.

Additional context

Woop woop.

Thank you for your feature request – we love each and every one!

[clarkus]

I have been working on this a bit. It's going to depend on the character length of the counts for each tab. We might also abbreviate or drop repeated words like "properties". Thoughts?

[paolodamico]

I know this complicates things but one piece of feedback I have is that "Elements" is actually a bit confusing. I don't understand from it that it entails properties related to frontend HTML elements based on autocapture. Can we maybe add a description explaining this even if it doesn't provide great discoverability?

Radical thought, why don't we get rid of this tab (and the ability to directly filter on those properties altogether). These props are actually better used through an action. It's more intuitive and the traditional path. I'm not even sure we have a lot of usage from filtering directly on these props directly.

[clarkus]

I'll see if I can fit in a secondary description of some kind.

Radical thought, why don't we get rid of this tab (and the ability to directly filter on those properties altogether). These props are actually better used through an action. It's more intuitive and the traditional path. I'm not even sure we have a lot of usage from filtering directly on these props directly.

I'd be up for this if we can estimate the impact it'd have on usage. I just don't want to leave users with broken insights.

[paolodamico]

I'd be up for this if we can estimate the impact it'd have on usage. I just don't want to leave users with broken insights.

Great point on this! We're actually not capturing this yet, but opening a PR to track this better and after a week or so of data we can make an informed decision here.

[clarkus]

Here's a quick iteration to show how we might adjust the sizing of the modular picker component. This is set a max of 320px in the second example. When all the options available in the tab list are wider than the available space, a directional chevron is displayed. Acting on this would page the tabs forward to reveal the remaining portion of the set. Not ideal, but it would adjust to various contexts while still being usable. Also shown here is the addition of the word "autocapture" to the "elements" tab. Elements aren't as meaningful or approachable for some users, so tying it back to the means of creation helps clarify what exactly is in this tab.

[paolodamico]

Based on the work on #5962, I think the scope of this issue can be reduced to 2 options. Thoughts @clarkus @mariusandra ?

1. Rename the tab to "Autocapture elements" and keep it.
2. Remove the tab altogether and just keep this stuff under event properties.

Or not sure if the work you'll be doing on #5962 will solve this issue too.

[clarkus]

Did we ever quantify usage on the elements tab in this context? If it's not adding value, I'm fine removing it. If it's being used, I'd be more in favor of the updated tab name.

[mariusandra]

If we make this component capable of handling multiple groups (we kind of have to...), then I'm in favour of keeping this as a separate tab. Renaming it to "autocapture elements" is also an improvement.

[clarkus]

There is a concept at #5962 (comment) that contains a solution for autocapture elements. The flattened list has plenty of room for more verbose labels and counts. Thoughts?

[paolodamico]

Alright so for now we'll just rename the tab (PR already out) and we can continue the conversation around the flattened list in the #5962 issue.