Toolbar experience for non-toolbar users

[paolodamico]

Is your feature request related to a problem?

There are some cases where users are unable to use the toolbar. The most common one is if you don't have the snippet/JS library (or any front-end events at all). If this is the case, it's a bit distracting/annoying and even concerning to see the floating toolbar prompt come up.

Describe the solution you'd like

If there are no frontend events which the toolbar can use, do not show the floating thing. We can still keep the menu item as a CTA to take actions for the toolbar to work.

Related to the above, we should show a CTA with clear instructions on how to address enabling the toolbar (i.e. likely adding the snippet or JS library to the frontend, or enabling $autocapture if disabled).

Additional context

Related to customer call

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

[macobo]

Idea: on clicking x for the toolbar, prompt to dismiss it 'forever' (for this user), then say "you can always re-enable it from settings". :) And add a toggle under settings.

[posthog-bot]

This issue hasn't seen activity in 6 months. Is it still relevant?

[clarkus]

Related #4268 - There is a toggle for disabling the toolbar here. Would that qualify as a solution here or is the core problem exposing this setting in the context of the toolbar?

[paolodamico]

User reported wanting to disable the toolbar for themselves but not for the entire project which wouldn't be covered by this.

[clarkus]

User reported wanting to disable the toolbar for themselves but not for the entire project which wouldn't be covered by this.

So given that, there should be two settings. One to enable the toolbar for the project, but secondarily to enable it for a specific user account?

[paolodamico]

So I’m actually not sure that’s the best thing to do, just wanted to put all the context I had forward. Perhaps one option is to have a single project setting but we let you permanently dismiss the toolbar when you click the close button. If you permanently dismissed the toolbar, we give you an option to re-enable it in settings.

[macobo]

Idea: "x" on the hedgehog on site. If clicked, asks if to permanently disable, but says you can always re-enable by launching it via app.posthog.com.

[paolodamico]

Yup 100%, exactly what I meant. Though if you permanently dismiss it I think it should only apply for your user not your project right ?

[clarkus]

Yeah my comment was more about the places where a user can change this in settings. It'd be totally fine to changes those settings or to prompt to change them when interacting with the toolbar. I was mostly thinking about the other case where the toolbar is enabled for the project, but disabled for a user, and a user needed to know how to re-enable the toolbar. A single setting at the project level wouldn't be sufficient for that.

[paolodamico]

Well that ends up being connected to what we do with the settings page but indeed we need a separate user-level setting for that. One UX thing that I think makes sense is only showing that extra config if you have permanently disabled the toolbar (i.e. you can only disable by clicking the close button)

[clarkus]

Here's an illustration of a possible solution. In this case, on dismiss we prompt the user to disable the toolbar for their User Account. Thoughts?

[paolodamico]

Yes, pretty close though I think we need to have 3 buttons: "Cancel", "Dismiss forever" and "Close for this session" (primary) [exact copy to be adjusted]. It might also be worth to have a "Don't ask me again" checkbox for option 3 (primary).

[clarkus]

Is the task dismissing the toolbar or disabling it? To me, dismiss means stop showing this, but disable means never show it again (unless I turn it back on in settings). The close action on the toolbar is the "dismiss" portion, and the follow up prompt is the "for how long" portion of the interaction.

👍 on the "don't ask me again" checkbox.

[paolodamico]

Yes agreed! Disabling is "permanent", dismissing is temporary (i.e. this session), but you trigger either by clicking on the same close icon button, that's why I was suggesting the 3 buttons. The thing is that once you have the dialog, clicking on cancel to only dismiss temporarily seems confusing, as cancel could simply entail go back and don't actually close the toolbar.

[clarkus]

Good catch. We're not letting them cancel out of the dismissal, we're just confirming it. What do you think of these changes?

[paolodamico]

Love it! One final suggestion if I may. Feels like the primary action should be just dismiss on this session rather than fully disable (is at least something we'd like to encourage I think). Wdyt?

[clarkus]

Sure!

Available in figma at https://www.figma.com/file/9yWtngNb1AIuf6KmXaEPJA/App-doodles?node-id=900%3A140805

[clarkus]

Related #2370

[corywatilo]

My thoughts on disabling vs dismissing:

I don't know if we need to disable it, to the extent you have to go back into Settings to re-enable. What seems like a simpler UX is, once you click X to dismiss it, it just doesn't re-appear until you go to the Toolbar and re-launch it on the domain where it was previously dismissed. Then it would stick around until you X it out again.

[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.

[pauldambra]

once you click X to dismiss it, it just doesn't re-appear until you go to the Toolbar and re-launch it on the domain where it was previously dismissed.

that's how it works now