Merge settings pages?

[paolodamico]

Is your feature request related to a problem?

Currently we have three settings pages: project, organization, personal (me). It's not always obvious where to go to accomplish something. Further, we've gotten feedback that the "Project" tab isn't even understood as settings.

Describe the solution you'd like

I'd like us to consider the possibility of merging all these setting pages into a centralized page where you can easily search for a setting across all three scopes.

One particular challenge of this is the hierarchy of content as currently the left navigation pertains to items related to the current project, while the top bar has precedence (affecting scopes above a single project).

Describe alternatives you've considered

See above.

Additional context

Also reported by our own dogfooding.

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

[clarkus]

I would like to make some time for this in the next sprint. I think the problem might be broader than just settings in the long term.

One particular challenge of this is the hierarchy of content as currently the left navigation pertains to items related to the current project, while the top bar has precedence (affecting scopes above a single project).

I think this placement actually works. The problem to me is that it is decoupled from the project switcher in the header. If that project switcher were more closely related to the primary navigation, it'd feel more natural to change settings for the project in that area. Likewise, if features are ever tied to a project and some kind of access level, this placement would reinforce the relationship between the two.

Another option would be including some kind of settings management within the current project switcher.

[clarkus]

@paolodamico, this is a rough wireframe I've been working on to think about IA and how to better relate things in the navigation. There's a lot of change in there, but I wanted to call out a few items that I think could help clarify the different settings areas.

1. Move the project switcher into the left navigation. This is purely to better associate a project to the features it has enabled, and to place supplementary features adjacent to the project identifier. This drives home that everything you see in the left navigation container is specific to the project. There might be opportunity to more tightly couple the project settings and toolbar items into the project switcher, but for now encapsulating project stuff to the left nav would be a clearer separation. Taking this out of the app header also reinforces item 2 below
2. Better separation of items in the user / utility menu. I am still debating the order of options here, but the key jobs of this menu are communicating who is logged in and which organization is active. Secondary to that, there are items for signing out or adding orgs. Removing the project switcher here further reinforces that this is an area of global configuration. Things here are specific to me as a user or to the organization I am working in.

I am working on a revised settings page design now, but wanted to share these initial ideas to see what you thought.

[clarkus]

I reorganized the project settings a bit to better align the page with other areas of the product. Notable changes:

• Toolbar settings and permitted domain / URLs are in the same section now
• Internal test settings are using a left-to-right sentence-like layout now to make better use of the space available. This same layout could be applicable to query filters.

I also combined the organization-related items into a single page with tabs for navigating between sections.

[paolodamico]

• I like the idea of having tabs in settings and centralizing. Should we separate membership & management into separate tabs?
• How about an instance licenses? These are a higher step than orgs in the hierarchy but we could consider adding them there.
• I also like the new layout for project settings. I wonder if we should separate sections even more with better titles? (e.g. Project Toolbar is a section that includes both enabling the toolbar and the permitted domains).
• Not sure if this fully solves the problem on this issue. We still have 3 settings pages, and it's not always clear a) where to find the right setting, b) that there are actually 3 different levels of settings (perhaps the personal settings / my account is a clear enough mental model, but I still have doubts on org vs project).

Thoughts?

[Twixes]

I think licenses should be part of a fourth scope: instance settings. This could in the future be a place for email sending configuration, some instance-level switches, etc.

Especially agree with Paolo on his last point about settings still being scattered around different pages. It'd be great be able to switch between scopes with just one mechanic.

[clarkus]

I don't completely agree that three distinct settings pages is a user problem. I think being able to find them is the core problem. Some separation can be really good as we add in more settings and control at each level of access (org, project, user). There can also be overlapping options within each area of settings and some separation can really help clarify that.

We also need to take user roles into consideration. Not all users will even need to change org settings. I think the way you navigate to these areas via prominent, constant representations of each context is a good start. I can also work to make settings easier to find within each page.

Can y'all help me understand the problem merging every page solves? I am happy to draw this out to test the idea, but I don't think I have a good enough understanding of how you're seeing the problem yet.

[clarkus]

I like the idea of having tabs in settings and centralizing. Should we separate membership & management into separate tabs?

These are so closely related that I left them together for now. Happy to separate if there's a good reason to do so.

[clarkus]

