Make saved reports a top-level feature

[macobo]

Is your feature request related to a problem?

Reports are useful for saving ad-hoc analysis. I want to:

• Save/share reports which are individually useful
• Add same report to multiple dashboards

We have a concept of saved reports already. You can access them by:

1. Going to insights
2. Clicking history
3. (Optional) Giving a unnamed insight a name
4. Clicking on "saved" tab

Describe the solution you'd like

Make reports a more top-level thing with:

1. Default tab to "saved" insights, history being a different tab
2. Provide tooling to manage reports - e.g. filtering by name, creator, when created, starring, etc.
3. Allow adding reports directly from dashboards - e.g. by having a (+) button which when opened allows to filter saved reports.
4. Add a way to open recent reports of same type to insights. Move all "saved funnels" to reports.

How filtering is handled by Heap

Describe alternatives you've considered

Only using dashboards - makes it harder to reuse reports in dashboards, bad for discovery.

How mixp@nel does it:

At top of insights there are New, Save, Save as new buttons.

Clicking open opens a modal for filtering these reports:

Additional context

There's a downside to this: we'd be cluttering our side nav even more with "related" functionality.

cc @paolodamico @EDsCODE

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

[paolodamico]

Here's an initial stab at introducing saved insights as main functionality.

1. Saved insights
Main way to access saved insights would be from the home page (if we keep it; alternatively this would just be a top-level menu item, in which case we would probably bundle other saved stuff).

2. Quick access
Same as we have on dashboards, we allow users to quickly navigate between saved insights.

3. Insight history
This would keep only the most recent analyses for easy recovery. We would default to filtering by analyses that each user ran themselves as it will probably be the most recurring use case.

[paolodamico]

Some mockups for the missing save insights experience.

Saving an existing insight

1. We ask for confirmation because just clicking save would completely override previous configurations with no easy undo.

Saving new insight

Saved insight

[clarkus]

I think this makes a lot of sense. There is a related case where work gets interrupted - sometimes you just need to put work down and come back to it later. The ability to save via a dedicated workflow would inspire some trust of the feature and add value to insights outside of dashboards.

[clarkus]

Transitioning here from #4979

I've put together updated listing screens for insights. This includes some basic filtering and a new primary action for triggering the insight creation workflow.

Part of making this workflow feel more fluid / simple will be setting smart defaults for all required fields. In the scenario below, the insight has a meaningful, identifiable name that can be searched for later. This makes our save action immediate. Given this, we might consider a toast-style notification that informs a user of non-critical events like "insight saved successfully". When the user opts to save and add to a dashboard, we show the existing modular workflow for adding an insight to a dashboard.

One outstanding thing to resolve is making starting the insight creation workflow a prominent and discoverable action. We want to make this list available for finding existing stuff, but we need to solve for that immediate "I need to explore my data now" task. This could be a big prominent action in the global navigation. Thoughts?

[liyiy]

I thought the all tab here

would render us this current view below that options bar, but is it all insights saved instead?

I thought having an extra options bar on top was a great way of adding saved insights discoverability without removing current visibility of our easy to access graphs. Is that new insight button meant to remove our current all graph types display and direct us to each one individually instead or is it just additional functionality?

[clarkus]

would render us this current view below that options bar, but is it all insights saved instead?

Yeah the intent is that this page primarily lists all saved insights into the categories all / yours / favorites / updated recently. Secondarily there will be a listing of insight history. This should be a distinct list.

Is that new insight button meant to remove our current all graph types display and direct us to each one individually instead or is it just additional functionality?

This would be a way to trigger insight creation. Right now when we go to insights, we're always in a mode where we're defining or creating something regardless of whether that work is saved. This change would create a distinct view for lists of insights with controls for making things easier to find. The existing insight view would be unchanged with the exception of funnels which has a "funnels saved to project" list. That would be deprecated and replaced by the insight list view.

[liyiy]

In terms of first insight creation workflow, I do like having all the insights always in a mode of creation/display 🤔 It makes it feel more intuitive to create something since it's all laid out visually for the user already. Adding a dropdown button in order to reach that page feels like we're adding another step to the process and obscuring a key discoverability moment? (when users just see all the charts and go at it, even if they don't quite know what they're looking at just yet).

Some of this saved insights stuff might be a good fit for the home page too, where we're already displaying some things like it?

But, curious to see what others think 😄

[clarkus]

@liyiy the idea is that you can click the button to trigger the creation flow as it is today, or you could click into the menu to jump to a specific insight type that you want to build. I'm not 100% happy with it either, so I'm chasing that as part of this goal:

One outstanding thing to resolve is making starting the insight creation workflow a prominent and discoverable action. We want to make this list available for finding existing stuff, but we need to solve for that immediate "I need to explore my data now" task. This could be a big prominent action in the global navigation. Thoughts?

Appreciate your feedback!

[clarkus]

I spent more time on the listing view. I introduce the concept of types into filtering. This is communicated via iconography now. Note that I'm trying some different icons here that aren't final. Let me know if you have thoughts on those.

We have enough inline actions here to justify an overflow menu. Here I've added an "add to dashboard" action that would trigger adding this insight to a dashboard. Next I am going to work on bulk actions that would allow you to remove multiple saved insights or add multiple insights to a single dashboard. There might be a tag editing case in there as well, but I'm still not sure tags make sense at the insight level or not.

[clarkus]

One other note while I'm thinking about it... our nomenclature for insights is a bit all over the place as it relates to dashboards. In various places insights are referred to as "graphs", "insights", or the insight type "funnel" for example. We're also using the word "reports" while discussing internally. So my question is what do we want to call insights? :) /cc @macobo @paolodamico

