Discussion: Proposed changes to the insight building workflow

[clarkus]

Is your feature request related to a problem?

In most of the current insight building workflows, visualizations are pushed further down the page by query building and other filtering options. While scrolling is a natural action, there are good reasons to give the visualization more prominence in the page. In some scenarios, filters can become sufficiently complex to completely displace the visualization down the page. The work happening in #3408 will give insights more value outside of the context of a dashboard. Being able to collapse or hide the query building portion of the interface will give the visualization more prominence and reinforce the read-only case for insights.

This is a huge assumption, but I feel like seeing data load is the major point of value with insight building. Anything we do to decrease the amount of time or effort to see data could potentially make that feature feel more valuable to users. A more prominent placement of the visualization also serve the read-only case described above.

Describe the solution you'd like

What if we could show query building and visualizations at the same hierarchy? What if we could hide the building components for read-only cases? What if we could make data load in as soon as the query builder reports that there is a valid, well-formed definition that can be used to render a chart.

This is early, but here are some rough concepts for a modular query builder that could collapse in order to show the visualization on its own.

Describe alternatives you've considered

What we have now works. I've considered updating this pattern to give visualizations and the builder equal space, but it still feels like we're prioritizing building over reading or consuming. Dashboards serve a lot of the consuming case, but if we build stand-alone insights, we could still do more to better serve the read-only case.

Additional context

There's a bunch of related work in:

• Replace "save funnel" with "save funnel to dashboard" #4979
• EPIC: Filters UX 2.0 #2760

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

[paolodamico]

Sorry for the delayed feedback here. Love this, think tit makes a ton of sense to try out. A while ago I had a similar thought particularly for when you share insights. My rationale was that when I share an insight the data is the central piece I care about. As the recipient I may want to sometimes look at how an insight is built to understand the data better, but even then this is for a secondary purpose.

• One thing I think would be critical is that you can access the configuration drawer quite fast and easily (definitely a hotkey), but even nailing down the right animation as to not make it painful like we had before the taxonomic filter.
• I think we could also add the option of snapping the configurator to the page. One particular use case that comes to mind is when you’re exploring insights. You typically don’t just build one query and that’s it, each answer leads to more questions and being able to answer them easily is critical.
• I’m a bit wary about the “other options”, where are we keeping there? Discoverability would be severely limited so it’s important that these are indeed advanced non-frequent use features.

[clarkus]

Thanks for the feedback, @paolodamico. You're right on. This is targeted at making that query builder or configurator less critical to the page layout. Most of the layout would be focused on making the insight visualization clear, well-described, etc. Secondary to that, when building an insight, having the visualization placed prominently could make the experience feel faster or at least more responsive.

One thing I think would be critical is that you can access the configuration drawer quite fast and easily (definitely a hotkey), but even nailing down the right animation as to not make it painful like we had before the taxonomic filter.
I think we could also add the option of snapping the configurator to the page. One particular use case that comes to mind is when you’re exploring insights. You typically don’t just build one query and that’s it, each answer leads to more questions and being able to answer them easily is critical.

Agreed - I was working through some options for how to trigger this view, but then found I needed to better understand the scale of building queries and filters (#2760).

I’m a bit wary about the “other options”, where are we keeping there? Discoverability would be severely limited so it’s important that these are indeed advanced non-frequent use features.

Good catch. I had this in there previously but I don't think it's needed any longer. I'll remove it!

[corywatilo]

Feedback

First, this is gorgeous. Second, it inherently solves a bunch of near-edge use cases.

It shows what happens if your screen is too narrow to display both the workspace builder and the results
If you’re on a giant screen, the column can naturally fit within the page.
It’s naturally responsive, so if/when we get to supporting queries on mobile, this lends itself toward working natively. (This isn’t a focus, but if we can kill two birds with one stone, awesome!)
If we ever decide to offer a read-only mode (or presentation mode) which hides the workspace, it won’t feel like anything is missing from the resulting view.

It also feels more app-like, which is a direction we’ve talked about going. (Being able to take up your entire browser real estate means a more native-like experience, which our users will appreciate.)

Next steps

What are some tangible next steps? Should we throw these mocks in front of some customers to gauge their feedback, or do we feel confident enough that this is a solid direction that we just start building toward this?

[clarkus]

I think tying this into the rest of the IA is important. There are some competing changes at #3408 (comment). It's really going to be tied to our mental model for creating and managing insights. Once we have some direction on that, I think we can make the editing / creation states more obvious and distinguished from read-only states.

[paolodamico]

Haven't seen the latest changes of #3408 (will take a look after this), but standalone this design does makes sense to me. There are two more things I think it's important to put forward: I would expect this column/drawer to be fully visible (and not actually a drawer) whenever a) I'm in a wide screen (maybe 15" or more) or b) when I'm in a smaller device (e.g. a 13" laptop) but building an insight. If I'm on my laptop, and I need to pop that up every time I need to tweak something, it can become super annoying. Wdyt?

[clarkus]

I think it just needs to be obvious how you access the panel. I agree with you that by default we should show it and make it obviously findable, but on smaller viewports, I do see the need for making the layout of that component more adjustable. Sometimes I might just want to collapse it so I can get a full viewport view of the insight I'm building.

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[posthog-bot]

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.