Visual Editing Services
To address the challenges with editing content in headless CMS system, we’ve seen two types of tools emerge:
Live previews within headless CMS
Visual editing services
How visual editing works
Typically, services are taking one of two approaches to preview content today:
Deploy preview: Using either a deploy preview or a built version of the site, the preview system will swap content on the page by interacting with the DOM as editors make changes. In some cases, the service may store changes made back in the content source.
Development server: Some services will run your development server on your behalf and make actual changes to the content source as editors make changes. This is like a content editor making changes to a site running a development server, without having to manage the technical pieces.
Live previews in headless CMS
Some content management systems have introduced the idea of live previews, where content changes within their system can be seen in real-time. Both Contentful and Sanity have some form of a live preview.
While this feature is certainly powerful for those already using these services, it comes with challenges:
Multi-site / omnichannel: Many headless CMSs serve multiple frontend websites. Previewing a record in a CMS might not be as simple as running a single site.
Multi-source sites: Most enterprise websites use content from multiple sources (e.g. CMS and product database). Previewing within a CMS typically means only changing content originating from that source.
Visual editing services
Other tools offer visual editing capabilities, regardless of where your content lives. The two leading examples for enterprise sites are Stackbit and Builder, though there are more appearing on the scene as this capability evolves.
Evaluating visual editors for enterprise
Aside from the typical factors used when purchasing enterprise software (e.g. cost, availability, support, etc.), here are some considerations when looking into visual editing:
Lock-in: Typically, it’s difficult to avoid vendor lock-in at the enterprise level. However, visual editing is one area where it’s unnecessary to get locked in. Working with an editor should be a process that works alongside your code and should be easy to walk away from if your needs change.
Content storage: Aside from specific editing settings, a visual editor shouldn’t force you to access content through its system, but should be focused on editing. If it’s optional and works for you, that’s great. But if it’s caching content from other sources, it’s another point of potential failure for your website and should be considered thoughtfully.
Code injection: Visual editing is about editing and (unless desired) should play no role in your production website. Editing is to serve editors, while your production site is to serve your users. You should not be required to run code from an editing service in production.
Flexibility: Cool features can be flashy and tempting. But features change and evolve over time. Delivering a great experience to your editors is about the flexibility to get the editing application to work with your specific needs. The more opinionated a visual editor’s features, the more likely it won’t be able to serve your unique site.
We're biased, but because of the points listed above, we believe Stackbit is a better fit for visually editing enterprise-grade websites.