Do you have plans to introduce a UI for field configuration?

[raybrownco]

Hey! Just spent the weekend kicking the tires on Payload. I'm really impressed by how well thought out the whole project seems. Y'all are obviously working your butts off and making a great product.

So far, most of my time has been spent in the docs, reading about config options...and then trying my best to remember them as I scaffolded out a bunch of collections. The field config definitely reminds me of a much friendlier version of ACF's JSON files, and I fully acknowledge the importance of a file-based data setup within a CMS environment.

However, I couldn't help but think that there should be some sort of tool that helps beginners scaffold out field configs via a UI. I suspect you might be against this sort of thing; after all, it seems that the file-based config is very much a first-class feature of Payload. But...on the off chance that you're not, I'd like to know if you have any plans to incorporate such a thing into Payload.

If so, awesome! If not, would you mind if someone like myself created an ancillary project to do just that? Thanks in advance for your response, and keep up the great work with Payload.

[jmikrut]

Hey @bitmanic — thank you for the compliments! We think it's turning out well!

I can understand your points for sure and we have had internal discussions around this for a while now. Overall, we absolutely welcome the idea and have some thoughts as to how it could best be incorporated. As of right now, we don't have any concrete plans to build something like this but it is definitely on the radar. I'll do my best to flesh out our prior thinking to see if we can maybe spark some synergy here.

UX Considerations

• Any type of "collection / global" UI builder would be most helpful in creating Fields, although it could be used to create entire Collection / Global configs (labels, upload, auth, other admin UI options)
• A UI builder will be most helpful in a user's first X days with Payload, because after that point, fields and their settings are memorizable and the utility of a UI builder diminishes.
• It could likely be built directly into the Admin UI if done right. If it is built-in, its access should be able to be controlled via config so as to be able to hide it from those that don't need it (editors, content people, etc.)
• Alternatively to building it into the Admin UI, due to its universal nature, it could even go right on the Payload website... Thoughts?
• A great UX might be sort of a WYSIWYG builder... where you drag + drop fields, configure, etc. and see a preview of exactly how the Payload Admin UI would look like when using the field config

Technical Requirements

• Because Payload developers can write their configs anywhere, at any time, this UI builder may be limited to only "generating" field configs, which would then be able to be copy-pasted into developers' filesystems where and how they see fit. Kinda like ACF's PHP copy+paste.
• It would be ideal to have a way to automatically write output field configs into the filesystem, but that will come with a lot of technical overhead and complexity. Strapi has a similar pattern there and they have to deal with Node server restarts and all kinds of stuff, which further complexifies the Admin UI which should remain extremely minimal and understandable.

Anyway, we would WELCOME further contributions to this idea and would be happy to continue its discussion. We may want to mock up a UX prototype as a first step if this feature is commonly requested. We are working on our public Roadmap now, and this feature will absolutely be added to it.

What do you think?

[DanRibbens]

@bitmanic Thank you for this feedback!

I see the configuration UI tool (eventually) existing on our website and offered as an alternative means of "Getting Started" instead of npx create-payload-app. Having a node environment and using the command line instantly limits our appeal to users who willing to use the command line. We would have a lot of work involved to make every option in the config editable within the UI, but it could be worthwhile.

Having the builder functionality is exactly what people are searching for in "low code" and "no code" applications. I also think we could, in the future, help bridge users from the config builder to CI and hosting by adding a workflow that commits to their github repo on their own account. I would want to validate that the market exists before going this far.

Payload is built for developers #1, but other users could be empowered and even drawn in to do development with this kind of tool. I think this fits our strategy well, Payload should be as simple as possible for users as we've done already, with the style in how documentation is written. Wordpress is the go-to CMS in spite of its faults because of how simple it is to host a PHP website compared to other languages.

[raybrownco]

@jmikrut and @DanRibbens: thanks for the great feedback.

I definitely agree that a UI-based field/collection creator feels more like a scaffolding/generative tool rather than something that devs would constantly come back to again and again. As for where that tool could/should exist, my personal opinion would be to not have it live within a Payload CMS instance's admin panel. I think people seeing a GUI for creating collections/fields within the admin panel will instantly expect it to work like WordPress, Craft CMS, Contentful, or whatever other CMS they're used to.

Payload is decidedly (and intentionally) different from these other CMS options. Maybe some day down the road, a fully-featured GUI for managing fields would be something to consider, but it's quite obvious that the current focus is definitely not in that direction.

With that said—and with all due respect—as a new user, I've found it a bit difficult to keep all of the available options in my head when I go to create a new field/collection. A simple checkbox field has 12 config attributes, and half of them can't be configured without additional knowledge from other documentation pages. So...to fully understand a checkbox field requires an inquiring developer to visit at least seven documentation pages. And that's just for one of many fields that I'd like to add to any given Collection, which has its own mass of configuration documentation.

