Dashboard Redesign

[louisescher]

A proposal to redesign (and, if necessary, rewrite parts of) the StudioCMS dashboard.

Champions

• Louis Escher (@louisescher)

Overview / Motivation

The current StudioCMS dashboard, while functional, leaves a lot to be desired in terms of UI/UX design. Since this project aspires to be the default CMS for all Astro projects big and small, a better dashboard is needed to facilitate the needs of multiple types of users - be it developers or office workers.

Principles:

• The dashboard should function on all devices.
• The dashboard should provide an easy way to manage StudioCMS for everyone, not just developers
• The dashboard should be easy to get used to
• The dashboard should provide functionality that can be extended as needed, in future updates and with plugins

Figma Prototype

I have created a Figma board and a matching Figma prototype that can be used to see an interactive early version of this concept.

Things that are needed for this to work

• The plugin definition syntax needs to be reworked in order for plugins to be able to:
  • Transform content before it is saved in the database
  • Add cards to the homepage to display info at a glance
  • Create their own settings pages based on a template/fields syntax that gives them access to input components
  • Allow plugins to add their own page content fields & implementations
• Issue #293 (Optional diff option) would need to be implemented
• The permissions system would need to be overhauled:
  • A new Owner permission, given to the person who did the onboarding
• A new invite system to add new users via a link
• A shared component library for all inputs, modals, layouts etc.
• The onboarding logic would need to be reworked somewhat to allow for OAuth accounts to be added during setup
• Some changes would need to be made to the current markdown editor

Feedback on design & functionality would be greatly appreciated! 😊

Note: This UI change has been discussed on the Astrolicious Discord Server in the #studiocms channel for a few days now. Refer to that for suggestions that have already been made.

Amendments

• Login page POC
• Double sidebar POC

[Adammatthiesen]

The plugin definition syntax needs to be reworked...

✔️ I would love to see a full example of what you where thinking for the layout of the plugin definition system

The onboarding logic would need to be reworked somewhat to allow for OAuth accounts to be added during setup

✔️ The only problem for oAuth during setup i see is how does the user get their oAuth account setup? For oAuth to work it requires the index/callback endpoints being available and for the user to be redirected. I'm assuming something like the following would work:

1. User goes through basic configuration to setup the base data
2. User presses the button to continue and it pushes the first part of the data into the DB.
3. If the seed is successful than show a new panel that shows authentication options
4. User either uses local username and password and continues on the same page, OR clicks one of the oAuth button options
   1. When a user uses oAuth we would have to redirect to the correct API Endpoint have them login and return to the callback endpoint
   2. The callback endpoint would be modified to allow the new oAuth user to be added to the Permissions table as an Owner and then be returned to the /done page in the end with final instructions(of course this would be linked to the dbStartPage config option)
5. Once the user hits the /done page they would continue as usual by updating the config

A new invite system to add new users via a link

This is going to require some thinking, the basics of the dashboard and the table wont be hard, but we will have to kind of rework the endpoints to allow for this, i feel like it will be part of the rework for allowing connecting extra oAuth accounts to be connected, as that will a bit of a complex system... (i am thinking it might be better to actually split out the actual user and auth tables out a bit and use table references to make the whole system a bit easier to manage in the backend)

Some changes would need to be made to the current markdown editor

The dashboard editor correct? not the renderer?

[Adammatthiesen]

Made a gist to visualize this...

Great visualization! Looking forward to having an updated system, this system was mainly made so that we could have the @studiocms/blog package, and sadly wasn't 100% thought about how it could fully interact with the interface. This would definitely provide us with that! There will be a huge upgrade to the entire plugin system to facilitate this and provide any potential developer a good experience while working with StudioCMS, primarily in the way the current virtual module is, i will be working on a system to even create full .d.ts files for plugin devs so they can be sure they have full typings! 😅

[Adammatthiesen]

The dashboard editor correct? not the renderer?

Correct.

Could you elaborate on what all the expected changes would be again here? there has been quite a bit of conversation on this.

[louisescher]

I'm mostly talking about two things:

