UI improvements for running queries, doing deep dives

[corywatilo]

In light of posthog/meta#66 and how queries become more detached from how they're visualized, I've been working through some UI ideas to support it.

The below are a few initial steps to move us closer toward the internally-floated concept of a more powerful PostHog UI.

One of the big themes in the data exploration RFC is that a user can change the visualization ad-hoc (without rewriting the entire query). In this conceptual UI (below), there's a pinned sidebar where event/actions can be added, along with filters and breakdowns – independent of the visualization. (Theoretically, this could also be used to show session recordings that match, not just limited to traditional analytics views like trends, funnels, etc.)

Next steps

To work our way closer to this reality in the current UI, here are some possible next steps:

1. Move query builder to left column, make it sticky (so it never goes away) within insights

Below is a funnel view, with certain elements moved/removed to make it so we can have a consistent query pane between all visualization views, with viz-specific elements moved to the viz pane. (In this case, I'm proposing we remove numbers from funnel steps, and removing language specific to funnels. Then we move any funnel-specific parameters to the top of the viz pane, since they're only needed here.) The only items in the side pane are items that would show in all visualization views.

2. Add recordings as a tab within insights (and UI to view list of recordings that match, with player)

Note: This would require session recordings to use the same queries as insights

This will allow a user to add a set of filters, or actions seen in sessions, to be displayed as a list of recordings.

3. When doing a "deep dive" (persons modal, user path links, etc), open content in sidebar

Rather than displaying details in a modal, it would be more useful to display this information in a pane. In the future (exploratory UI), it could look something like this. (This pane would open when you click a subset of users from the funnel view.)

Until we get to a major UI iteration, simply moving this content out of a modal and into a sidebar could be a good way to ease our way into a UI change.

4. Tabs

To become a super powerful dev tool, instead of just loading details in a side pane, we could introduce tabs. This doesn't need to only be for deep dives, but for also running other queries without losing your place - and without requiring opening new browser tabs. (This is slightly alluded to in the above wire, though with actual tab support, deep dives would likely open in new tabs.)

5. Reduce nav prominence

Once we have more content spreading across the screen, we'll likely need to save some horizontal nav space.

Now, I'm not the greatest proponent of label-less stacked nav, but there are some ways we can make this less obnoxious (like showing the nav labels on hover).

6. Taxonomy 3000

Update: This is now a separate issue.

This is a little further out, but a quicker way to use the taxonomy dialog seems super useful - especially to be able to support mostly keyboard navigation and reducing a ton of clicks. Here's a 3-pane filter pane that's contextual based on the filter selected in the first column. Each column has search, so you could type, then tab, type, then tab, then enter your value – all without having to touch your mouse.

This feels like a project that's independent of the above steps, but a great addition to some UX improvements around running queries.

[mariusandra]

We're going to have a session next week at the offsite (Thursday?), where we'll break down the work on this for the next months.

[corywatilo]

A more holistic overview explaining this subset of changes is now in #12923