"Apps" Next Steps (Marketing + Product)

[marcushyett-ph]

Conclusions from discussion around "Apps":

1. Focus on rebrand of plugins to apps and aligning with messaging
2. Completing the work to update "Integrations" to "Apps pages" @joethreepwood
3. Rebrand in the app Plugins to Apps (sidebar and inside of the plugins page) @lottiecoxon @mariusandra
4. Make it possible to build a basic front-end configurable App which appears in the sidebar @mariusandra
5. Link from product to "Apps pages" @lottiecoxon @mariusandra (taking you to "collections" on the site)
6. Marketing launch plan TBD (probably not a huge amount of noise) cc: @joethreepwood @andyvan-ph @charlescook-ph

[andyvan-ph]

I'll cancel the parade :(

[timgl]

Genuine question, is the biggest value we'll get out of this just the website/marketing side? Maybe we should try positioning posthog as an app platform first before we actually move everything around?

[clarkus]

Make it possible to build a basic front-end configurable App which appears in the sidebar @mariusandra

How far are we going with this change? Is it mostly just a concept or prototype to test the idea, or are we trying to build something that we're going to release to users?

[joethreepwood]

Genuine question, is the biggest value we'll get out of this just the website/marketing side? Maybe we should try positioning posthog as an app platform first before we actually move everything around?

On the marketing side we aren't planning to make much noise about the initial plugin/apps switch, as it's essentially a rebrand only.

The biggest value I see in the short term is actually in improving the documentation and visibility of plugins/apps - hence the initial hackathon idea of nailing plugin docs, because they're currently not very good. This approach works for that goal whether they're called Apps or Plugins.

There is a potential long-term benefit in term of becoming an app platform, but agree there are unanswered questions there.

[mariusandra]

I think we should just go forward, and rename plugins to apps without much fanfare. Despite what we might think, the users won't really care whether we call them one or another, but if the direction we're moving towards is this:

... then calling them "plugins" won't do them much justice.

Let's fix the old term that's getting in the way, and then have big parade if and when we actually release useful apps on the platform.

[clarkus]

I'm good with a renaming effort for now. We should take special consideration for the ongoing onboarding project - we're using the term plugins there, so we should ensure all that content is updated to align. I'll take care of that today.

Edit: I forgot I already updated all the content to reference apps. ✅

[joethreepwood]

There definitely won't be much fanfare.

I want to be clear that renaming should still involve merging PostHog/posthog.com#3253 so that we have better visibility and documentation for plugins/apps.

I'm at the very end of finishing content for this PR. All that remains are providing product content for the last few (currently unlisted) apps Emanuele has made, then removing references to the integration library and redirecting that to the apps store. I'm unsure on if @corywatilo is planning further design/site work there, however.

[joethreepwood]

Can I clarify, as there seems to be some misunderstanding, whether the existing product features (Funnels, Trends) will also become Apps? And whether that will happen in line with the rebrand of Plugins to Apps, or be something we shift to later?

My understanding is that all that is happening initially is Plugins to Apps and that features will stay as features. In the future, Apps may grow. I think that's the right call.

If we're changing Funnels, Trends, etc., to Apps now too then that is a fundamental change in product positioning and messaging. We should think very carefully about the benefits/risks of doing that so quickly and we'd need to do more on the marketing side to make sure users understand why that switch has happened.

Tagging @corywatilo as this question arose from discussion with him

[corywatilo]

✔️ Built-in apps
✔️ Apps you can install from the app store

Let's go all the way. Feels weirder to have some things that are apps and some features that aren't.

It will be more clear once #3267 is done.

[clarkus]

Let's go all the way. Feels weirder to have some things that are apps and some features that aren't.

I personally would feel more confident if we took this slower and focused on rebranding plugins for now. I just don't understand what we gain from calling a feature a built-in app or if the effort is worth it right now. Have we tested the idea with users? Do we have any data or feedback on this yet?

I'm not against the idea, I just can't see the strategy behind this or the problems we're addressing with a broader renaming effort. This could have a real impact on ongoing work, so I'm cautious to jump in without more information to validate the changes. Happy to talk through it more, but I can't really get behind the broader renaming changes without more information.

[mariusandra]

I don't think we should get ahead of ourselves. In fact, I think it's the clearest for everyone if we only call "apps" the things you can build using the app platform.

