Thanks @Marius & @Louis for the thoughtful responses. This might actually be a more interesting topic than I initially thought.
Edit: Novel incoming.
No need to worry! The whole purpose of the post was just to open a discussion and get feedback like yours.
Of course, the suggestion to remove a feature isn’t something that would affect me personally.
It’s more thinking about Cwicly’s user experience in general and providing whatever feedback we can to make sure that when a new user tries the builder for the first time, they feel like “this is for me.”
Any time a user feels friction, it compounds, and I was initially thinking that the Linked Blocks feature might be something that creates friction.
This is interesting. I hadn’t really framed it as using a class but without needing to add it to your global stylesheet. I can see the appeal in that.
But here’s where I struggle with it.
In what case would using Linked Blocks be considered best practice?
If you’re building a standard site, you’ll want to be able to reuse sections and components across different pages.
Even if you think you’re just using it for this one page, you may change your mind down the road or want to run an A/B test.
If that ever becomes the case, you’ve left yourself in an undesirable position because if the master block ever gets removed, you’ve lost your styling everywhere.
Edit: it looks like if you delete the master block your linked styling still remains on any other page you pasted the block on. However, you can’t actually edit that styling anywhere now.
The second issue is developer hand-off. Client-First by Finsweet is a framework for Webflow, but this part of their methodology has always stuck with me:
- To create a Webflow build that is scalable and easily manageable
- To help developers, clients, or anyone understand the project
A Webflow developer, client, or any person should be able to understand what a class is doing based on a class name, even if that person has no experience with Client-First.
Linked Blocks are an abstraction from these principles.
Imagine someone else at your agency has developed the site, and you load up a page that’s utilizing linked blocks. You click on a secondary instance block and you:
- Have no idea what styling is being applied
- Have no idea where the styling is actually coming from
- See an autogenerated class name that doesn’t describe its utility
The first two could be tweaked with UI changes. The last one could potentially be resolved as well if you rename the autogenerated class, although when I tried that it looks like the linked styling still just gets applied to the auto class.
The last thing is feature complexity. It seems like a simple feature on the surface, but the more I play around with it the more I realize how much logic must be going on in the backend.
Let’s say someone has the base understanding. When you create a linked block, it simply adds the autogenerated class of the first block as a virtual class to the second block. And those block classes only exist on the page that you’re on.
But then you go to another page, add something from your collection, and see the option to add a linked version? My brain goes “error error 
.”
So classes can be copied from one page to another.
And when you copy a block from one page to another it still works. But if you add styling to a nested element on the source page, it doesn’t get reflected on your new page even though the class names are the same.
As you can see, it just feels like there’s a lot of logic that the user needs to understand. And that creates friction.
Don’t get me wrong, I can see the benefit of the feature. If you’re building a one-off landing page or are trying to build as quickly as possible, it treats your stylesheets better.
But is the benefit worth the complexity?
And does it help web designers build a better, more scalable website?
Ladies and gentlemen of the jury, those are the facts I present to you in this case.
In all seriousness, these are just some personal thoughts & observations to consider. Even if only helpful for tweaking the UI in the future or adding to the knowledgebase.
If users are finding the feature useful, then please leave it as is!
), but I think for most users their potential is hidden behind a counterintuitive UI and vocabulary. I can imagine, well, in a very limited extent, that FSE and WP/Gutenberg constraints give you some hard time implementing Cwicly, but just a bit more attention on this would be a game changer and would really make Cwicly shine even more way above the competition.