[timgl]

I was trying to go into this direction with the history tab so definitely in favour of this. I am quite fond of the way I brought in the actual graphs as a way of super quickly identifying Insights, as 99% of them will be unsaved and thus have no description attached to them.

[clarkus]

@timgl I think that makes sense when you're trying to identify previous work that isn't identifiable via other attributes. I could see using that in a card layout for the insight list in the proposed changes above. When other attributes are available (name, desc, tags, author, etc) I think the table could offer some value. It really depends on context and how the user is identifying the insight.

One thing that is tripping me up is our different models between dashboards and insights. I think the core difference is the immediacy in which I am in that creation flow for insights. I click on insights and I see the creation / query view. I click on dashboards and I see a list of dashboards. The changes above propose we align insights with dashboards (I click insights and I see my list of insights).

We can still ensure quick and immediate access to creating an insight, but it would be triggered via something other than the insights item in the menu. Maybe there is a big prominent "new insight" button for the quick exploration case?

Let me know if this doesn't make sense... it feels really subtle and nuanced.

[marcushyett-ph]

I like this approach a lot - I actually wonder if it makes sense for this to replace or be part of "home" as I imagine its the first place most people will want to go? cc: @kpthatsme

As @timgl says the graphs are really helpful to understand quite a lot about the insight without digging - I think it'd be okay to show them on hover or something.

With the new insights dropdown for some reason it feels quite hard to differentiate between them with only the name - e.g. Whats the difference between a trend and perhaps, how retention is trending over time? Maybe its just a naming thing - but this potential confusion seems more pronounced in this experience.

[paolodamico]

• Agreed, I think a save as option could be helpful. We could have an extra context menu like we just introduced for auto-refresh.
• Re undo. I feel like this is the kind of problem we'll never hear about because it's not a bug, and it's unlikely to come up in a usability test (because you're not dealing with real data). I'm all for testing this but if we're doing that, we should provide a quick and easy way for users to provide feedback if something went wrong (e.g. after saving the toast can say something like click here if you made a mistake).
• Re hotkeys. Agreed in the overall principle of relying as much as possible in standard browser navigation (in fact I don't think we're overwriting anything other than the cmd + K of the command palette if you use Firefox). My pushback would be that we make sure everything is easily accessible with the keyboard, it makes things significantly easier. It can really be a pleasure to use an app that's properly wired.

[clarkus]

Agreed, I think a save as option could be helpful. We could have an extra context menu like we just introduced for auto-refresh.

Here's a quick idea that rolls the "save as new insight" and "save and add to dashboard" actions into a submenu under the save action. I'm a bit concerned about discoverability for adding to dashboards, but at the same time I don't want a menu of a single option here. Thoughts? Are there any other related actions we might consider exposing while editing insights?

[paolodamico]

I think this works because even if you click Save only, you'll be able to add to dashboards from the modal, right?

[clarkus]

The modal would only fire when adding to a dashboard. Otherwise saves are immediate. This is based on having a default value for the insight name... in most cases I was just using "my insight " + a unique ID. That would give you something uniquely identifiable (as long as unique names are enforced or we have some other unique ID exposed). Descriptions and tags are optional, so as long as we have that name value saves should be immediate.

A general workflow could look like this:

• New insight
• Populate insight details (name, query, vis type, etc).
• Click "save" and you're taken to the read only view for the insight
• Click "save and add to dashboard" and you're shown the "add to dashboard" modal
• Click "save as a new insight" and you're prompted to provide a unique name. This might not be necessary as on save we could just generate a new ID and take you to the newly created insight in the read only view

Throughout saves you'd see toast notifications reinforcing the successful save or creation of new insights. Thoughts?

[paolodamico]

Oh okay! Cool indeed, makes saving even more seamless. I think what we could do then is: a) if it's the first time saving this insight, we have both buttons (as save as doesn't make too much sense in this context), b) if it's NOT the first time, we do the single button with the dropdown. Adding to dashboard discoverability is less important in this case. Wdyt?

[clarkus]

That sounds like a good approach to me.

[clarkus]

I reorganized and posted the latest designs to the PostHog App project in figma - https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=3116%3A34102

[clarkus]

Quick update to clarify the editing state for meta details like descriptions, tags, and names. https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=3245%3A33481

Previously the user would need to toggle the editing state for names and descriptions regardless of the insight page mode. If you're editing the insight, these fields should just be directly editable and saved along with the rest of the insight definition.

[kpthatsme]

I really like what you have here @clarkus – I think it would add a ton of value to activation, it's basically a much better version of project home.

@paolodamico how far out do you think this is for you all to work on? (Just the saved insights page)

[paolodamico]

@alexkim205 is actually getting this over the line during the next sprint. @alexkim205 would we be able to include the explore tab here too?

[kpthatsme]

Oh that's super exciting– I think this will really help with activation.

[alexkim205]

Actually I think @liyiy actually merged in her saved insights work today. It should be behind a FF for @PostHog people and it's really cool. I'm picking up remaining work for saved insights though so feel free to play around with it and assign me to any bugs you might find

[Twixes]

I think we can consider this done, saved insights having been released now.

[posthog-contributions-bot]

This issue has 4509 words at 40 comments. Issues this long are hard to read or contribute to, and tend to take very long to reach a conclusion. Instead, why not:

1. Write some code and submit a pull request! Code wins arguments
2. Have a sync meeting to reach a conclusion
3. Create a Request for Comments and submit a PR with it to the meta repo or product internal repo

Is this issue intended to be sprawling? Consider adding label epic or sprint to indicate this.