Enhancing Content Creation: Visual Editing with Sanity and Storyblok for Next.js

As experts in headless CMS (hCMS) and performance at FocusReactive, we work with many products from this segment and closely monitor their development. But most often we choose those CMS that have integration with such a framework as Next.js. While hCMS makes it possible to separate content and work with it independently, Next.js helps to achieve maximum performance using the built-in mechanisms and capabilities of the framework.

Sounds great, right?

If we talk specifically, then two players can be distinguished here: Sanity and Storyblok.

Another reason to go with either Sanity or Storyblok is that they offer visual editing functionality. Let’s dive into it and take a look at some of the main features they offer.

What is Visual Editing?

Visual editing is a user-friendly method of creating and modifying digital content using graphical interfaces. It allows users, regardless of technical expertise, to directly interact with and manipulate content. Unlike traditional text-based editing, visual editing provides a real-time preview of how the content will appear on the page, increasing efficiency and collaboration among engineering and content teams.

User Interface and Navigation

Both Storyblok and Sanity have quite similar UI regarding visual editing: you will find the URL of the page, a preview of the page, and a list of blocks used by the page. It is important because this is one step towards standardization, even though non-official.

The visual editors of both platforms allow you to click on any component and open it in the content column on the right side of the page. Here is how it looks:

Storyblok

Sanity

This feature saves time and speeds up the editing experience, especially when dealing with complex components that consist of multiple nested components.

Both platforms will open top-level fields as well as nested child components. Depth doesn’t matter.

Moreover, in the case of Storyblok you will see the nesting hierarchy aka breadcrumbs. They are clickable, which gives you additional convenience when editing/navigating between nested components. Sanity doesn’t have that.

However, there are a couple of differences between the two platforms in the scope of this feature.

Let’s say you have a link and you want to go to another page by clicking it. It won’t work, because instead of going to another page, you will open the clicked component in the content column.

Sanity offers an "edit" toggler that turns it off and allows you to interact with the page.

This feature is particularly useful when you want to preview and test the final result, including clicking links.

Unfortunately, Storyblok does not have this feature. But, at least, you can do something. Specifically, you can prevent the iframe events, like clicking on a link. To configure that you can use preventClicks property of StoryblokBridge instance (check out official docs). But this is more of a technical change, that should be done in code, rather than in UI. So the content team can’t use it independently.

This can be frustrating in certain cases, especially when you develop a new functionality related to link behavior.

Real-Time Preview and Instant Feedback

Both Storyblok and Sanity provide instant preview feedback when changing content. This means that any modifications made to components are reflected in real-time without any delay. This feature allows content creators to see exactly how their changes will affect the final appearance of the page, facilitating quick iterations and adjustments.

The importance of that is elegantly described in Sanity's blog as What you see is what you edit. Both hCMS play well in this crucial field.

Let's see how it looks:

Storyblok

Sanity

They are both fast and convenient to use.

But what about applied changes persistence?

Sanity saves all changes with draft status, so if you reload the page, changes will be there. This could be cool when you working on the content and don't want to lose any changes, but might be annoying when doing some development/debugging work.

Storyblok, in turn, shows all the applied changes but doesn’t save them until you press "save" button.

Worth to mention tho, is that Sanity gives you the ability to edit any separate component, eg footer and header, and see instant feedback. Same behavior as all the other fields.

In case of Storyblok, the mechanism is a bit different. Let’s consider adding a reusable header component which you will share among the pages. You create a "story" (collection of fields) with header info and add a story field to the page. Then you should select one of the existing header stories as the value. And the last part is adding the header implementation in the code to make it work for all pages (eg use in layout, that is shared between pages).

This is not easy and not straightforward. This approach limits your preview and live editing experience for shared components, which is not what you want.

Drag-and-drop and Copying Functionality

Drag-and-drop functionality is a must-have for any visual editor, and both Storyblok and Sanity offer this feature out of the box. It allows users to easily change the composition of a component and experiment with different layouts and designs. This intuitive and handy way of editing enhances the user experience and speeds up the content creation process.

Storyblok

Sanity

However, the efficiency of content creation is further elevated through the copying capabilities.

Storyblok has a convenient mechanism to copy and paste components through a clipboard. It allows copy-paste components across projects/pages/nested objects. Meaning that you can copy a component and paste it to another page and even to another project. On the other hand, Sanity opts for a more targeted approach, offering duplication functionality. This means you could create a component copy that will be added right next to the original component.

Let’s see the difference:

