Module: Content modeling guide
9 of 17 Pages
Design content using Page Builder
Page Builder allows content editors to design parts or whole pages wherever developers enable it (by defining editable areas). Editors can use two types of components to format content using Page Builder: sections and widgets.
Sections specify the visual layout for widgets. They represent reusable pieces of markup that can store an arbitrary number of widget zones – areas where content editors place widgets.
Widgets are reusable components that content editors and non-technical users can quickly work with. Widgets give users more power and flexibility when adjusting page content and basic editing of text and images. By working with widgets, users decide which components and where they are placed on the page. Editors can also use widgets to format structured data.
Developers can prepare widgets to handle content in three ways:
- Widgets that present structured content
- Widgets that store and design the content at the same time
- Widgets that combine both inline editing and structured content
Widgets that present structured content
Editors add these widgets into appropriate Page Builder sections and select the content to display. Xperience can store the content itself in one of the following locations:
As content items in the Content hub. The widget serves only as a design container for the content stored in the Content hub. For example, a Promotion widget displays data stored in the Promotion content type:
Elsewhere in Xperience website channel application. The widgets serve only as design containers for the content stored (and presented) elsewhere. For example, a widget that displays only several properties of the “Article” content type:
What does working with the reusable content look like?
For example, imagine the editors are building a campaign landing page.
The page will contain a Hero element. From the design perspective, editors should select only the Hero banner content type from the Content hub to populate a Banner widget. From the editor’s perspective, adding reusable content to the page and displaying the structured data might look like the following:
When modeling the content storage, always consider the editor’s workflow. Help them understand what type of content they’re supposed to select. For example, you can use instructions next to the selectors in the widget properties and your project documentation to ensure editors receive enough guidance.
Similarly, ensure that editors will not unintentionally break the page experience by selecting content that doesn’t belong.
- Developers can restrict the selection to pages of specific page types that fulfill required conditions (e.g., have the URL feature enabled). See samples of the Xperience selectors in Reference - Admin UI form components.
- Similarly, developers define which type editors select into the widget properties, such as the Benefits widget in the Kbank demo site.
Widgets that store and design the content at the same time
With these single-purpose content widgets, editors can manage the content in a WYSIWYG manner using inline editors, use the widget’s properties and add content through the widget’s configuration dialog, or combine both. The out-of-the-box Rich text widget is an example of a widget with advanced text styling capabilities.
The Banner widget on the Dancing Goat sample site shows both inline editors and widget configuration properties where all the input data are stored within one database field.
Similarly, the Page heading widget on Kbank demo site allows editors to add content and style it using only widget configuration properties.
Widgets that combine both inline editing and structured content
Mixed-content widgets allow editors to reuse structured content, e.g., by providing a selector to pick content from the content tree. At the same time, editors can use the widget’s editable properties to overwrite some of the content pulled from the selected page or create brand-new content. Editors can also provide additional information or behavior to their content, such as ensuring that hyperlinks to external websites open in a new tab.
We recommend limiting using mixed-content widgets only to specific pages (sections), as content stored in these widgets can be more difficult to reuse in other channels.
Page Builder content storage
All content added directly to a Page Builder widget is stored in a single database field (CMS_ContentItemCommonData → ContentItemCommonDataVisualBuilderWidgets), making it difficult to reuse. On the other hand, widgets that add design to structured content store only a reference to the linked content (using the GUID value).
Sometimes, projects require WYSIWYG editing through widgets that also store content. While specifying the project requirements, we recommend considering the implications of this design decision. Storing content directly in widgets significantly impacts content reusability or the project’s upgradeability.
Recommendations – Page Builder
Combine structured content and widgets
To make the website’s content both reusable and future-proof, we recommend storing the content of the widgets using the structured content format. Developers should prepare widget properties that allow editors to format content using WYSIWYG editing capabilities.
Based on the project requirements, the structured content of widgets can be stored in a dedicated section in the content tree or directly in a hierarchy under the page as child items.
Limit using widgets for single-purpose content
Xperience stores the content input directly into widgets within one database field for the whole page. We recommend storing content in widgets only when the content is not going (or doesn’t have the potential) to be reused on the website. This content can work on one-off pages, such as campaign landing pages.
Create sections with designing capabilities
We recommend creating sections with properties to let editors define how the content they add via widgets displays on the website. Some examples of section properties are a field for a URL parameter (Anchor tag) for deep linking, a property to define the number of columns within the section, a property to adjust the margin or padding of widgets, and changing the color of the section, and similar properties.
Set restrictions on editable areas
Use editable area restrictions to ensure editors can add only desired widgets or sections to specific areas. This ensures page designs do not break (e.g., in different browsers) and creates boundaries for data predictability (when considering future upgrades). Find out more in Create pages with editable areas.
Create custom widgets to add markup to pages
Typically, in the early stages of a live project, editors might need to add custom HTML markup or include scripts to embed 3rd party applications. Project owners sometimes need to remember this or similar scenarios when detailing project requirements, so ensure your project gets this low-hanging fruit to make editors happy.
We recommend creating custom widgets that allow editors to add scripts or HTML markup in the page’s head or body. For example, editors might use an Anchor widget to enable linking to a section of the page or a Script widget to add JavaScript that runs a custom-built mortgage calculator.
Suppose editors will reuse these scripts or markup on different pages. In that case, developers can prepare a custom Script content type with a custom widget. Content editors then add the widget to the appropriate pages, reusing the scripts or markup.
Add instructions to selectors in Page Builder components
When building widgets that display structured content, provide editors with clear instructions describing what content items they should select. You can use the ExplanationText widget property and provide contextual information specific to the selected widget. Providing additional guidance ensures that editors don’t break the visual experience of the website by mistake. Also, include clear instructions about how editors should use every widget on the website in your project documentation.