EPIC: Filters UX 2.0

[paolodamico]

From our own dogfooding and feedback from users we've now identified that the filters experience needs some love. The experience is not very fluid, and can even be confusing at times. Creating this issue to group all related issues, centralize feedback and serve as a basis for planning/discussion of a new filtering experience.

One key thing that we've discussed about this is that we need to think of a standardized component/experience that we can reuse across the app (i.e. for insights, sessions, persons, events, ...)

Additional context

• Issues opened before (superseded by this issue), Confusing UX: Removing event/action from trends #2586, UX for creating filters on Insights is unintuitive #2631.
• User feedback: Dec 3.

[paolodamico]

From another customer call,

I really did not see and wouldn’t have unless you told me about the weekly selector at the top.

referring to this:

Period filtering in retention was a ton more logical than above the graph (as in insights). The mental model of the RHS panel is that this stuff that changes the data should go in there.

[paolodamico]

Another user reporting it was unintuitive where to find the cumulative graph. Some confusion with "Sum" property aggregator too.

[macobo]

Potentially relevant tickets are tagged https://github.com/PostHog/posthog/issues?q=is%3Aissue+is%3Aopen+label%3Aanalytics-filters - though there are others that don't have the label

[paolodamico]

#4050 has reworked other filtering touchpoints (e.g. interval, timeframe, ...), so keeping this issue now only to discuss refactoring the main filtering experience.

This is what we're doing currently in sessions for reference, while I think it's a better experience, unsure if it's the right approach for insights too. Regardless, we should keep a uniform experience everywhere.

[paolodamico]

From #4535 by @corywatilo,

Action-level filtering

Currently to filter an action, there's a button below the dropdown.

Problem

There is some confusion between user-level filtering and action-level filtering.

Typical filtering in an analytics UI filters the users like, "limit to users who did X".

User-level filtering is super powerful, but placing both on the same UI can be confusing to newcomers.

I'd like to propose we move the action-level filters into a place where you can find it if you're looking for it, but won't confuse you if you're not looking for it.

Solutions

A Loom explaining 3 options

Link to wireframes

[paolodamico]

From #4535 by @mariusandra

• Cory, please replace "action" with "event" above 😄. Actions don't have properties (events do), etc :).
• Option 3 is my clear favourite, as it makes the interface most accessible and easiest to use.
• We had a popup with tabs like "option 2" before, but then nobody clicked the tabs (action / event).

---

What I like about the current filter is that (once you press "add filters" and then press "add filter" 😅 -- can we remove two steps?) you can just start searching for a property and you'll find it, no matter if it's a event property, person property or even cohort.

This does bring drawbacks. For example, as a new user, what the hell am I supposed to choose?

Had I used trends, I would have gotten a slightly worse experience:

[paolodamico]

From #4535 by @clarkus

I put together some conceptual changes to the picker based on the work happening in #4267 (comment). I think we could maintain the ability to quickly filter down the full list, while still exposing category groups that allow for scoped keyword searches. Note that this work was done for picking actions and events, but could easily apply to other structured sets like user and events properties.

I also noticed that we're using some inconsistent labeling across query building in our insights features. Generally the actions users can take are hiding / showing filters, adding a filter, updating a filter, removing a filter, etc. I think we could clarify these actions across insight tabs, and trigger the option selection flow immediately instead of forcing a user to click that option after they click "add filter".

[paolodamico]

Re @corywatilo

1. Personally I would go with option 2 to activate the filters for the first time, in line with what we current do on trends and to avoid more confusion with global filters. Though, definitely worth opening the filter dropdown with a single click when you tap on the add filter button. I also think it's pretty powerful to hide the filters if you don't want the distraction.
   1.1 One related thing to consider is if it's worth having the filters shown by default when you open the graph (or maybe we can keep the state of whether they're open or not). Sometimes I've found it a nuisance that the filters are compacted when opening a link.
2. Either option we go with, I agree with @mariusandra, the "Property" / "Cohorts" tab things is confusing and it also doesn't feel smooth, I would keep the current version, save for @clarkus's proposal.

Re @clarkus
Love the proposal for the new filter box! Still keeps the benefit of allowing you to quickly search among all the options, but now filtering is a lot easier, and particularly adds discoverability to other secondary filter types (like cohorts) that may have not been in your radar.

3. I have some minor thoughts on the box, will add my comments in the related issue, but I would in general move forward with this.