Storyblok

Sanity

In my opinion, Storyblok has a more convenient way of doing it. Because you can choose what components to copy (yes, you can select multiple components and copy them the same way you copy a single one) and where to paste it.

Sanity is limited to copying only within the array and one component at a time, which can cause some inconvenience in certain cases.

Preview for Different Viewports

Another essential feature of visual editing tools is the ability to preview content for different viewports. For now, Sanity offers two options: desktop and mobile. While this provides some flexibility, it is limited compared to Storyblok. Storyblok allows users to preview content in mobile, tablet, and desktop viewports. Additionally, Storyblok enables users to preview content at any custom width, similar to widening the browser window. This level of customization ensures that content creators can accurately preview content across various devices and screen sizes.

Storyblok

Sanity

Collaboration and Communication

Collaboration is key in any content creation process, and Sanity takes it a step further. In Sanity, users can work alongside teammates without any worries about overwriting, locking each other out, or applying unexpected edits. Fields are independent, so multiple users can edit different parts of the same page without conflicts. Even more, Sanity shows who is editing a document in real-time and it works with live preview as well. (Wow!)

A common, but must-have feature, that is integrated in Sanity is document history. It keeps track of all the changes and you can always restore the particular version of any content.

Storyblok offers some of these features as well. It supports the same history feature, with the ability to restore specific page versions. However multiple users can’t edit the same page at the same time, because conflicts will occur. This is a significant limitation for the content team.

One more great thing about both platforms is that you can leave comments on any component fields, tag team members, and ask questions or provide feedback directly within the editor. Tagged team members receive notifications, eliminating the need to switch between messaging platforms like Slack. This is nice because sometimes you don’t want to switch contexts and get distracted.

Components composition

Both Storyblok and Sanity empower content teams to create multiple pages from existing components. This flexibility allows for efficient content creation and promotes consistency across the website or application.

However, it's important to note that the more pages you have, the more complexity lies with the content team. Changing components for one page could potentially affect other pages.

Sanity has addressed this issue by providing a clear overview of which pages use the content and how changes will cascade. This feature allows us to inspect the results on pages before making any changes public.

Unfortunately, Storyblok does not offer this feature, which can be a drawback when working with a large project. This is what I'm really missing in Storyblok.

Implementation and set up

Implementation and Setup The implementation of Sanity's visual editing involves using a new web standard called Content source map and the @vercel/stega package for encoding and decoding page content. Other hCMS also adopt this approach for implementing visual editing.

Similarly, Storyblok has its own implementation, requiring the manual addition of special properties to each editable block by using the special helper function.

Both platforms use iframes in their implementation, making the setup steps quite similar. Here's a breakdown of the steps for each platform:

For Sanity:

1. Add presentationTool to the project.
2. Add an API route to manage draft/published documents.
3. Connect your frontend application to the Sanity Studio.

For a more detailed guide and analysis, you can refer to our article: A Deep Dive into Sanity's Visual Editing and Presentation Tool: The developer view.

For Storyblok:

1. Add an API route to manage draft/published pages.
2. Add a preview URL to Storyblok.
3. Configure tokens.

For additional guidance, follow the official docs.

In summary, the general process involves setting up a route to handle incoming requests and configuring the tools offered by either Sanity or Storyblok.

It's interesting to note that both products follow a similar approach. This not only validates the idea but also establishes a pattern, which is beneficial for developers and community users. Patterns are always a positive aspect!

Conclusion

For headless CMS, visual editing tools play a crucial role in simplifying content creation, developing new features, and testing the result.

Both Storyblok and Sanity offer powerful and intuitive visual editors that empower content and engineering teams. While Storyblok was the pioneer in providing a visual editing experience out of the box, Sanity has entered the scene with its own set of impressive features.

Although both visual editing tools are very similar, you can’t decide which CMS to pick based on only this set of features. A lot of aspects should be taken into consideration before making a final call: tech stack, size and experience of the team, budget, level of communication between teams, need for customization, how good documentation is, potential risks, and more.

Check out related articles, that might help you make a final decision:

• International and multilingual sites with StoryBlok and Next.js
• Project insides: How We Built a Complex Headless CMS Based on Custom Sanity Studio
• Best Headless CMS for NextJS in 2023
• How to Choose a Storyblok Partner

But, as always, the choice is dependent on your specific use case. You should understand your system and business deeply, to make the right decision.

If you have any questions, contact us, headless CMS experts, and we will help you to make this choice easier.