Expanding Design System Management Beyond Tailwind Integration

[oppi]

The new Tailwind integration represents a significant improvement, enhancing the efficient and popular workflow of Cwicly. And I see that people who already had a positive experience with the framework appreciate the integration even more.

However, I have reservations about Tailwind. Managing numerous classes can be overwhelming and stressful to me, and while I recognize the benefits of a utility-first approach, I find it appealing only to a certain extent due to the excessive number of classes involved, with only a few being necessary to build a comprehensive system.

For me, Cwicly is not just a classic page builder, but it does solve a lot of other problems for me as a WordPress and frontend developer that wants to craft custom themes and holistic WordPress environments that I sell to clients: I don’t have to struggle with npm and stubborn local dev environments anymore. I have everything I need at hand and it allows me to comfortably write custom (S)CSS.

The Idea

I’d like to have a way to leverage the new class selecting system and combine it with what we already have: Design System Management

This integration could simplify the process, as we currently have the capability to set up tokens for colors, gradients, default typography, class management, elements under global settings and since Cwicly 1.4 we can use combinatorial styles on components. A unified, user-friendly UI that showcases global tokens for their respective fields in the editor would enhance the user experience significantly.

My concept aligns with a “core framework,” and I envision a dedicated area within Cwicly’s settings (possibly outside or in the editor) for organizing project tokens clearly and logically. This approach becomes particularly vital as website design projects, which often begin simply, evolve and grow in complexity. Those tokens could be named freely of course and allow for readable BEM naming for example.

Specifically, consider the example of a button system. In its initial state, such a system may not be complex. However, the ability to efficiently cater to new variants as the project advances is key. Currently, in Cwicly, setting up elements like buttons is primarily confined to working within components, which often involves a nested and somewhat cumbersome process. I propose a more integrated and straightforward method for creating and managing these elements. This new method would allow for easier adaptation and expansion of button systems, reflecting the evolving needs of a web design project.

Let me put it that way:
I’d love to create an alternative system similar to Tailwind in Cwicly, but with my rules and classes selectable in the block editor we all appreciate in a stupidly easy manner.

I would appreciate your feedback on these ideas and welcome any suggestions or insights you might have.

PS: I am aware some points were discussed in the latest “Fact-checking Tailwind Sceptics”, and I absolutely don’t want to pick sides or anything. My POV: I want it all and everyone is right

[Marius]

@oppi

The Idea

I’d like to have a way to leverage the new class selecting system and combine it with what we already have: Design System Management

This is the goal, I believe, and it’s being worked on (if I get your point).
The new color system was only the first step.
Controlling everything via variables which you can setup and manage, and then apply to applicable properties via variable picker, just like you can with TW (via Popover selection menu).

@oppi

A unified, user-friendly UI that showcases global tokens for their respective fields in the editor would enhance the user experience significantly.

This is already available under the Globals Tab and will be extended as new options get introduced.
What are you missing?

[oppi]

yo @Marius!
I know the globals tab serves as a good starting point. But my vision is something different, a more integrated and maybe focused solution that allows for an organized way to create tokens to use in the editor. A blend of everything that makes cwicly awesome into a single place to create working Design Systems. For ourselves as devs and our clients.

[Marius]

I see, @oppi!
Yes, maybe something to bring up when the currently ongoing process is complete. Quite a few important things are still missing in the Globals Tab, as they haven’t been implemented yet in general. It’s a bit early, but I get your vision.

I like the idea to an extent, but nothing that couldn’t be achieved within the Globals Tab with some tweaks (which aren’t currently necessary for the above-mentioned reason).

Thanks for sharing your thoughts, curious about what other users think and if there are points that are (currently) lacking in that regard.
Appreciate this topic and certainly will return when time has come

[StrangeTech]

@oppi

I’d love to create an alternative system similar to Tailwind in Cwicly, but with my rules and classes selectable in the block editor we all appreciate in a stupidly easy manner.

Yes, I believe this is almost identical to what I requested during the first Tailwind preview that @Louis shared for us.

All of the selectability benefits of Tailwind with complete customisation.

I am still exploring more in-depth configurability of Tailwind, so it is possible that with some work, some of these things may already be possible using a custom configuration, but I do think this is a valuable request.

[oppi]

I gotta elaborate on my idea.

The big picture should be an alternative editor like the one from core framework. It can generate meaningful CSS variables as tokens that are used in the cwicly panel.

But for now let me illustrate a practible example with text size tokens.

For a MVP solution, we could have a simple selection dropdown that suggests global tokens (CSS variables) from an external stylesheet we activated. A fuzzy search guarantees a fast workflow.

Later on I’d like to see the Tailwind approach with a nice layer that contains custom named tokens. Those are managed in a dedicated space.

And that’s for a simple example of text tokens.

---

The Design System Manager I envision has a lot more to offer, but derives from the actual features Cwicly already brings to the table which I outlined before.

[Marius]

@oppi

Later on I’d like to see the Tailwind approach with a nice layer that contains custom named tokens. Those are managed in a dedicated space.

That’s exactly what I expect to happen, based on various indications. In addition, to unify the experience, any other approach wouldn’t make so much sense, in my humble opinion.

Global colors work the very same way already (color picker requires a different UI than a dropdown of course).
Not only can you decide how you create/name your vars, you can also add a custom name/description which shows up when the user makes a selection.

Until that’s available in a complete state, Cwicly has been further developed and evolved. So let’s see, maybe your envisioned design manager, in one way or another, is already a part of the UI.
Since this is UI related only, the actual functionality needs to be introduced first. Then, a lot is also dependent on user feedback.

[oppi]

@Marius

Since this is UI related only, the actual functionality needs to be introduced first. Then, a lot is also dependent on user feedback.

True! That’s why I started the topic in the first place. I see what great work @Louis did with the TW integration and want to advocate for opening up the system to allow for more frameworks and custom approaches. Most of the functionality and data modeling is already there. I know there is still a lot to be done, but although I’m new to this community I already love this place here and the opportunity to be part of a create process.

I hope to find some time in the next couple of days to illustrate more of the concept. Rearranging my coarse thoughts on this and hopefully come back with some UI concept.

[owynter]

@oppi

want to advocate for opening up the system to allow for more frameworks and custom approaches

Some of this is possible now with the Tailwind integration (though this takes place within the Tailwind environment to some extent).

With TW’s custom theme configuration, you can set up your own keys (tokens as you refer to them) through the Cwicly interface.

Here’s a video I did to explain how I’ve approached it: Cwicly-Tailwind.mp4 - Google Drive

With some improvements, we could get to what you were illustrating in a more comprehensive way.

[yankiara]

Hi @owynter,
And thanks for this great demo.

I have the exact same kind of variables based configuration, and your demo partly answers my request #3 in this thread

[oppi]

That’s definately an interesting approach, thank you for sharing it, Orett!
I’ll give it a try and see if I can simplify the overwhelming palette of options in TW that way.

Again, the big picture I had in mind follows a new and more centralized and organized way to manage all that. I imagine a native Cwicly design system like Tailwind, Bootstrap or the Core Framework on the one hand. On the other hand I want a lean way to integrate third party frameworks. That does not necessarily involve fiddling with text based configs.