[mariusandra]

Love the mockup from @clarkus . Some UX thoughts:

1. What would be open first? All? Event properties? Person properties?
2. What happens if you are in "event properties" and search for something that gives 0 event and person properties, but 1 cohort. Would the active tab switch?
3. Missing from the mockups is event and property taxonomy. Basically this means some place to show a title + description for whichever property, as seen on the screencasts I posted above.
4. How do you easily switch between the tabs if you're a heavy keyboard user? "tab" to change tabs? Sounds about right 🤔
5. To aid discovery, what about an option where before anything has been searched, we show a (closable?) line inside the box, something like "Search for events that had a specific property set on ingestion. Browse properties set on all events below." vs "Search for events for users that have a specific property set. Browse the most popular user properties below.". I'm ~~bad~slow in copywriting, but the point is to have a bit of visible help that clearly explains what's the difference between an "event property" and a "person property" the first time you are given this choice.

[clarkus]

1. What would be open first? All? Event properties? Person properties?

This can depend on context, but by default we'd show the all tab. This would maintain the current powerful keyboard navigation and not produce any breaking changes for users.

2. What happens if you are in "event properties" and search for something that gives 0 event and person properties, but 1 cohort. Would the active tab switch?

Tab switching without a clear reason could be really confusing. Ideally we'd show an empty state for the event properties when there aren't any matching results. The user would then elect to navigate to that other tab via a click or some other keyboard event.

3. Missing from the mockups is event and property taxonomy. Basically this means some place to show a title + description for whichever property, as seen on the screencasts I posted above.

I think we could retain the existing summary card shown on hover. I'll include this in the designs and produce something a bit more well rounded.

4. How do you easily switch between the tabs if you're a heavy keyboard user? "tab" to change tabs? Sounds about right Tabs are difficult because 

I need to do some research on this topic. I would avoid tabonly because of natural tab index ordering in the document. I think we could possibly rely on arrow keys, but I need to educate myself a bit more on this topic. I'm adding it as a todo and will post something more complete later today.

5. To aid discovery, what about an option where before anything has been searched, we show a (closable?) line inside the box, something like "Search for events that had a specific property set on ingestion. Browse properties set on all events below." vs "Search for events for users that have a specific property set. Browse the most popular user properties below.". I'm ~~bad~slow in copywriting, but the point is to have a bit of visible help that clearly explains what's the difference between an "event property" and a "person property" the first time you are given this choice.

Great idea. I'll add this.

[clarkus]

@mariusandra I did some reading on best practices for keyboard navigation at https://xd.adobe.com/ideas/principles/web-design/best-practices-for-prototyping-keyboard-accessibility/ and https://inclusive-components.design/tabbed-interfaces/. I think we should stick with the default tabindex when using tab keys to navigate. This would mean traversing a tab and its list of options before moving over to the next tab group. Arrow keys could be used to jump ahead in the tab index when a tab already has keyboard focus. For example, you have the all tab focused and you can arrow key left or right to move through the list of tabs sequentially.

[clarkus]

I took @corywatilo's wireframe to a higher fidelity version aligned with the other recent filtering work. Given this format, I'd want to rework my previous filtering concepts to fit within a popover / overlay context. Doing that next.

[paolodamico]

Not sure if this element should be in this issue, but love this, definitely a significant improvement! Keen on building this

[clarkus]

Just mentioning #5189 as it implements some changes proposed here. There is a lingering issue to handle multiple-selection scenarios in filters. For example, you're filtering based on a browser property and want to use a contains operator to capture the supported browsers for your product. You can see the current behavior in this capture from #5189.

Notable issues:

• In filters, we autofocus the value field when the property field value is changed. This bypasses the operator field entirely. Might not be a problem, but it could be cumbersome for users who change that operator field often.
• Value fields seem to get confused easily (see above gif). I think this could be clarified with some guidelines and an updated multiple selection component that affords type-ahead searching as well as manually scrolling through a finite list of options.

[clarkus]

Below are my notes on how this feature is currently working and how it could generally be structured for an improvement. We've recently improved the experience for finding properties, so the remaining work is mostly focused on operators and selecting values. If any of the notes below are inaccurate or could be improved, please let me know. I'll be using this as the basic test case for designing an update.