Quick update to illustrate how we can make settings pages easier to navigate. This includes a jump navigation that links to a specific page section. This does a couple of things - gives a prominent, succinct index of the scope of the page, and enables users to jump quickly to a specific section. This navigation would be fixed in the viewport and scroll along with the page content to maintain context.

[Twixes]

I actually agree that it's good to have pages distinct per scope, just that it would be useful if jumping from project settings to its organization settings were possible with a single click.

[clarkus]

I missed the note on licenses previously... I don't seem to have access to that feature in the app. Is that something we expose only to specific roles? I can incorporate that into the settings pages, but I want to understand how we're handling it now first.

I actually agree that it's good to have pages distinct per scope, just that it would be useful if jumping from project settings to its organization settings were possible with a single click.

@Twixes thanks for clarifying. I can work on some ideas for incorporating this into the IA changes I shared above.

[Twixes]

Licenses are not applicable to Cloud (they are replaced by Billing), but if you have a self-hosted instance (or just go to playground.posthog.com) I think you should be able to open that page when you open the account dropdown (top right corner).

[clarkus]

Licenses are not applicable to Cloud (they are replaced by Billing), but if you have a self-hosted instance (or just go to playground.posthog.com) I think you should be able to open that page when you open the account dropdown (top right corner).

Thanks for the guidance! I will add license management into the org screens.

[Twixes]

The catch is that they are not org-specific, because licenses work for the whole instance. In most cases this would not actually matter because self-hosted instances usually have just a single-org, but just something to keep in mind conceptually.

[clarkus]

Thanks that's great information to have. Is it accurate to say that the concept of an "instance" is only exposed in the self-hosted scenario? It seems like if most often there is a single organization per instance, or if we can enforce that somehow, we can more tightly couple instance and org settings into a single organization settings screen. I see the technical difference, but for a user there might not need to be as much separation.

That would all rely on the 1:1 relationship between an instance and an org. If multiple organizations per instance is a common scenario, I'll have to think through how we navigate orgs, too. Thanks again for the information!

Edit... the introduction of other instance settings might be more justification for separating membership and management into discrete sections.

[Twixes]

Yeah, it's only a self-hosted thing in practice (though as PostHog Cloud admins our team does see some instance-level features). For now I think it's alright to put this in org settings, though sooner or later we will end up needing further instance-level configuration UI (like #496).

[clarkus]

Here's a quick update to illustrate licenses in the context of a self-hosted PostHog instance. This is largely a reorganization of the table, plus incorporating existing functionality into the tabbed layout for organizations.

[corywatilo]

Some fly-by thoughts:

1. Tabbing seems like a solid way to manage different types of settings.

Gmail uses horizontal tabs:

He@p uses vertical tabs:

I think this just feels a little more organized than having scrollTo links and one giant settings page.

2. We have distinct division between types of settings

1. Account (Password, personal API keys)
2. Project (Project name, JS, timezones, webhooks, other settings)
3. Organization (Org name, users, delete)
4. Billing

It might make sense to keep them grouped in this way.

One major area for improvement is how to access these settings...

3. MVP: Should we move things around?

1. Currently Project settings lives nested alongside product features. It doesn't feel like it belongs here. (At least it took me a while to adjust to finding it here - I'd expect this to live in a utilities menu.)
2. Organization settings is realistically just user management, since you're likely not coming here to change your org name or delete everything.
3. Billing could live within Org settings, since they're both org-level settings. (@clarkus snuck in a last-minute mock above. A Billing tab seems perfect inside Org settings.
4. Seems like an easy win would be to move Project settings to the top right to live with the others.

4. Org creation vs project creation

Is there a strong use case to keep New organization where it's at? I'd be curious how often this is confused for New project which lives somewhere else.

---

Summary

I don't think this is the most important thing to tackle, but at least moving the links for all types of settings to a single spot seems like it could be a quick win to help clear up where to go to find these options.

[clarkus]

I don't think we should place project navigation in the utility / user menu. I think the project is the context that is likely to change most often for a user. Seeing a prominent, clear representation of the project helps me know that I am working in the right place. I agree that project settings could be more tightly coupled with the project context.

I was attempting to clarify this in https://github.com/PostHog/posthog/issues/4268#issuecomment-882800236:

