Design website content

On this page, you can find information about the process of creating and designing website content using various approaches:

• Create content in website channel applications
• Design content for a website
• Design content using templates
• Design content using Page Builder

Website channel applications allow marketers to create and manage page content they want to display on the website. A hierarchical structure called the content tree represents website content structure in a website channel application.

Not every item in the content tree necessarily needs to represent an actual page on the website. From a presentation perspective, we recognize three types of content stored in the content tree hierarchy:

Create content in website channel applications

Editors can populate the website content tree with the content stored in the Content hub. They can also create one-off channel-specific content that serves only a single purpose, e.g., the website page’s URL, or highly personalized content defined by the presentation. Alternatively, editors can also create reusable content through website channel applications and store it in the Content hub.

From a content-creation perspective, editors can create three types of content in website channel applications.

The following diagram shows the options for adding content in website channel application.

When deciding how page content gets stored in Xperience, you have two options: structured pages and Page Builder . The following table gives an overview of both approaches.

Structured pages

Editors create structured pages without the need to focus on their layout. From a developer’s perspective, structured pages are strongly typed and stored in dedicated database tables per content type. Developers can easily retrieve this data via the API and display it on the live site application according to project requirements. Alternatively, developers can retrieve and display the content in various channels, such as mobile applications or third-party services.

Structured pages can be formatted using the following approaches:

• Programmatically per page type by assigning a dedicated view file – see Set up content tree-based routing.
• By editors using page templates assignable per page – see Page templates for Page Builder.
• By editors using widgets that contain a selector functionality that editors use to pick the intended content item from the content tree. Existing selectors allow editors to select any item from the content tree, so when creating the content storage section for reusable content, make the content items easy to find and navigate. You can also consider customization to the Page selector and restrict its use to a specific content type.

Page Builder content

Page Builder is a user-friendly interface where non-technical users manage the content and layout of pages using configurable components.

Editors work with Page Builder on the Page tab in website channel applications. They can build entire pages (or their sections), experiment with different layouts and page designs, and immediately see the results. Equipped with widgets and sections, editors can lay out content without asking developers for help whenever they want to build a new page or adjust the design of an existing page.

Developers prepare Page Builder components based on project requirements.

Page Builder was not designed to create entire websites. The content that editors add to the widget is stored per widget instance. This makes the content difficult to work with for developers. Also, it is harder to reuse such content, which can lead to content duplication and content governance nightmares.

Keep the following points in mind when considering the use of Page Builder:

• Most website pages do not require frequent design or layout changes. For such pages, defining only the content in Xperience and handling the content presentation in code is more convenient.
• Page Builder has been designed for content editors and marketers as they need to be able to alter the layout of some content. However, they don’t need to adjust the layout of all content across the entire site.
• The risk of human error causing an unintended formatting or layout issue (due to incorrect widget configuration, misclicks, etc.) increases with the number of Page Builder-enabled pages.

When to use Page Builder to store data?

• You need WYSIWYG-style editing for specific pages.
• To maintain one-off, quickly degrading content that often needs adjusting.
• You don’t need to use content in multiple places (except for widgets that allow for presenting structured content; see below).
• To leverage content personalization and help website visitors on their customer journey.

Combining Page Builder and structured content

Page Builder and structured content are not mutually exclusive. You can combine Page Builder with structured content to leverage the full potential of both approaches. When you define your content model, consider situations in which you can store the data in a structured format and use Page Builder widgets or sections to present this content. Your widgets and sections can contain properties that allow editors to add design information (size, colors, and other content behavior). Even further, some content types, e.g., Articles listing pages, bring editors more possibilities if you combine Page Builder and structured content.

In general, your editors will benefit when you combine both approaches:

• Use Page Builder for formatting structured content
• Add Page Builder editable areas to page templates that display structured data to help with content personalization.

The following diagram shows the benefit of storing data separately from their presentation. From a user perspective, editors can create their data once and reuse it when needed.

