The drag-n-drop blocks/slices of content CMSes look cool in demos. As someone who has an in-house developed CMS editor just like this, it's a nightmare of constant updates. "Can we right align text and turn it blue?", "sure we'll add more and more props to each block". The actual content creators have a hard time using it effectively. So the results are almost always unsatisfactory. More training could possibly help but there's still a constant tradeoff between freedom and maintaining brand identity.
A headless CMS in our case would be a better approach. Simply provide the content and let a few professional folks code it up to match designs. Not everyone has that luxury I realize - so there's definitely a place for this type of CMS. I'm just pointing out how it can go horribly wrong.
Context: I'm the creator an open source page builder in Ruby on Rails named Maglev (https://www.maglev.dev), pretty much similar to Primo (congrats for their product, looks amazing!).
A couple of months, I used my own tool (Maglev) when revamping an e-commerce site of a client who didn't have a content management system to edit the marketing part of her site.
So I sliced the site into editable "Maglev" sections/blocks. The result was great in terms of editing experience BUT a couple of months later after the launch, my client hired another marketing person with HTML/CSS "skills" (I'd say 101 HMTL/CSS level).
And I had a hard time to convince her that it was a bad idea to write HTML/CSS code herself but instead to let me (or another developer) write the missing sections she wanted.
A solution would have been to add in Maglev some kind of dev editor like in Primo. However, based on my long experience, you really don't want your client to touch the HTML/CSS of your site. And I don't believe in the "you break it, you pay for it" mojo or at least this is not the kind of relationship I want with my clients.
On a higher level, any kind of CMS has the same issue. For instance, I helped a company with a broken Webflow site and it was the typical issue: a designer built their site and later the marketing person tried to "improve" the UI and broke everything.
> However, based on my long experience, you really don't want your client to touch the HTML/CSS of your site.
Certainly, and in the same vein you don't want your client touching the design of the site. Clients can barely write good copy, much less make good design decisions. My freelance projects go a lot more smoothly now that I can hand off the site to the client knowing that they're restricted to adding/removing blocks and updating content (and that they can't see the 'open code' button).
"A headless CMS in our case would be a better approach" doesn't the client just get mad they can't do what they want? You can only build so many components.
Ideal world is a CMS that allows clients to easily change the HTML without code. That way it loads fast, has great SEO and stops developers re-inventing the wheel.
That was the reason I built https://versoly.com/ (Website builder + CMS), why does the client have to contact you to change the background color or add a new section?
I definitely understand with the struggle to balance design freedom and brand identity (or good design). But wouldn't you still have the issue of content editors wanting to right align text and turn it blue regardless of the CMS you're using?
I'm building a GraphQL based headless CMS currently, ~2 months away from an official launch. It's currently wholly lacking official documentation but feel free to give the index page a peek and see if it's something you'd be interested in trying out!
(or if you just have general feedback or learnings from your own experience, I'd love to hear that too!)
Yup! That's the avenue we took. A React app as an editor, content blocks are represented as a large JSON structure. That structure is stored in a DB via Drupal. (The editor is actually jacked into the Drupal page editor). We use GraphQL as our integration service. There's a shared "blocks" library so the editor can do the layout, store the JSON and the front-end website can interpret that JSON and use the same library to rebuild the component structure. I will say that it's a neat system. Some folks are VERY attached to it. I don't feel it fits the business needs so I'm investigating other options.
Best of luck on your CMS! I'm always intrigued by what others build - so please don't take my experience as any sort of criticism - I'd love to see your project succeed!
I love the idea. Telling our content folks, "you can choose 1 of 8 different templates" would be great. In actual practice it's more like, "Ok, we want to use part of that template and we need to modify part of that other one - marketing wants this live in 30 minutes'. So, giving them the "blocks" approach has worked for delivery. Frankly I'm embarrassed at the results it yields.
A headless CMS in our case would be a better approach. Simply provide the content and let a few professional folks code it up to match designs. Not everyone has that luxury I realize - so there's definitely a place for this type of CMS. I'm just pointing out how it can go horribly wrong.