Where is my WYSIWYG page builder?

Frankly, there is no need for that because the team is doing surprisingly well and is almost always able to deliver results on time, be it a blog post or new product campaign. Thanks to their knowledge and right toolset, apart from a few exceptions, they don’t need any external help. One of the tools is their powerful CMS with a WYSIWYG (what you see is what you get) page builder. With this feature, they are not only able to adjust content styling and layout but also build completely new landing pages for their projects. And the best thing about it—everything can be done in-house and without any advanced knowledge of coding.

In this article, I’ll be using terms like WYSIWYG page builder or visual editor quite extensively. Please note, that I’ll always be referring to the tool that empowers users to create new page designs, work with the layout, and apply various styling to their content. It shouldn’t be mistaken with rich text editors allowing simple text formatting like section headings, bold font, and so on.

Why users like WYSIWYG

At Kontent.ai, we’ve been discussing WYSIWYG page builders quite extensively over the past few months. There is no surprise in that—a visual editor is a very common item listed in project requirements, people like it, and it is a feature offered by almost any major content management system. And since we are building a headless CMS, we had to ask ourselves: “Do we want or need that feature too?” At a certain point, we even had a working prototype, which looked very promising, and customers were excited about it.

Based on what I’ve written so far, you might be asking why we even had to think about it. It brings only good things, right? Well... unfortunately, it’s not that simple.

The use cases and benefits behind

When we first started evaluating whether to include WYSIWYG page builder in our headless solution, we had to find out what jobs or use cases are actually hiding behind this feature. We’ve spent countless hours discussing the issue with our partners and customers just to understand it better. So why do people love visual editors so much?

Generally speaking, from a customer’s point of view, non-technical people want to have the option to create or manage pages, including their layout, by themselves. Their experience is telling them that instead of calling a digital agency or development team to help them with every task, it’s often easier, faster, and cheaper to do it themselves. Some would even say that developers don’t speak their language and they are slow and expensive.

Regarding specific use cases, here is what we’ve discovered behind the request for WYSIWYG page builders:

• To create content and build pages while having visual and content context. That means users know WHERE exactly content goes, HOW it looks, and WHAT the surrounding content is.
• To edit or fix errors on the spot, i.e., directly on the web page (no need for searching for the content in the content inventory).
• To build custom pages, new layouts, and templates without developers and to speed up the whole process.

So far so good. Now, let’s take a look at what happens when you put WYSIWYG page builders to the challenge of large organizations and omnichannel projects.

Why you should be cautious with WYSIWYG

Let’s get back to Marcus and his team. Things have changed since we talked about them the last time—everything has been going well, the company has been growing and so has the marketing team. As the team grew bigger, Marcus started to notice that their current process and way of working might have its pitfalls, and it might be time for a change. 

Even though they have started with team synchronizations on a daily basis, Marcus can now see that there are a lot of inconsistencies in the team’s work. Every campaign, every piece of content and landing page has its own specific look and feel, depending on the team member that processed it. Since every marketing project is a one- or two-man show from design to implementation, the signature of a particular person is always present and differs from the rest. The company’s presentation just doesn’t feel like unified work anymore.

And there is one more thing. Because the company has grown and is now targeting larger and more demanding clients, the style of their communication, visuals, and graphics had to change too. Suddenly, when they compare their results to their new competition, it somehow feels immature and kind of inferior. It’s not bad, but it’s not great either. The truth is, Marcus and his team are missing field experts and specialized roles. The focus on having universal employees prevented them from excelling in individual areas.

The process of delivering awesome results

Mature organizations understand that creation of a new design or landing page is a complex activity with precisely defined and mutually dependent steps. And that’s why they want to have some governance in place—the process needs to be controlled and executed by specialists.

Every task involved in the creation process has different specifics and problems, and only experts are fully aware of all of them and are able to deliver consistent results at the highest level of quality. Content strategists define goals and personas, designers create the layout, content editors prepare the content, and so on.

With this kind of approach, everyone can focus on their work and aren’t distracted by assignments they are not good at. Writers don’t need to think whether the headline should be centered or floated to the left just like designers don’t need to come up with exact wording for a product description. Finally, developers or coders don’t have to deal with specifics of a given WYSIWYG builder, they just use their favorite technology and implement a clean, pixel-perfect, and responsive page based on the design provided. Everything clicks together and forms the perfect outcome.

Adding omnichannel to WYSIWYG only multiplies your problems

Fast forward in our story about Marcus and his team. After a while, they’ve realized digital marketing is not just about the web anymore. They found out that apart from the web and social networks, their customers are expecting them to interact through a mobile application, voice channels, and more. The content production changed. They had to start thinking about authoring differently because suddenly, they were creating content that was supposed to live on multiple platforms at the same time.

And that was the point they ran into multiple issues. Here we are getting back to our research again because, in regards to omnichannel and WYSIWYG page builders, we (just like Marcus and his team) have found out that:

• Content authoring in the context of one of the channels can lead to a content production bias (i.e., a focus on one particular channel) and has a negative impact on other channels. Let’s say you write the following sentence: “For more information, click the button below.” Now imagine how this is going to work with your mobile application where users don’t ‘click’ but ‘tap’ and the button is not below but on the right because the design is different.
• Visual content editing suppresses the production of metadata, which is the foundation for omnichannel delivery. For example, since Marcus decided to enable voice ordering for their customers, he needed to add several metadata fields like sound effect or voice and tone specification to every product. Since that data is ‘invisible’ to the website and WYSIWYG, we can only ask how they would get filled in by the content editors.
• Inline editing encourages content creators to focus on the visual presentation instead of the structure, semantics, and content itself, which are, again, basic elements of omnichannel content production. It’s, therefore, a distraction from content authoring. Imagine you’ve just spent 20 minutes editing your paragraph. You had to add some extra words because you wanted the text to be aligned with your image gallery, and you used some custom styling to emphasize certain words. Later on, you try to reuse that text for your newsletter just to find out that the text is too long and the styling doesn’t match your newsletter design at all.
• Implementing principles of content re-usability in the visual approach is rather difficult, as the content is usually stored in unstructured blobs, which are very difficult to use on other platforms.

So… what happens next?

Because omnichannel content production is more than relevant for most of us today and because of the arguments stated above, we have, in the end, decided not to continue with the WYSIWYG page builder prototype I mentioned at the beginning of this article.

At the same time, we realize the WYSIWYG style of editing has been around for quite a long time, and people still like it. It gives them a quick idea of how the content looks on the page. It gives them the power to move it around, add some components, change the visuals, and so on. That’s why we’ve been working really hard to come up with a solution that would help them to address the needs connected to WYSIWYG in an omnichannel way and make the transition process to the new content authoring style much smoother and easier.