• News (content type).
• The editor creates a new page using the News page type and selects the page template they want to use. The News page type has the URL feature enabled to generate the page’s URL and make it accessible to website visitors.
• Data input via the Content tab is stored in the “News” page type, and data presentation (layout and styling) is handled via the page template.
• The Teaser image field in the News page type references a file stored in the Content hub; it doesn’t keep the file itself.
• Landing page (content type)
• The editor creates a new page using the Landing page page type and selects a page template.
• The Landing page page type has Page Builder enabled.
• Using the Featured article widget, the editor displays some data stored in the Article: the Title, Teaser image, and Publication date.
• The widget references the selected news using its GUID. If the widget has any properties that set design information for the displayed data, their configuration applies separately for each widget.
• The editor also adds a Speaker widget that displays some of the data from the Author content type stored in the Content hub.
• The widget references the selected Author using its GUID. Data about the widgets’ configuration on the Landing page is stored in the DocumentPageBuilderWidgets database field in JSON format.

Design content for a website

You can design and present content using the following Xperience features (and their combinations):

• Predefined content templates (structured content)
  • Define a layout for content based on the content types.
  • Can be bound only to specific content types (e.g., layouts specifically for articles or blog posts, testimonials, etc.).
  • Either assigned automatically or selectable by editors when creating pages.
  • Created and managed by the developers.
• Page Builder
  • Enables editors to adjust the layout of entire pages or specific sections dynamically.
  • Often combined with predefined templates to allow editors to further customize options for displayed content.
  • Created and enabled by developers but maintained by editors.

Depending on your projects’s implementation, content editors can have different options to create pages and manage their content. The most common workflows are:

• Editors use predefined templates to present structured content. Editors have less control over the final appearance of the content they produce. Instead, the page’s overall layout is determined using MVC view files assigned to each content type. This approach ensures that all pages of a specific type (e.g., articles) use a layout from a predefined set of designs.
• Editors modify the page content and its layout using Page Builder and provided components – widgets, sections, or Page Builder templates. This approach allows you to combine structured and unstructured content using dedicated Page Builder components.
  • For example, using widgets that select a collection of Article pages (structured content) and enable additional formatting options such as a custom Call to action widget, the number of articles displayed per line, or personalized content, such as featuring different articles based on the visitor type (unstructured, Page Builder-specific content).

Design content using templates

Templates can combine means to display structured content with areas editable by Page Builder.

Xperience recognizes two types of templates:

1. Page type templates
   • A page type can define a static template for each page without options for editors to adjust it.
     • Use this type of template if you need to enforce a unified look and feel for all pages of a particular type (e.g., blog posts), without giving the editors additional freedom of customization.
   • These templates do not require the Page Builder, which can simplify its production workflow – editors only fill in the necessary fields with their content, and the page is ready to go live. The type of the created page predetermines its design and layout.
   • To learn more about how to set up these types of templates see Set up content tree-based routing.
2. Page Builder templates
   • Page Builder templates allow content editors to choose from predefined page layouts when creating new pages.
   • Editors can use page templates to present structured content, Page Builder content, or their combination.
   • Developers prepare the templates and assign them to specific page types.
   • Each content type can have multiple default page templates to display content. Editors pick the most suitable configuration when they create a page. They can also save their custom template configurations into page Presets and use these presets for creating new pages.
   • To learn more about how to set up these types of templates see Page templates for Page Builder.

Both template types may optionally include Page Builder sections to provide editors with further customization options using available Page Builder components. This type of content composition is widespread in many Xperience projects.

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.

Page Builder content storage

All content added directly to a Page Builder widget is stored in a single database field (CMS_ContentItemCommonData → ContentItemCommonDataPageBuilderWidgets), 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

You’ve learned about the different options for designing Xperience pages. On the General content modeling recommendations page, you’ll learn about overall content considerations and universal tips on website functionality that you might consider when planning your next project.