As Cwicly is pretty advanced, what I really like about it! Give us the possibility to build Blocks using Cwickly and register them with typed editable inputs areas. This allows for regular editors to write posts and use specific Blocks without needing to dive into said complexity, while keeping use Web designers in charge of design that doesn’t break as easily.
This is definitely needed. Cwicly is just too overwhelming for an average web designer, let alone a marketer/content creator. We really need to add some of that trademark Cwicly no-code elegance to the process of registering blocks, which we can restrict in different ways.
The discussion about complexity is a funny two-sided one. On one hand, many people don’t like the simplicity of base Gutenberg and Cwicly offers many options to them. On the other hand, clients and beginners will be overwhelmed by the options.
Blocks can be a solution to create complex layouts in Cwicly and save them for the regular users and clients. Beginners could select blocks from a growing library by Cwicly or the community and tweak them. Experts could build entire blocks from scratch or use existing ones as a basis. Clients would just use them and fill out the exposed fields.
Cwicly is still in the process of creating tooling. I think the following aspects could help in building a bridge between developer (full complexity), designer (mid complexity) and clients (no code, low complexity):
Slowly refine the interface to make it as easy as possible, but having complexity if needed. For example, this would be offering the essential settings to make something work and complexities are shown when needed (toggles for areas or pinning etc.)
Keeping regular Gutenberg as a driver for content editors. For instance, this might be a matter of taste, but I would use Gutenberg only to build my site-templates and blocks if possible. Additionally, I would keep clients from using Cwicly blocks as they lock them in content-wise and that should stay portable (from theme to theme) and is mostly too complex in the sidebar for them. Another point is that this would entail having a way to style default Gutenberg blocks as clients will mainly use them.
What do you think? Should Cwicly focus on simplicity or on offering more options? Let me know in the comments!
I do want to point out that there are two requests in this post, in my opinion:
A white label - simplified - restrictive version of Cwicly that developers/designers can set for their clients
Developing blocks from the Cwicly ecosystem.
As @MaxZieb pointed it out, the interface needs tweaking so that everyone finds their perfect point.
Cwicly has taken the direction of being a toolkit for developers/experienced designers that hand down their work to clients, who might/will want to tweak things here and there.
Easy tweaks/editing is where Gutenberg shines, so definitely, we have to take advantage of this.
We’re slowly moving towards a developer/designer defined block inspector, where you’ll be able to activate/deactivate properties for every Cwicly block.
The block development solution is planned for in our code, but realistically won’t be ready for another 6 months or more.
Thanks for your input, @MaxZieb, really happy to have someone as knowledgeable as you joining the conversation.
Being able to walk that fine line between offering a powerful tool that expert developers feel right at home using, while also being something that beginners can use is a job that I am glad I do not have to figure out.
My vote is for Cwicly continuing to grow into being a professional, advanced-level tool. There’s nothing like it in the space, and I think the other toolkits have gone the simplicity route, with the downside being that they are limited.
I believe Louis did comment on the lock-in issue, and is looking at a solution that removes this to allow portability. This gave me some relief earlier, because that would potentially be a dealbreaker.
Just wanted to clarify that my request was more combining those two.
Sure, there might be the added bonus of having blocks we create being available for the broader ecosystem, but that was not my motivation. That requires careful thought and planning by designers, otherwise we have users end up with mismatched blocks that do not properly solve their problems.
For any particular site being developed, there are elements that get repeated: two-column layouts, hero sections, testimonials, etc. Once these are designed, the next step would be to catalog however many variations into a theme-specific block library that gives clients freedom to put together pages as they see fit, all while maintaining the look and feel of their theme.
However, I will happily take more control over the block inspector to assign/limit user editing roles as a solution, until proper block building is available. This would be a familiar workflow for just about any developer.
As always, thanks for your thoughtful consideration, @Louis.
White label is not really the point. Happy to promote Cwicly. It is rather that I want them to mainly only use regular Gutenberg blocks for content, so that after years of blogging they can still change themes.
That is great way to offer the clients a simple interface to a complex design. Looking forward to that.
Are there plans to extend components in a way to develop custom blocks?
The basis is great, but going the custom block route isn’t possible for a bit more advanced use cases.
I can go in more detail here if you require.
I think this is extremely important, especially for the average user, as Cwicly does not offer dedicated blocks, like team member, pricing table, etc.
Offering pre-built designs helps but doesn’t solve the actual problem.
Users want to quickly apply settings, not fiddling around with numerous blocks and find out where to change styling.
A visual block builder, based on components, would be insane and opens many doors, as it greatly lowers the accessibility barrier, but also attracts designers/developers who can build an eco system around Cwicly.
