Repository navigation
Think through the Elements tab #5312
Description
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.
Activity
clarkus commentedon Aug 5, 2021
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 commentedon Aug 6, 2021
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 commentedon Aug 6, 2021
I'll see if I can fit in a secondary description of some kind.
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 commentedon Aug 8, 2021
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 commentedon Aug 10, 2021
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 commentedon Nov 30, 2021
Based on the work on #5962, I think the scope of this issue can be reduced to 2 options. Thoughts @clarkus @mariusandra ?
Or not sure if the work you'll be doing on #5962 will solve this issue too.
clarkus commentedon Nov 30, 2021
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 commentedon Nov 30, 2021
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 commentedon Nov 30, 2021
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 commentedon Dec 1, 2021
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.