1. The markdown editor would need to be extended to allow for the formatting buttons in the top right corner and to paste images like in GitHub (something I'd love to be able to do, I made a proof of concept here)
2. The markdown editor would need to be decoupled if page type plugins could bring their own editing solutions, for example an FAQ plugin having a card-based system for which they provide their own component

[louisescher]

If we decouple it into a separate package we could also allow for plugins that want to use the normal editor to hook into the different events a textbox gives us

[Adammatthiesen]

The markdown editor would need to be decoupled if page type plugins could bring their own editing solutions, for example an FAQ plugin having a card-based system for which they provide their own component

If we decouple it into a separate package we could also allow for plugins that want to use the normal editor to hook into the different events a textbox gives us

There COULD also be the issue then of the form not being able to get submitted correctly 🤔 I've had issues in the past getting components children to work with forms correctly... i'm not sure giving plugins the ability to directly USE the main content editor is the best plan,

It might honestly be best to offer a text element that they can use to link to another page where their editor would be instead(allowing them to disable the base editor but not override it)... that way they can lineup their content the way their DB tables need, Using the FAQ plugin as an example, IMO it would make more sense for it to bring its own editor page that also has a [id].astro route that can directly be linked from the id route i have and provide for page editing/creation, where it could provide a custom form, that would fit their frontpages and custom DB table to keep things more organized, and for them to even provide custom metadata for pages! for very simple example, a default OG image for all FAQ pages.

IMO if something should be part of the main system than it should be part of the main ecosystem so there cant be any chance of breaking the tables. (libSQL is a fork of SQLite, both of which are quite a bit less forgiving then say MySQL or Postgres, so we have to make sure we don't give plugins to much chances to screw up the tables... For example a rouge plugin that is outdated and has a old table schema could cause some MASSIVE damage if AstroDB doesnt catch it first)

[louisescher]

Amendment 1

Login Page Prototype

We (the community & I) have created a prototype for a login page that you can view in your browser:

• https://louisescher.github.io/studiocms-login-test/ (Webpage)
• https://github.com/louisescher/studiocms-login-test (GitHub Repo)

Contributions for new StudioCMS-specific backgrounds or new looks (better glass material / outline) are appreciated. Just open a PR on the repo. A guide can be found in the README.md file. If you find any bugs / performance issues, please open up an issue on the repo.

Palettes

Here's the palette found in the prototype, plus a light mode version:

[jdtjenkins]

Foreward

So first off I want to say thank you to @louisescher for championing this and really driving this forward.

I think the designs look amazing so far, I'm really pleased with what I'm seeing and I think all these design changes will make StudioCMS much more appealing to people and really set the groundwork of improvements and additions to the platform in the future!

So, since this redesign was quite in-depth, it does almost immediately throw up some big, big questions as we discovered on our call a few days ago! I'm just going to jot down the big questions we had and what I can remember basically.

Chapter 1) Off the rails immediately and it's only been three sentences

1) A folder-based page structure
So at the moment each page (and therefore slug) is just a flat thing all on the same level. To create a page you have to manually specify every part of your path for each page at that directory. For example if you have a blog and want to separate your posts by year and month, which is a very common thing, you'll need to have three separate pages, each with the following slugs:

/blog/2024/09/i-met-donald-duck
/blog/2024/09/i-hugged-donald-duck
/blog/2024/09/donald-duck-filed-a-restraining-order

Which is a nightmare to manage, especially for non-technical people. But also from a UX POV, you want to slap in a page title and have it generate the slug. But you can't do that if you also need to manually enter the rest of the slug with the whole path and everything. It just wouldn't work without more kinda bs.

So the idea here is to have a simple folder structure, where you'll create a folder which is a subdirectory, then pages created in a directory automatically get the tree's paths prepended and stuff so each page's slug only pertains to that page.

2) Block based content
So this is more of an opinion section. The question of GrapesJS reared it's juicy head and whilst I think in the future it may be a good idea to look at, the main story I want to focus on right now is the story we have. Creating whole pages from mdx, and having your template set up in your project to inject whole page content into.