Notes
The value selection portion of the filtering workflow can be optimized based on the data type of the property used in the filter. We generally support operators for string, numeric, boolean, date, list / array, cohort / membership in our filters. This is a co-mingled set now, which is fine, but we can adjust the selection experience a bit based on data types. For example, we can hide operators that aren't applicable to the current property.

These might be a valid cases, but as a less-technical user, I wasn't sure how these filters would evaluate or if they were even valid.

Here's my working list of types and their supported operators. Some properties can be evaluated via multiple data types or operator sets. These operators also imply a single or multiple select scenario for the value field.

• String
  • Equals (multiple val)
  • Does not equal (multiple val)
  • Contains (single val)
  • Does not contain (single val)
  • Is set
  • Is not set
  • Matches regex (regex)
  • Does not match regex (regex)
• Numeric
  • Equals (multiple val)
  • Does not equal (multiple val)
  • Between ([lowerbound] and [upperbound])
  • Not Between ([lowerbound] and [upperbound])
  • Minimum (single val)
  • Maximum (single val)
  • Greater than (single val)
  • Less than (single val)
• Boolean
  • Is set
  • Is not set
• Date
  • We don't really offer any specialized date operators right now and our date formats vary across properties
    • In the last ([N] [time units])
    • Before the last ([N] [time units])
    • between dates (start date and end date)
    • not between (start date and end date)
    • on date (date)
    • not on date (date)
    • since (date)
    • before (date)
• List or Array
  • Contains (single val)
  • Does not contain (single val)
• Cohort or Membership
  • Is a member of
  • Is not a member of

[paolodamico]

Some pretty solid stuff here, love these new visuals! Some feedback,

• Would be helpful to visualize the components in the actual view to get a sense for the whole visuals.
• Think having icons makes sense, particularly because after you select an option we collapse the whole thing to just the icon. It’d be strange for the option to become an icon you don’t see before.
• I would make the visuals for the glyph/letter similar to what we have right now, they intuitively call attention to themselves and the colors make it obvious what’s going on.
• Another important thing to consider in this EPIC is what happens with filters outside insights, e.g. what we use in feature flags, cohorts, … one particular pet peeve of mine is you have to click “Add filter” in places where it’s unintuitive because we use want to fully reuse the same components.
• Feedback from a focus customer: being able to copy/paste values would be incredibly helpful (particularly long URLs are hard to visualize in the constrained boxes). Think we can improve the interaction with values in these boxes.

Re data types:

• For boolean we have one more value because undefined is different from set explicitly to false. Also “is set” might be confusing as to whether this means is true or simply set.
• For array, it’s unclear whether contains means that it contains an exact element or contains a partial match to an element.

[clarkus]

Would be helpful to visualize the components in the actual view to get a sense for the whole visuals.

Absolutely. I'm going to do that once I feel like I have the structure of the workflow figured out. Most of the constraint is knowing the full range of options that the component has to support. Secondary to that, identifying gaps that we can improve on - date operators for example.

Think having icons makes sense, particularly because after you select an option we collapse the whole thing to just the icon. It’d be strange for the option to become an icon you don’t see before.

Yes agree, but some operators don't have simple icons we can use. I also feel like that while these mathematical symbols are technically accurate, they're not immediately meaningful for a portion of users. The more I work on this the more I feel like showing the full operator text is the better experience. Speaking of icons I am also chipping away at #4266 which is not represented here.

Another important thing to consider in this EPIC is what happens with filters outside insights, e.g. what we use in feature flags, cohorts, … one particular pet peeve of mine is you have to click “Add filter” in places where it’s unintuitive because we use want to fully reuse the same components.

Totally agree - I am working on these with the goal of having them work in any context. I am still working through these ideas, but just wanted to show that I am testing against a variety of scenarios. Here cohorts are shown.

Feedback from a focus customer: being able to copy/paste values would be incredibly helpful (particularly long URLs are hard to visualize in the constrained boxes). Think we can improve the interaction with values in these boxes.

Excellent feedback. I'll add this to my list of things to address.

For boolean we have one more value because undefined is different from set explicitly to false. Also “is set” might be confusing as to whether this means is true or simply set.
For array, it’s unclear whether contains means that it contains an exact element or contains a partial match to an element.

👍 will make this clearer in the mockups.

[paolodamico]

I think we can close this with the new taxonomic filter, wdyt @clarkus ?

[clarkus]

Sure thing. I have some other changes in the works that I will file separately once they're ready for work.