Replace "save funnel" with "save funnel to dashboard"

[macobo]

Is your feature request related to a problem?

Currently, it's possible to "save" funnels in a way that's incompatible with the rest of trends.

Describe the solution you'd like

It should be possible to add funnels to dashboards.

Describe alternatives you've considered

Additional context

User was confused in papercups: https://posthogusers.slack.com/archives/G01JXEDAL22/p1625235789002100

cc @paolodamico

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

[paolodamico]

Updating here. Problem we had with funnels is that the Add to dashboard button was accidentally dropped. #4986 fixes this. This fixes the problem in the short-term.

The real problem we still have is that we have a confusing and inconsistent (different for funnels than other insights) experience when saving insights. Think it's worth putting more effort to figure out the right UX, and have the same UX across all insights. Keeping this issue to work on it.

@clarkus I'm not sure if the latest version we're considering is the best way to go yet. Some concerns that come up:

1. Add to dashboard is not very discoverable and causes some confusion for existing users too.
2. How do we handle saving already saved insights (i.e. updating)
3. Adding to dashboard might seem a bit non-intuitive even after opening the modal.

[clarkus]

I was also confused about this 😅 . I think the core way funnels diverge from other insights is this concept of saving them to the project while not saving them to a dashboard. If we drop the ability to save a funnel to the project, does this list go away? If this is the case, that's probably a breaking change that should be communicated to users. Otherwise there won't be a way back to an existing funnel if it isn't already on a dashboard.

I am trying to better understand our model. If this is changed for funnels, my understanding is that the existence of an insight on a dashboard is the only way to save state. There is no concept of saving an insight outside of its placement on a dashboard. Is this accurate?

[macobo]

There is no concept of saving an insight outside of its placement on a dashboard. Is this accurate?

There kind of is a third system. If you go Insights > History, you can save "reports" that way. However that's a third system on top of dashboards + funnels and one that I don't think is widely used.

See also: #3408

If this is the case, that's probably a breaking change that should be communicated to users.

Conservative proposal: Put the feature behind a feature flag, enable the flag for everyone who has been using it so far and see if it gets any usage after that. If it does, then talk to them and see whether there's a valid usecase.

Eager proposal: Just nuke it and see if someone complains.

[clarkus]

Given we still have the history component, I'd be more in favor of the nuke option. That would clarify the "save to dashboard" label and be much more straightforward. That said, we should align this across all insights if possible. We have the same model for each, so aligning the button labels would be a good change to reinforce the model.

[paolodamico]

We definitely have a bit of a messy experience here.

Here's what I was thinking (mockups for this are on Figma). Feedback? @clarkus