That being said. Another interesting avenue we could go down is to be more like Storyblok and offer more "block" based content which is user-defined and in no way tied to a specific page. So say if you want reviews, or just little snippets of content somewhere, it's not tied to a page and it's easier to manage. To fully understand this section just go try out or watch a video on Storyblok - it's fucking awesome.

3) Plugins and extending functionality
This one is a rabbit hole. But basically how should StudioCMS handle user-created plugins and what data or how should they allow the user to create extra functionality. This isn't really part of this redesign proposal - but it did come up when thinking of ideas for the previous section. Since it was somewhat hinted in the designs we just chucked around some ideas.

4) Our userbase
We have a really interesting userbase. Because it's a CMS, we have developers and end-users (who we can assume are not techy at all).

But we know the devs will all be Astro devs, so we can really lean into the Astro framework and it's features. Anything Astro can do, we can do. Which is really nice, the DX for StudioCMS should be great.

And because we know that at least our current main story (or at least the one I think we should be focussing on) is just whole page content, Astro let's us really nail that too.

5) The double sidebar
Yeah I think this is an interesting one. Before I commit, @louisescher I want to see some mobile designs for this, and maybe some prototypes too, to see that it's not going to become unmanageable. Bearing in mind it's mostly going to be vanillajs controlling it!

Chatper 2) Back on track...?

Back to the redesign:

I love the current direction of the redesign. It's like Vercel and StudioCMS had a baby and then we added shit tons of bloom with 3js. So for me, as I said, I think the more important thing rather than just the application looking baller - is really seeing how we can lift and shift things. How quickly we can iterate on these ideas. And what it'll let us do in the future!

So far from what I've seen, I think this project will create such a massive boon for the project and lay the foundation we can easily build off of in the future.

[Adammatthiesen]

1. A folder-based page structure

erm... folder based page structure is going to be interesting to setup... ( I honestly was not sure if the current setup would allow /2024/09/your-slug but was glad to see that it worked, for plugins to manage this using settings would be one thing... but being built in could face other routing challenges. ) that being said... currently for example @studiocms/blog is built using ATP, which by default would not allow us to define slugs like that as its built to be user controllable... meaning the user can change pretty much everything. if we wanted to drop ATP this could be avoided.

2. Block based content

User defined blocks ( components ) is really only possible currently with Markdoc within StudioCMS due when its React rendering system is enabled... This is another project i still need to work on, as it would require a setup similar to how astro-remote lets users assign custom components.

3. Plugins and extending functionality

A rabbit whole indeed.

[louisescher]

erm... folder based page structure is going to be interesting to setup...

The current slug structure and way of saving everything could be maintained, the "folders" can be created from splitting all slugs at runtime and be shown to the user. Think of them like OneDrive folders, folders in a cloud - just representing part of the slug so the user understands it better. No need for DB changes here.
Edit: By "at runtime" I mean client side in the browser (or wherever we map the articles to the components)

[louisescher]

Amendment 2

Double-Sidebar on Mobile POC

@jdtjenkins asked me to create a mobile version of the double sidebar, so here you go:

• GitHub Pages deployment
• GitHub repo

The general idea goes as follows:

1. When visiting the content management page on mobile, you start with seeing the "inner" sidebar
2. You select a folder to navigate into, and eventually click on a page
3. The sidebar gets hidden and the editing content is revealed to you
4. At any time, you can choose a different page via the hamburger menu in the top left corner
   Side note, might wanna have a modal warning about leaving the site without saving changes
5. You either select a different page or head back to the "outer" sidebar with the arrow button

A couple things to note about the POC:

• A few animations are broken in the POC, I expect them to work properly once this is a well implemented system and not just some thrown-together HTML
• After talking with @jdtjenkins, we agreed that it makes the most sense if the sidebar extends to full size on mobile devices, to cover the whole screen. This is something we will implement in the actual dashboard, but not in the POC.

[louisescher]

#296

There is now a PR for getting the first version of the UI library merged into the main repository. It will be available as @studiocms/ui.