chore: Move developer-related settings away from user-facing features

[martpie]

Feature

• Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
• Related issues linked using fixes #number
• Integration tests added
• Documentation added

¯_(ツ)_/¯

Ok, so I was just playing with outstatic to see how hard it would be to contribute, take this PR with a pinch of salt. I'm faster coding than talking, so I did not create an RFC for that.

I finished creating a small website for my gf using a CMS. She is highly non-technical (types with one finger, does not understand anything about computer except opening chrome).

When I told the content of her website was ready to be updated via the CMS, I did not give her any indication on how to do it (good UX excercise). There was basically one collection called "Events". She was supposed to create a new Event, add some content, save, and profit.

What she ended up doing was creating a new collection (!), called with the name of the event she meant to create, then starting adding stuff to it assuming all would work.

Back to this PR: I thought it could be a good idea to separate the developer-facing stuff from the UI that is meant for content editors, avoiding this kind of things from happening. I believed the main issue was that the default page when loading outstatic was the list of collections.

This PR moves Settings + Collection list away from the rest of the content edition pages, to make them less prominent CTA (only the dev should go there, not users). Here's a screenshot of the result.

There are a couple of things that still need to be checked:

• The default homepage for users should probably not be the list of collections
• Alternatively: The dashboard should not show the collections, but stuff related to content, not structure, so the dashboard could stay up, but a new page should be created called "Collections Management" (or something), and placed next to settings.
• Test the empty state

WDYT of this change overall? If positive, we can work on addressing the points above.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 65dcf2e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

Deployment failed with the following error:

There is no GitHub account connected to this Vercel account.

[vercel]

@martpie is attempting to deploy a commit to the Andre Vitorio's projects Team on Vercel.

A member of the Team first needs to authorize it.

[avitorio]

Hi there,

Thanks for sharing this interesting experiment. I enjoyed reading through it.

I understand how someone unfamiliar with the system's concepts could make that mistake. While I support the idea of separation, I agree that we should maintain a Dashboard where users can view their content overview.

Here's my suggestion: Let's create a "Content Types" section in the sidebar, with "Collections" as one option. This layout would also accommodate our future plans to support singletons. The Collections page would be exactly like the current Dashboard.

The Dashboard would be replace with a page that still displays the collection list as it currently does, but with two key changes:

• Remove the "Create New" button
• Replace the settings and delete buttons with a simple "+" icon that either direct users to create a new document, and when the card is clicked or takes them to the document list.

I recommend keeping the settings section in its current location for two reasons:

We avoid potential design issues that could arise from handling numerous collections
It's not worth heavily investing in the current sidebar since we're planning to upgrade to shadcn/ui sidebar soon

What are your thoughts on this approach?