Design website content

About this guide

Content tree hierarchy and page structure in website channels

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

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 and organize website channel content

Xperience allows you to treat website channels as first-class citizens within your digital ecosystem. This means editors can create, manage, and design website content directly within the website channel application and they don’t need to switch between different contexts during their daily work. Editors can add or reuse content from the Content hub, craft channel-specific structured content, or create and adjust content directly within the webpage using Page Builder. Or, they can approach the website channels as one of the presentation layers that is on the same level as other digital marketing channels, and manage all their reusable content from the Content hub.

Content within a website channel can be navigable (forming part of the site’s structure and URL hierarchy) or non-navigable.

Developers can create content templates to display structured data dynamically. This ensures that the same content looks consistent across the website, but limits editorial control over design and layout. Alternatively, developers can design page templates that include Page Builder zones. Page templates provide editors with a flexible editing experience to manage page layouts, expose custom-built page template properties, and contain Page Builder widgets and sections. The Page Builder is a user-friendly interface, well-suited for frequently updated or campaign-focused pages.

Before we dive into details you’ll use in designing your content strategy, remember:

• Data in the Content hub is always reusable and can support multi-channel delivery.
• Data stored in a structured format within the website channel can be reused across the website and email channels where needed.
• Content added directly within widgets in Page Builder is page-specific and not reusable across other pages or channels.

Design content for a website flow

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

• Predefined content templates
  • Displays only structured content (that is stored through the page or )
  • 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.
  • We recommend using content templates for content that needs to be tightly controlled.
• Page Templates
  • Need to have Page Builder enabled, but don’t need to contain widgets or sections.
  • 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.
  • This approach is suitable for most website pages.

Depending on your project’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. Page template properties give editors limited 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, event, or product pages) 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 content type can define a static display template for each page with or without options for editors to adjust it. We recommend using 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.
     Static content layout doesn’t need to span over the whole page. We recommend that even for pages, like listing, product, or article pages, developers enable editors to work with Page Builder. This will allow editors, for example, to tailor the “unified content piece” with personalized messaging. See article pages in the Kbank demo site for reference.
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 a combination of both, as described below.
   • Developers prepare the templates and assign them to webpage content types.
   • Each content type can have multiple default page templates to display content. When editors create a new page, they pick the most suitable template configuration. They can also save their custom template configurations into page Presets and use these presets for creating new pages.

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 is a user-friendly interface where non-technical users manage the content and layout of pages using configurable components.

Editors work with Page Builder in website channels. 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.

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 are placed where on the page.

Behind the scenes: How Page Builder works

Developers prepare Page Builder components based on project requirements.

Page Builder was not designed to create content of entire websites. The content that editors add to a widget is stored per widget instance. This makes the content difficult to work with for developers if editors want to reuse content on a different page. Instead of reusing, editors will copy data into a new item, such as a widget, which leads to content duplication and content governance nightmares. If you need to frequently reuse a piece of content, such as an FAQ question, consider storing this content in the Content hub and give editors a widget to display it.

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 their pages. However, they don’t need to adjust the layout of all content across the entire site.
• The risk of human error causing unintended formatting or layout issues (due to incorrect widget configuration, misclicks, etc.) increases with the number of Page Builder-enabled pages.

Understand how Page Builder stores content

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.

See the different types of Page Builder widgets

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 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 webpage 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 is 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.

Drive displaying data using taxonomy

Design dedicated widgets to consume taxonomy terms as input and dynamically display content based on those terms to support taxonomy-driven content. For example, a content listing widget should allow editors to select a taxonomy tag or smart folder as a filter. The widget then queries and displays only the matching items. It should also offer options to exclude certain content, such as by listing available tags or applying an “exclude from display” tag in article itself, to give editors more control over the final output. Ideally, the widget will allow editors to wrap the listed content with additional content (e.g., text or visuals) to ensure that content remains reusable and manageable directly from the Page Builder.

Recommendations – Page Builder

What’s next?

You’ve learned about the different components editors can use to design Xperience pages. On the next page, you’ll learn about different approaches to storing the data using two different content models - the atomic content model that supports high-content reusability. Then, we’ll discuss the page-based content model.