I believe that Xperience by Kentico's Page Builder does a great job balancing several competing goals.

  • Feature and capability scope vs conceptual complexity
  • Great user experience vs ease of technical implementation
  • Productivity and flexibility for a marketer vs governance for a team

I also believe this balance isn't guaranteed!

Achieving it requires teams to understand how the Page Builder works, what problems are the proverbial nail to the Page Builder's hammer, and of course the challenges that stakeholders are looking to solve.

Kentico MVP, Elmar Höfinghoff, has the knowledge, experience, and desire to share that makes him the perfect guest for an Expert Chat to guide us through his tips for Page Builder implementations.

Expert chat

Solve the marketer's challenges

Elmar starts off the discussion with a point that's easy to forget when we become too focused on the technology or implementation details.

The first thing is you do not have to build everything with the Page Builder components, it's always a mix of static content and modular components. It depends on on your client and the project as to what fits best for for them to work with [...]

I would recommend the first thing everyone should consider is to go deeper into this and think about how could this client this marketing team work best with this components and and dynamic controls [...]

The first step is to speak with your clients and decide in which way you want to do this, how much flexibility should be allowed for the marketing team. That's the base of the architecture and the design for the components.

You heard it from Elmar - client communication first, implementation second!

He also sees the Page Builder not as a solution to convert web page designs and HTML cut-up to Xperience's ASP.NET Core Razor templates, but as a tool to solve problems for people.

You're not designing the Page Builder just to suit the layout of the page or the content that you're trying to display. Instead you're starting with the marketer, what their preferences are, the amount of control they want to have, what their goals are with the website that they're going to be in charge of.

You start from their perspective first so that it is at the end it should fit for the customer and not for me.

As a developer, project manager, or sales engineer, we understand the what of the Page Builder which is key, but it's just as important to understand the why.

A good implementation

Elmar's second area of focus is on the Page Builder implementation - specifically, don't make it too complex (developers have a habit of looking like they love complexity 😅).

When it comes to the design of the individual components it's very important to have them intuitive and well documented.

So, do not do it too complex, do not do it too difficult to understand. Think about keeping it in small parts so that it is modular and reusable.

[...] you know you have the possibility to add some explanation text to all of your properties in the widget dialogues and so on so that the marketer does not have to go to external documentation - it's all there and keeps it intuitive.

I do every time I create a component and I get very good feedback on this because [marketers] can just work with it.

We provide this same guidance in our documentation.

As the Page Builder is preferably used to present the information rather than store it, use Label and Explanation text widget and section properties to help editors understand the data their content needs and what will happen once displayed in the dedicated channel.

It's so easy as an implementation team to forget about this affordances for marketers because we know the implementation details. It's obvious use us how the Label field is used or why there's only 3 options in the Theme dropdown for a Widget. Marketers don't have that privilege of writing the code or even being able to look at and understand it.

We can help marketers have a great experience with the Page Builder by making sure they feel confident when using it. Give them a clear understanding of the options available.

What do marketers struggle with?

After laying all this groundwork we transition to a deeper topic - what do marketers still struggle with when using the Page Builder, even if the solution is well designed?

One of the worst things in this context is that you have dependencies on the components. So, for example a Widget which shows an article teaser that works only in a Section for article teasers and this is only working in a Page Template for article overview pages.

The problem is that the developers did not think about restricting the use of those components only to this context area. So, they are available everywhere and then a marketer adds such a component in another context and he does not understand why this is not working.

This is one of the big tasks for developers when it comes to design in a modular architecture of components. Sometimes it's because they get HTML from another agency or a front end agency and they try to just copy and paste the markup into components.

Or, they do not design it in a way that [the components] are working independently of each other.

[...] use the the systems to restrict the Widgets which are used in

the Sections to those which are working in this context [...] so that the marketers are not lost.

Again, Elmar points out we ideally need to keep components modular and independent from each other and as a backup use the Page Builder's Editable Area and Section Widget restrictions to limit what can be used where.

I like to use the phrase "falling into the pit of success". If a marketer isn't quite sure what is allowed the developer has already set things up to guide them to positive outcomes that result in accessible experiences for their customers.

Wrapping up

Elmar really has a wealth of knowledge about the Page Builder and what a great implementation with it looks like.

Over the course of our chat, which has another 20 minutes of conversation beyond what I covered above, we touch on when to use Page Templates, should content be authored in a Widget or reused from the Content hub, and how important it might be for web designers to understand how Xperience's Page Builder works.

Are there Page Builder techniques or tips that have been successful for you and your teams? Or, as a non-technical user of Xperience what kinds of Page Builder experiences have you found you love working with?

Let me know in the discussion for this post!