We are ZYRES, a digital agency from the heart of Frankfurt, Germany and a proud Strapi Solution Partner.
As a customer and end-user centric firm our main focus always lies within the usability of our solutions. A focus to be at the core of our blog today; our approach to creating a slime-lined page builder with Strapi for editors without requiring any technical competencies and long content creation horizons.
To begin with, let us tell you a little bit about ourselves; us ZYRies combine technological innovation with professional know-how to develop customised e-commerce and software solutions. In our 23 years of existence, we evolved as specialists in the field of headless CMS and Shop systems, customised software solutions like return-portals or complex product-configurators, prototyping, intuitive customer experience designs and themes, agile project management as well as managed hosting and cloud services. We love technology and state-of-the art approaches, hence we favour the MACH-Architecture, standing for Microservices, API’s, Cloud native and Headless strategies. We do so by combining a modern tech-stack which includes GraphQL, REST, GO, Kubernetes, Serverless, Next.js, Node.js, PostgreSQL, MongoDB, TypeScript, Material UI and Tailwind.
Having tried several approaches, we found out that, in all our projects, what works best for the editor teams is having (if possible) a single “content/pages” collection, even for pages that may seem better fit for a separate collection. Meaning that editors would like to deal with only one interface in terms of “Where can I create my content?”. Obviously, sometimes you can't really avoid having multiple content creation collections, but it seems to confuse the editors. Hence, we created the STRAPI-ZYRES Page Builder which in the end is a concept of how to organize the editor experience for best leveraging the platform with minimum frustration.
This means that the ZYRES-Strapi Page Builder must be very flexible, whilst staying understandable and manageable. So before diving into its details, we need to remark on some crucial concepts, which we heavily use. These are “basic elements are components”, “content components” and “default values.”
All basic elements are a component, which includes all the fields required to make the element completely functional. Secondly, we avoid having diferent variants of a component. For example, we will try to have only one type of “button”, only one type of “image”, only one type of “link”, and so on. Obviously, this makes each component more complex, but it helps the editors not having to think about the possible variations between (e.g.) one or another image type. Talking specifically about Images, the image component would always include fields like a MOBILE-view alternative, an ALT field, and a TITLE field, even if sometimes the editor may choose not to use them.
All other components are made, as much as possible, via nesting, by re-using the mentioned basic elements and keeping specifics to a minimum. Keeping an organized classification in your components list is key. Then, for more complex needs, we will abstract those into a collection of partial contents, and use the Relations feature of Strapi to make it work. In the image, a relation to a Content-Type “insert” is added/chosen. Strapi ofers you a lot of power here, with all kinds of relations possibly needed (one-to-one, one-to-many, etc).
Default values are a key aspect you want to consider carefully. Any field that is not marked as required, or has no default value, can cause unpredictable efects in the frontend. So either agree for every field/component how they will behave if not properly filled, or set them as required with default predefined values.
The immediately visible structure is kept clean and always consists of 3 main parts, being the" heading area", the "dynamic zone" and the "bottom":
A “heading” area that comprises the most important page-specific settings only. Examples of fields here would include, apart from the obvious “Page name”, colour choices/themes, or page behaviour selectors.
A “Dynamic zone” as the main body: this is the core zone, it contains the choice of all the components that you will have developed before, for the editor to add. Once again, here we have found that a single Dynamic Zone is less confusing for editors than several.
As soon as the components are developed and made available to the editors, they can add whatever content- related component they want here. Obviously, you wouldn't want the basic elements (button, image...) as a selective, but what we call “Sections” → components that include those basic elements forming a meaningful “slice” of content.
A “bottom” area comprises all other needed page-specific settings and elements which add value to the page, but which are neither needed in the “header” area nor are related to content creation. Examples of components/fields here would include the SEO component which you can implement through Strapi'sown SEO plugin .
Having icons set in the Section components helps editors locate the wanted component quicker.
The order in which the components are shown is also relevant, try to make the most used appear first.
As you will have noticed, all components have a technical numbering preceding their names (i.e. “S17”). This is helpful in two ways. One, it also eases component location but more importantly, it is a reference you can use throughout your project, with your developing team, in documentation, and in any project conversations. The name or the way of referencing it may change, but the technical number remains. You could even version them, for example, having an S17v1-building and an S17v2-building
From our experience we can say that you will need to have a configurable WYSIWYG editor in your project. We had no project where this was not requested. Strapi has its own editor which was just released for general availability. Alternatively, you can or choose from one of the available in the Marketplace – just go to Strapi's Plugins Marketplace.
Another functionality most likely to be requested is some kind of preview, especially when the project users have previously worked with some other CMS entailing such a function. Again, the Strapi Marketplace ofers some.
Whenever you choose a plugin, and provided you have choices, the advice would be to go for a plugin that, apart from providing the needed functionality, is active in maintenance and support. It is a good idea to visit the plugin's repository pages and check.
Examples of other plugins that usually fit most projects would be a Menu/Navigation plugin and an image optimization one (for performance and modern formats), but there is more and more choice in the ever-growing Marketplace. Make sure you visit it.
The view of each of the components is really important – it is not the same to fill in a mess of fields as something with a decently showing structure, that has placeholder values and field descriptions.
Having dived into the technical set-up of the ZYRES-STRAPI Page Builder let’s have a look at a typical user journey from the perspective of a content creator, an editor wanting to create a new landing page.
After having selected the function “Create new entry”. This is the complete interface visible to the editor:
Now the most basic page-settings must be set. In our example, this entails: 1. Setting up the page Name. This name is only used for internal references. 2. Selecting between a black or white header content theme. 3. Selecting between a white or transparent (blurry) header background colour.
Now the editor may enter the page-relevant SEO Data. This is also done in one component, including: 1. Setting a Meta Title. This is the ofcial page name that would appear on a Google Search. 2. Setting a Meta Description. To be shown below the Meta title a Search Engie. 3. Including a Meta Image. This may be an image found on the Page itself or could be a specifically designed image 4. Social media-specific meta details can be entered for each platform separately. Including the same information from Numbers 1 -3. 5. Enter the keywords and Meta Robots. 6. The editor can enter structured data of the page. 7. Lastly, a Meta viewport and a canonical URL can be set.
For most editors, it makes sense to fill this component at the end of content creation. However, the possibility of doing it at the beginning exists.
Within the same component, the editor can select between three set page theme colours, either beige, brown, or terracotta. These colours are given to specific elements of the page, including the footer, the contact request button, and parts of the header. Within a few minutes, the full “Infrastructure” Part of the Page is set and the real content creation can be started.
The editor can now start creating the body of the page, which is made up of a combination of selected components. For the use of our example let's select 3 Components to create the full body of the page. Let's say the editor wants to start of with a Hero Image. The process is the following:
As a second component for the page body, the editor may choose an image with a text module. To have a filled component let's have a look at the steps to do so: 1. Select the Component named “S7ImagewithText” 2. Again, give the module a title if you want it to have one in the frontend 3. Via a dropdown you may choose whether the text stands on the right-hand or the left-hand side 4. Now you can enter a subtitle if you like 5. Select an Image and mobile Image as well as enter the Alt Text/ Image information if wished 6. In this component you have the option to use a rich-text WYSIWYG editor to create your content. From selecting diferent font sizes, over listing options to underlining specific words, everything is possible. You could even add another Image here if you wanted to. 7. Again you have the option to add a button to this component, giving you the same possibilities as already mentioned above.
As a last component let's create a lead-generating Contact Form. To complete this module the editor has to do the following: 1. Select the Component “S55-form” from the section “add a component” 2. Give the Form a Name to be shown in the frontend 3. Enter the email address that you want the leads to be sent to 4. Now you have the option to create as many fields as you like. An example could be the Name and end-user. For that, you may click on the “add entry button” 5. Now you may enter the displayed name of the field for the frontend, being Name 6. Via a dropdown menu you can select the input type for that specific field. In our case that would be “text” 7. In the field “placeholder” you can enter an example answer for the end-user. For instance “Kennedy” 8. Now you can customize the button Name. for instance “Send”. 9. Add an image and your form is ready to go.
And that’s it. The Content has been created. Now the editor can view his content with a preview function, to evaluate his work from the perspective of an end-user in the frontend. The preview is instantly available after Saving the page.
Thanks for making it all the way down here! You spending your valuable time is much appreciated. We hope that you, either as a developer or Content Creation – related individual have been able gain value adding insights from our ZYRES-STRAPI Page Builder experience and solution. Even if you can only use parts of the information we provided, we recognize it as a success! If you have any questions, remarks or interest in a similar solution (similar in the sense that everything can be easily customized) drop us a message, connect or give us a call at any given moment!
Ignacio is Project Manager & Head of Strapi Projects at Zyres.