1. The history "tab" (with visual changes) would be kept but only to show previously run queries that aren't saved. From there the user could pop open a historic insight or save it. We would only keep too maybe like ~2 weeks of history? More than that seems unneeded. Goal of this would be if you want to go back to something you ran but forgot to save or want to check again, almost like an undo version control.
2. You save insights as standalone reports. Saved insights can then be accessed either by a dropdown on the titles like we do on dashboards (see mockups) or via a new separate "saved" page (which I haven't given much thought to yet). You can then always update the saved insight or "Save as" to create a copy.
3. For adding to dashboards, you can either add saved insights, or save an insight directly. Insights saved directly wouldn't show the same as saved insights (perhaps not shown or perhaps shown differently). I think one critical improvement here is being able to add insights more easily from a dashboard, particularly for saved insights this would be quite easy.

Things outstanding:

4. We need to make the save experience when you're working on an existing insight more seamless. Ideally we wouldn't show a "Save modal" to confirm save or save as, but we might need to then have some sort of undo in case you made a mistake.
5. Should we create an additional "saved" page? Perhaps this can be the home page for existing users.
6. Do we keep "Add to dashboard" and save separate or together? I'm thinking separate might make the most sense, but we need to fit them correctly in the UI.

Thoughts @clarkus ? Think it's worth spending time building full mockups for this, happy to do them or if you prefer to.

[clarkus]

@paolodamico I have some ideas for this and I am happy to spend some time on it today. I think the most obvious and valuable model is going to be saving insights as standalone objects. This gives the user a means of starting and stopping work on an insight as needed. Saved insights / reports could also be a centralized place to manage and update insights used on one or more dashboards.

[clarkus]

Here's a quick stab at stand-alone insights based on the existing components for managing dashboards. Note that I am redoing some templates to make them a bit more composable... if you see repeated data, ignore it for now and know that I am cleaning this up as I work on the core problem. This is the first step in establishing a clearer model for managing insights. My next steps are to clarify the saving workflow across types of insights to make it more consistent.

Notable changes to the workflow:

• You are no longer immediately in a creation workflow when you click on insights. It's a pretty powerful experience to be able to immediately jump into build a visualization. If we go this route, we might consider a prominent action on every page that lets you quickly start exploring data via insights.
• I set up some tabs to make it easier to jump to categories of insights. Note that insight history is exposed here directly. This would be a distinct set of items, so it's placed opposite the rest of the tabs. It feels a bit orphaned right now, so I am working on changes to make this more obvious
• I wasn't quite sure how pinning worked, so I changed it to favorites and set a tab just for those items. The thinking is that favorites are just a reserved form of tag that we can use to group insights.
• I added some affordance for bulk actions. This would allow a user to clean up old insights, tag in bulk, etc.
• There is some rudimentary pagination in the footer of the table

More in progress work at https://www.figma.com/file/9yWtngNb1AIuf6KmXaEPJA/App-doodles?node-id=587%3A0

[clarkus]

@macobo @paolodamico I spent a bit more time on this. I'm not quite happy with the workflow, but this would at least get us to a point where we can save insights independent of dashboards.

My problem with the workflow is that building an insight doubles as an exploratory flow. You don't always start out with the intention of saving your work - you very well may cancel out once you've answered your questions. I don't want to diminish the ease of getting into that exploratory workflow. For this reason, I've broken away from the model we use to create and save dashboards. In the dashboard case, you create the object, then populate it. In the insight case, you populate and preview the object, and then optionally save and / or add it to a dashboard.

You can see that I have two main actions on the create insight view - Save and Save and add to dashboard. The idea here is that the Save is a quick action that just saves state and gives your insight a position in the list of insights with whatever name you provided. Save and add to dashboard prompts with a modular workflow that prompts for extra details. It makes sense that in the dashboard case you would want to provide a meaningful name, description, tags, etc to make your work approachable and identifiable.

I am also slowly trying to consolidate and improve consistency across the insight creation views. If you see any major layout changes here, just know that they're an in-progress thing mean to fill the gap while this model is figured out.

Thoughts?

[corywatilo]

Lots of good stuff here!

We’re conflating a few things here (which are all semi-related), so I’ll try to break down my thoughts by topic.

Saved queries, queries on dashboard, and recent queries
100% would be great to have consistency between all analysis views. Even if we’re changing the UI between analysis views (stacked, side-by-side), all the functionality should be consistent. (I was also thrown by this when I first dove in!)

Defaulting to Your Insights
We have a couple different use cases here:

Analysts/users who are running a bunch of ad-hoc queries
People who are invited to PostHog to see reports, but aren’t likely to dig too much into the data

@kpthatsme may have some thoughts here, but if we want to optimize for customers exploring data, we may want to make the query stage a little more visible. (I wonder if there’s a way to combine an empty query stage and some number of saved reports?)

BUT, this is UI seems great for read-only analysts. “Want to run your own query? Great! There’s a button for that.” (But New insight might not be the most obvious way to label it - as a user invited to view reports, I’m not sure what that button means at this point.)

UI
Loving the cleaned up UI which brings together all the elements of the query stage (Steps, Insight options), but my biggest concern is if it pushes the results too far down the page. (We also seem to be missing a “Run query” button?)

Even if we were to implement smooth scroll that moves you down to results after you run the query, I wonder if we can tighten things up a bit so they aren’t so far below the viewport?

P.S. I’m loving the shading between the steps and the filtering - makes it super clear what you can drag up/down!

[clarkus]

Loving the cleaned up UI which brings together all the elements of the query stage (Steps, Insight options), but my biggest concern is if it pushes the results too far down the page. (We also seem to be missing a “Run query” button?)

Yeah I think this is the case for all insights, but it's especially problematic for funnels given the unbounded nature of steps. The more steps you have the more you displace the visualization. I agree with your feedback. I am still working to try to tighten it up while still making it feel obvious.

[paolodamico]

Ignoring layout changes for now, but the overall UI improvements here are amazing!

• Echo @corywatilo's suggestion on exploring a way to have the insight builder screen right away while having a way to explore saved insights. Perhaps even splitting them into separate menu sections? Discovering insights fresh is at least as powerful as discovering saved insights (at least for now).
• Having separate save + dashboard & plain save buttons seems quite intuitive, though then I'm not clear what happens when you click each. The save insight modal seems to handle both cases into one.
• Related to the above, I'm still not convinced about this save modal, very subjective, but still feels quite clunky, not like something I would find in an Apple product.
• We're also missing how would the experience be for updating an already saved insight? Two particular considerations: a) updating a saved insight could be considered "destructive" in the sense that undoing that change could be painful, b) how about a "Save as" option too.
• Not sure if we should support tagging at the individual dashboard item level, seems like it might just add confusion to general dashboard tags. On the other hand, having tags for saved insights (not on dashboards) could be useful. Thoughts?
• Think the insight history might be worth having only on the insight editor page? Let it serve sort of as an undo.
• Think we need to add a search and more explicit filtering to the insights table (i.e. something like we do in sessions page as opposed to the in table filtering we have in other places).
• For the created by, we could use the Avatar component we use in other places. I'm also not sure what would happen if you click on that person link?
• Love the idea of having a separate tab for favorite/pinned stuff. Genuinely not sure if favorite is better than pinned, but whatever we choose let's use the same for dashboards too.

[clarkus]

Echo @corywatilo's suggestion on exploring a way to have the insight builder screen right away while having a way to explore saved insights. Perhaps even splitting them into separate menu sections? Discovering insights fresh is at least as powerful as discovering saved insights (at least for now).

@paolodamico @corywatilo this is really the core of my issues with the design I shared above. I want it to be straightforward to trigger this exploratory flow but also want to give standalone insights a bit more value by making them more discoverable. The data exploration use case seems like something that should be available on every page of the product. Anytime you want to validate an idea or explore some data, you click on a prominent "new report" or "new insight" action and you're immediately in that view. What would be super cool is if it were modular so that you could trigger that view without leaving your current context.

Example - I am looking at a person session, I see some common attributes that give me a general idea I want to test. I trigger this building view and it overlays the current screen. Given this is targeted towards an exploration case, it's optimized towards seeing data and results as soon as possible. Once I test my idea, I can save that work for later, or just close it with a prominent action and I'm right back into my person session. You could also do this via a new tab, but there's some power to having this on-demand building experience without hijacking the user's browser tabs 😉 .

Having separate save + dashboard & plain save buttons seems quite intuitive, though then I'm not clear what happens when you click each. The save insight modal seems to handle both cases into one.

I am working on this today actually. I don't like it either. I want to be able to prompt for those other insight details or at least provide some smart defaults so that it's less critical to provide that information when you're first saving. The general ideas was to chain the workflows, but I'm not sure they need to be separate.

We're also missing how would the experience be for updating an already saved insight? Two particular considerations: a) updating a saved insight could be considered "destructive" in the sense that undoing that change could be painful, b) how about a "Save as" option too.

I could see "save as" working. You could argue that providing a duplication option could offer the same functionality just from a different starting point. Maybe we should provide both.

Not sure if we should support tagging at the individual dashboard item level, seems like it might just add confusion to general dashboard tags. On the other hand, having tags for saved insights (not on dashboards) could be useful. Thoughts?

Dashboards could just aggregate the tags from the insights they contain.

Think we need to add a search and more explicit filtering to the insights table (i.e. something like we do in sessions page as opposed to the in table filtering we have in other places).

I'll work on this today as well. Totally with you on making things easier to find.

Love the idea of having a separate tab for favorite/pinned stuff. Genuinely not sure if favorite is better than pinned, but whatever we choose let's use the same for dashboards too.

Yeah I think pinning impacts the list of items in the overflow menu under dashboards. The same could apply to insights, but I'm not sure it's super obvious. I'd question if we need the overflow menus if we provide this structured listing of all items. We also have a pretty capable search that can directly open objects... we could do more to make that the centerpiece for power users quickly jumping to a known context. Tagging items as favorites feels more approachable to me simply because it's more prevalent in other products.

[paolodamico]

Makes sense! I like the idea of performing quick insights like you do for email composing in Gmail, sounds like it's worth testing.

Aligned on the rest! Let me know if you need any help.

[clarkus]

This update is focused on the insight creation view, less so on how you get to it. This is intended to front-load the insight details (name, description, tags) in the header of the page with reasonable defaults. For example, we have a placeholder name and the description (if unmodified by the user) would automatically update to match the funnel step progression. A user can click to rename / edit the name or description. Tags can be added, as well. This would give us a one-click save action with no prompts. If the user elected to save and add to the dashboard, they only get a prompt to select a dashboard.

There are a ton of other changes in here that I am working on in related issues. The goals I'm chasing for this iteration are:

• Simplifying building insights across types
• Trying to make query composition as succinct and quick as possible so that the visualization is discoverable
• Front-loading insight details to simplify the saving workflow
• Making left-to-right funnels a bit more scalable

Thoughts?

I haven't put much time into the overlay idea yet, but it would likely follow this same format. There's a chance I can get the query building to work in a 320px column, in which case we could show the visualization area more prominently. I'm working on that next.

[clarkus]

After working through this a bit more, I think the base improvement to be made is collecting the insights details prior to saving. If we don't have to enforce unique insight names, we can provide a reasonable default that makes saving a one-click, immediate action. If the user opts to add to the dashboard, the save action happens first followed by a prompt to add to a specific dashboard. If we do need to enforce unique names, we might consider introducing a simple numerical ID into the insight name. This would be enough to make it identifiable and findable again.

One thing I'm not clear on is the relationship between insights and panel names on dashboards. Can panel and insight names diverge? Are they always the same? Is there any other insight attribute used to ensure uniqueness when added to a panel on a dashboard?

I am going to save the rest of this solution for the larger issue at #3408.

[paolodamico]

I think we're duplicating a lot of information from #3408 in this issue, and ultimately the solution we come up for #3408 will be reusable across all insights and solve this issue, so I propose we close this issue and continue the conversation in there to avoid confusion.