Please don't take this as a shot at Payload or its documentation. The documentation itself is completely stellar. You've done a wonderful job with it! I'm definitely not trying to complain about it in this space. My intention is to communicate the "modularity" of the system, which is complex but necessarily so.

At this point, I should note that the types at src/fields/config/types.ts have been so incredibly useful. They communicate so much great information about each of the field types concisely. That file's also been useful in helping me understand which field attributes are global versus specific to that field. The UI I see in my head for field configuration looks quite similar to these type definitions.

A few remaining thoughts:

1. A UI builder, as you noted, seems most valuable to devs who are still learning Payload and/or setting up new Collections.
2. A config generator should probably be hosted on the Payload website (or some other resource) instead of within a Payload CMS instance.
3. Something to consider: perhaps let people share their configs with others? Or...have a showcase of config examples, sort of how Tailwind CSS offers style examples via Tailwind UI? They've done a great job of communicating that the components at Tailwind UI are a starting point of sorts - the dev is expected to copy/paste/modify the code as needed. These config objects are shaped similarly. (I see that you've already gathered some 'demo' configs in the repo.)
4. Perhaps another approach worth considering is not a UI, but something like a VS Code Intellisense plugin or something. The reach of such a tool would be narrower, but it would be much closer to the code, which is probably exactly where devs want to be.

Sorry for the delay in response, and also for the lengthy one!

[seaj1one]

I'm not a dev and looking for a low code CMS that is more powerful than Wordpress. I'd like to see a UI that allows me to manage my content. I use Metabox, which allows me to create custom fields and posts but also shows me the PHP code. As you add and remove components, users can learn as they go.

[seaj1one]

An additional thing I'd like to add if this helps.

Metabox has a separate field generator at the top of this link and a field generated within the plugin. I mentioned the field generator as it could give the option to copy and paste the code.

https://metabox.io/

[ToneseekerMusical]

@jmikrut
As someone who's self taught and has never worked in tech a day in my life, I find the current state of Payload incredibly intuitive, extremely well thought out, and beginner friendly, even for those with almost no coding experience, however, in its current state, Payload can be quite daunting for those who don't have the desire to learn to code, and even people who aren't afraid to get their feet wet, but are still new to coding. With that in mind, I'll happily say that I think this feature request would be a huge step in the direction of bringing more Wordpress users into the fold, and if you add in a GUI for access control management, it would be leaps and bounds ahead of any of the other CMS systems I've personally used.

As a businessman however, I don't think that forcing your inexperienced users to go to your website every time they want to add a new collection is the right move, especially after they may have possibly struggled to get everything set up. I'm of the mind that this feature should only be accessible in devmode, which would mitigate damage to the site by users without admin control of the box that it is hosted on.

Additionally, to address some of the thoughts on Wordpress/Low code/ No Code users, I think that having an executable that installs a clean NodeJS, MongoDBCompass, and Payload instance on the user's local computer and functions similarly to that of XAMPP or OS specific installations such as W/L/Mamp would greatly improve your conversion rate from your competitors. You could have a devmode switch on the application to enable and disable devmode, a gitpush button that would push any changes made to the user's github repository, and a build button to generate a build of the application, ready to be copied to whatever server the user may have.

[hades200082]

I just want to throw in here that the primary pull of payload for me is that all of the content model is version controlled in code.

I moved to payload from Strapi specifically to get away from GUI content modelling.

[seaj1one]

Can there be an option for both in theory?

[hades200082]

Strapi do this. It means their gui can only be used in dev mode and causes a rebuild of the server when you save a content type.

Additional consideration would be that any gui would need to provide for reuse of types and create a good file structure

I also don't see any way for hooks or access control to be handled simply in a gui/No-code

I do like the idea of having a separate tool for field/content type generation

[ToneseekerMusical]

I'm actually working on a desktop application that will solve this issue and keep any file manipulation functions on your local machine so a malicious party can't do nearly as much damage as they could if it was a built in feature. It's still in its infancy, but it's coming along quite well. It's built to set up a computer from scratch in order to entice Wordpress and low-code / no-code users to try Payload.

In its current state, it downloads all the tools needed to develop with Payload and adds them to your system PATH environment variable. You can currently set up and delete multiple blank payload sites without a frontend.

There are quite a few things that I need to do before I can add a GUI collections editor, but I'm working toward that goal. This will eventually allow you to build an entire website from a GUI, push it to a Github repository, build the site, export the database, and package it in a file that can be uploaded to any webserver to be installed.

https://github.com/ToneseekerMusical/PPIM

[seaj1one]

@hades200082 @ToneseekerMusical Good news to hear something is being developed. As a non-developer, I wouldn't expect any GUI to be able to do everything.

I'm used to using a little code that someone provided and accept that I may have to learn a little bit. It may also help me to understand the code better too. 😀