In this vision, what we call "insights", "feature flags", "session recordings", and so on are core platform features, which "apps" can use as building blocks. (you have access to the feature flags API ---> but apps can't create APIs right now)

[joethreepwood]

+1 to Marius and Clark's point. I also think we'd risk complicating the commercial and practical perception for the product. We want PostHog to feel simple to deploy with a straight forward value prop. Apps on apps could complicate that by making it feel like more work is needed and bolt-ons are required. Limiting the first step to plugins feels like a good way to test the messaging.

…

On Wed, 11 May 2022, 21:39 Marius Andra, ***@***.***> wrote: I don't think we should get ahead of ourselves. In fact, I think it's the clearest for everyone if we only call "apps" the things you can build using the app platform. In this vision, what we call "insights", "feature flags", "session recordings", and so on are core platform features, which "apps" can use as building blocks. (you have access to the feature flags API ---> but apps can't create APIs right now) — Reply to this email directly, view it on GitHub <#9654 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUA6UKIAQIHJ3L3FUQD3DHLVJQLG3ANCNFSM5VE4Y5ZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[marcushyett-ph]

• 1 to @mariusandra @clarkus @joethreepwood. Not much extra to add. Other than to say getting the rebrand out and the new SEO optimized docs for our existing plugins as quickly as possible will be really valuable, lets see the impact and get some customer feedback on this before taking a bigger leap into repackaging all of our core features as apps.

@simfish85 and I are going to be setting up a bunch of regular customer calls and we should be able to get some feedback on this topic (and others) to help us make some informed decisions.

[joethreepwood]

Seems like we're aligned. I'll make some changes to the Apps PR and document this there so we're moving in the same direction. 👍

[mariusandra]

I made a PR to rename Plugins to Apps on the app. I'm not sure where some of the links on the page should lead though.

This PR can basically be merged whenever all the rest goes live.

[joethreepwood]

This PR can basically be merged whenever all the rest goes live.

I'm going to be done with content - updating plugin to apps in the docs, giving each app new docs and product pages, etc - by the end of this week. All that work is on PostHog/posthog.com#3253.

@smallbrownbike and @corywatilo have indicated there is some more design work to be done on that PR. The other thing we'd want to coordinate with is accepting Emanuele's new apps into the product, as I've given the following a presence on /apps in the PR.

• Amazon Kinesis
• Braze
• Twilio
• Intercom
• Databricks

[marcushyett-ph]

Just in the process of getting all the repos transferred - for these should be done by the end of the week. I'm not sure about Braze though if we've not been able to test it? Shall we put it up with a beta / warning label on it?

[joethreepwood]

Just in the process of getting all the repos transferred - for these should be done by the end of the week. I'm not sure about Braze though if we've not been able to test it? Shall we put it up with a beta / warning label on it?

If it's completely untested then it may be best just to remove it and avoid unforeseen unconsequences? Happy either way, as it's easy to remove from /apps.

[marcushyett-ph]

I think we leave it in and call it beta - if we get feedback from someone we can use that to help fix and test it further.

FYI, the repos are all transferred now: PostHog/integrations-repository#7

[mariusandra]

As of today we have basic frontend apps live on cloud. Only behind a feature flag and for just our team of course. Nobody else can edit apps on cloud anyway.

Go and check out the one running app (in the sidebar), make a new one, or add some useful links to the the existing one if you're brave enough.

On cloud, it may not auto-reload (there's a silent timeout), and you may need to hit reload manually. Locally all changes were live within seconds.

Here's a sample app to start from:

import React from "react"

export const scene = {
    title: "My Stuff",
    component: function MyStuff({ config }) {
        return (
            <div>
                <h1>My Favourite Links</h1>
                <ul>
                    <li>
                        <a href="https://news.ycombinator.com">The NEWS</a>
                    </li>
                </ul>
                <h1>My Favourite Cow</h1>
                <img src="https://media.giphy.com/media/RYKFEEjtYpxL2/giphy.gif" />
            </div>
        )
    },
}

The structure of frontend.tsx, what you can import and use, how to structure the exports, etc... all of this is very very early and will still change based on feedback.

Currently apps can import { whatever } from either react, kea or @posthog/apps-common.

These are the things you can import from @posthog/apps-common

export * from 'lib/components/LemonBubble/LemonBubble'
export * from 'lib/components/LemonButton/LemonButton'
export * from 'lib/components/LemonCheckbox/LemonCheckbox'
export * from 'lib/components/LemonDivider/LemonDivider'
export * from 'lib/components/LemonInput/LemonInput'
export * from 'lib/components/LemonModal/LemonModal'
export * from 'lib/components/LemonRow/LemonRow'
export * from 'lib/components/LemonSelect'
export * from 'lib/components/LemonSwitch/LemonSwitch'
export * from 'lib/components/LemonTable/LemonTable'
export * from 'lib/components/LemonTag/LemonTag'
export * from 'lib/components/LemonTextArea/LemonTextArea'
export * from 'lib/components/lemonToast'

export * from 'lib/components/AdHocInsight/AdHocInsight'

import api_ from 'lib/api'
export const api = api_

For example:

import { lemonToast, LemonButton, api } from '@posthog/apps-common'

As props, the Component gets the plugin's config. There is no setConfig, and no other way to set persistence, unless you abuse e.g. the annotations API or something like that.

...

Going forward, I suggest we move as slowly as possible, letting the previous work settle before adding new stuff. Whatever we build, we might need to support forever or risk annoying users, so let's not start expansion we're not ready for.

To take the next steps, we need to make sure we have a good story regarding building, running, transpiling and reloading apps. We should test and seriously dogfood the system ourselves, building anything and everything we think of ("does it run doom?"). Only then, when the developer ergonomics are good enough, should we think about adding next features, like persistence, etc.

We're still some points short of the masterplan, but let's go slow and steady. I'm curious to see what you all will build with the current featureset!

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