Move the project switcher into the left navigation. This is purely to better associate a project to the features it has enabled, and to place supplementary features adjacent to the project identifier. This drives home that everything you see in the left navigation container is specific to the project. There might be opportunity to more tightly couple the project settings and toolbar items into the project switcher, but for now encapsulating project stuff to the left nav would be a clearer separation.

This change makes pretty much everything you see while working in the app a project-context. The exceptions will be the things you get to via that user / utility menu. If we ever do more role-based access to features, the project placement could also reinforce that not all features are available in each project.

Also related context at https://github.com/PostHog/posthog/issues/5346

All that said, I agree that this probably isn't the most important problem to solve right now.

[corywatilo]

Ah yes, didn't mean to infer the project switcher should be buried. Makes a ton of sense to have it in the forefront.

[paolodamico]

I really like the latest version with the LHS section navigation (particularly for project settings). One thing I'm not sure about is how this relates to org settings where tabs seem to be a superior option (as it'd be strange to scroll to find billing setting in the same page as team management). Should we have each version respectively?

I think the only other big change I would try to add is as was suggested a one-click navigation to the other scope settings, so if I reach the incorrect settings page, I can quickly navigate to the one I'm looking for.

[clarkus]

If we can define meaningful groups of related configuration options within projects, we could move to a left-to-right tab component at the top. I wasn't quite sure how to group those, so I stuck with an index navigation that jumps to sections. One thing to note is that left left side jump navigation is 1:1 with each section in the page. The LTR tabs would be labeling groups of options.

I'm going to challenge the 1-click optimization. Check out the work at https://github.com/PostHog/posthog/issues/5346#issuecomment-892242476 for context. This is an updated user menu which would provide a 2-click path (click on user, click on org settings) to user settings, org settings, and org swapping. While it isn't 1 click away, it is globally available and learnable. I'm not certain that clicks are a reasonable measure of effort here. It seems that being able to find the thing and quickly identify which option you want is more important.

At a minimum, I'd advocate we try the new user menu and see if it has a meaningful impact on users being able to find their settings. If it still proves to be difficult, we could optimize more. My concern is that we bias getting into settings over doing work in a project. Thoughts?

[paolodamico]

Was taking a look at the options we have in project config, and while I do think we could come up with some grouping suitable for tabs, I reached the conclusion that the LHS sidebar you proposed actually provides a better experience because it quickly lets you find what you're looking for. The mental model is the same as for org-scoped settings, the difference is that in the org we only have two settings: name & members. So my suggestion would be: either a) keep both versions respectively [if we don't think that's confusing] or b) do LHS sidebar for both [even if it's not ideal for orgs].

Re the 1-click navigation I think I mostly agree with your argument, though I was thinking we could do something like a simple notice (even plain text) that says something like: "Looking for your account settings or your organisation settings?" (Where "account settings" and "organisation settings" are links to the other pages respectively). Thoughts?

[clarkus]

I'd go with a) just because it seems better suited to each context. I was thinking a similar in-page alert could be a good fix for users that land in the wrong spot. I was thinking about it earlier, but wasn't sure what the thresholds would be for showing it. Seems like we wouldn't want to show it forever. Maybe show it until the user dismisses it once or twice?

[clarkus]

Just bumping this - recent projects have brought up the idea of moving some project-level settings into this view. There's a pretty complete concept at https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/?node-id=4325%3A30315 if anyone feels like taking this on.

[posthog-contributions-bot[bot]]

This issue has 2586 words at 24 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.

[Twixes]

I'm happy to pick the implementation of this! With continuing proliferation of configuration options (I've definitely contributed to that too) the need for a better settings system grows (noted in https://github.com/PostHog/posthog/pull/6395), I think it's a good time to handle this in a future-proof way.

[clarkus]

Excellent! I owe you one more update for the Access Control settings, but then it should be ready to go. I'll follow up once that's ready.

[clarkus]

https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf?node-id=4325:30344#116692604 @Twixes that's ready to go.

[paolodamico]

We've now shipped the new settings pages, and won't merge settings pages for now, so closing.

[Twixes]

We won't merge the settings pages, but we haven't shipped the improved (and future-proof) designs by @clarkus from this issue, which I think will still be worth doing (actually even more so over time as we expand settings).

[Twixes]

Done!