Design website content

This page is a part of the Content modeling guide which you should follow sequentially from beginning to end.

Website channel applications allows 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.

Editors can populate the website content tree with the content stored in the Content hub. They can also create one-off channel-specific content, which only serves a single purpose, for example, the website menu, website page’s URL, or highly personalized content defined by the presentation. Or, they can create reusable content through website channel applications and store it in the Content hub.

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

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

Content tree in website channel applications

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:

Type of content

Content from the presentation perspective

Content types for pages accessible under a URL

  • Website pages are accessible under specific URLs (e.g., mysite.com/Home )

  • Pages with URLs can have properties to define the URL slugs, categorize the content, and contain custom fields to adjust the content’s SEO properties.

    • Media library file URLs are accessible through custom code.

Content types for pages storing structured content

  • Not accessible directly under a specific URL.
  • Serve as building blocks editors use to create strictly-ordered hierarchies.
  • Typical (but rare) examples include elements where the order of items is vital, for example, navigation menus, different company offices, or team organizations.

Folders

  • Folders don’t store any content. They are used to create taxonomies within the content tree to make navigation easier for editors.

Content tree-based routing

Depending on the website implementation, the content tree-based routing feature can generate page URLs based on their position within the content tree hierarchy. Learn out more about features related to pages with URLs:

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, which only serves a single purpose, for example, the website menu, website page’s URL, or highly personalized content defined by the presentation. Or, they can 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.

Structured pages

Page Builder content

Reusable content

  • Editors create new structured pages only in website channel applications.
  • Editors input the data in a structured manner through editing fields.
  • The content is displayed within the hierarchy of the content tree.
  • Content can be either navigable under a specific URL or non-navigable (without a URL).
  • Editors have less control over content formatting and overall page layout, which the developers determine.
  • A change in page layout requires developer assistance and a redeploy of the application.
  • Once created, editors can update this content in theand Content hub applications.
  • Structured content is stored in dedicated database tables.
  • Page Builder allows editors to manage the content and layout of select pages using a WYSIWYG editor.
  • Editors control page layout using widgets and sections – reusable and configurable content prepared by the developers. Editors can dynamically alter the design of a page without developer assistance.
  • Recommended for pages that need to change frequently and heavily focus on their design, such as email campaign landing pages.
  • Page Builder content is stored as a JSON string in a dedicated database column.
  • Reusable content can be created from website channel applications by selecting the Create new button when editing any page that has a field containing linked content items.
  • Selecting the Create new button automatically creates a new content item of a predefined content type and whenever the changes are saved, links the new content item to the currently edited page.

The following diagram shows the options for adding content in website channel application. You’ll learn about the presentation layer on the next page, including the page templates.

Content management in website channels

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.

Recommendations – Structured pages

We recommend using structured pages for:

  • Pages with non-changing content structure and a relatively static layout, such as articles, blogs, news, listing pages, biographies, or company offices.

  • Non-navigable structured pages to define content hierarchy that requires specified order.

    • Developers can create dedicated Page Builder widgets that display the menu or other custom mechanisms that dynamically display the content.
    • Typical examples: navigation menu, tabbed sections, or cards.

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.

Page Builder

Structured content (both non-page items and reusable content)

Advantages

  • Focus on design
  • Greater control over the layout and styling
  • Easier to fine-tune individual pages
  • More flexibility for personalizing pages 
    content
  • Focus on content
  • Easier to work with data in code
  • Better for storing reusable content presented across multiple channels

Recommended usage

  • Campaign pages
  • Landing pages
  • Home pages
  • Articles, news, blog posts

  • Offices, Subsidiaries

  • Case studies

  • Reusable content types

    • Author bios, Employee profiles
    • CTAs, banners, FAQs, videos

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.

Recommendations – Page Builder

Use Page Builder to layout and design content stored in a structured format. This approach helps editors focus on creating quality content and reuse it where needed.

We recommend using Page Builder content for:

  • Parts of a page to allow for content personalization.

    • For example, above-the-fold content on high-traffic pages (home page), prominent areas on listing pages (articles page), project-specific category pages, or user profile pages.
  • Entire pages when creating one-off marketing campaign pages.

You can use the Rich text and Form widgets provided out-of-the-box when working with Page Builder.

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.

Structured content reuse example

Summary

  • The primary method of storing website content in Xperience is pages and content items.
  • Pages store data using a hierarchical structure visualized in the content tree.

Three kinds of content you can find in a website channel application’s content tree:

  • Structured content – contains structured and strongly typed data stored within page fields (available fields vary depending on used page types). Editors add the content on the Content tab and then retrieve and display it on the live site.
  • Page Builder content – This type of page is managed using Page Builder, which allows users to design pages using configurable widgets. See Page Builder for more information.
  • Folders – do not store any content and only serve as categories for sub-pages in the structure of the content tree.

In typical Xperience projects, these three approaches are combined together to create an effective content management experience that supports reusing the content as necessary. Stakeholders must decide how they’ll work with the content when defining the project requirements. However, to make your content future-friendly, we recommend storing it in a structured format.

You have learned about the options for storing data in Xperience. On the Design content page, you’ll learn about different approaches to designing and presenting this data in your application.

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.
    • Learn more about how to set up these types of templates in the Content tree-based routing chapter. More details about templates specifically can be found on 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.

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.

Recommendations – templates

We recommend basing every page type using the URL and Page Builder features on page templates. Basing your pages on templates with editable properties from the beginning ensures that your content editors receive various configuration capabilities from the project’s start.

Recommendations – page presets

To speed up content production and publishing, we recommend creating custom page presets for pages that work with Page Builder.

For example, a senior editor can create an empty page using the default page template, configure its layout with required sections and (empty) widgets, and save your configuration as a page Preset.

When editors create a new page of this type, they’ll start working on a preconfigured page. This helps with content production and helps keep design consistency between pages with the same underlying content type.

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

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:

    Selecting content items from Page Builder widgets

  • 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.

Widget with a selector and an explanation text

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.
    Page selector component with filtered selection
  • Similarly, developers define which type editors select into the widget properties, such as the Benefits widget in the KBank demo site.
    Selector content type selection

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.

Widgets that store and design the content at the same time

Similarly, the Page heading widget on KBank demo site allows editors to add content and style it using only widget configuration properties.

Add formatting metadata to content using a widget

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.

Mixed-content widget example

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_ContentItemCommonDataContentItemCommonDataPageBuilderWidgets), 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.

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.