[later phase] Theme Builder vision

In the beginning, all of these actions are achieved through a low-code experience using a code editor within the browser.

I have to admit I can't get over my initial reaction about a "code editor within the browser", it gives me pause. What is the rationale behind this requirement? I would prefer, if possible, to not do this and jump straight to the no-code solution, without this stepping stone.

The design system may also have no-code configuration options (e.g. color schemes, fonts, spacing, etc) to enable non-technical builders to create experiences tailored to their brand and content strategy.

Yes!

Exposing a component to the Experience Builder should be as easy as it is with competing products.

Any examples of what it is like with competing products?

Thanks for this writeup @lauriii. My favorite part is that technical-builders and low-code builders are on the same track, even if using different tools. I think that having significantly different theme building experience would have eventually sidelined one or the other. I know we are focusing on the ambitious site builder persona, but at the end of the day there are lots and lots of technical builders building Drupal sites that we need to keep prioritizing. I see this vision supporting that.

In the beginning, all of these actions are achieved through a low-code experience using a code editor within the browser.

If part of the rationale for low-code, in-browser editing is to help ease new Drupal users into the developer role, I wonder if it makes sense & would be possible to ease them into industry-standard tools as well. Could the in-browser code editor be vscodum-based with some well-curated extensions? This could also help pipe new drupal users into contribution via DrupalPod.

Hi guys, @mindaugasd made me aware of this thread, because he had seen some of the stuff I was prototyping, so I just wanted to chime in for two reasons - I was playing around with this some time ago with ACE Editor and even custom fields that might visualize an idea what can be done. This was very much prototyping, but I have some ideas from that time. I put in a message in the beginning as well regarding the other thing I think its important to highlight - the usage of AI for this and what was possible back then (and probably moreso now).

The video is available at https://www.youtube.com/watch?v=NEtsYDzeq-g&ab_channel=DrupalAIVideos, you can skip until 8 minutes into that video to get some ideas of how it looked and what is possible at minimum with AI.

We're not intending to work on this in the months to come. But that doesn't mean the discussion cannot continue here — just that our focus will be on the Page Builder part of XB.

Linking related issues to improve discoverability.

I really like the proposed ability to export and import the overall look of a website as a "design system". I wonder, however, if referring to this as a "skin" would be more equivalent to the same capability in other systems marketers are used to. Perhaps it was would be useful to get real user input on the question of what to call this.

Also, I think it would be really useful if these could be projects on drupal.org and able to be searched and browsed using the Project Browser.

A “skin” to me sounds more like you could use all the same components but make them look differently.

A “design system” does more: it defines what the components are too, not merely what they look like.

A design system itself could have skins, but skins would inevitably be tied to a design system.

👆🏻 My understanding, and it’s been at least a month since I discussed design system details. 😅 Let’s see what Lauri says when he’s back from vacation on Monday 😊