Page pattern
A page is one of the basic parts of a web app.
See the page pattern in action by clicking on the link below:
Demo Page pattern (opens in a new tab)
You can create this pattern in Prepr automatically when you create a model. Choose the Page pattern template and the models and components listed below will be created for you.
Introduction
This guide takes you through the content modeling process for a page pattern and explains the reasoning behind the modeling decisions. We'll look at how to model a feature-rich web page with a variety of elements. Here is a sample web page we used as a basis for the modeling:
Include the link to the model template when the model templates can cater for referenced supporting models and embedded components
Let's take a closer look at the modeling steps. Using this page as a basis, we see that a number of elements make up the page content. These include:
-
A page header The page header has a heading, an image, some text and a call to action.
-
An image and text block These blocks contain a heading, some text and an image.
-
A collection of articles This element contains a selection of articles.
-
A collection of products This element contains a selection of products.
-
A call to action The call to action at the bottom has a heading, a background image, some text and a button that opens another page.
Let's look at how to structure a page like this in more detail.
The Page model structure
In our schema, we've decided to create a generic Page model that can be used for different kinds of web pages, for example, a home page, marketing pages, landing pages, etc. The Page model is our starting point where we make a lot of our modeling decisions.
See an example Page model below:
Within the Page model we define the following fields:
Field name | Field type | Description |
---|---|---|
Title | Text | The title of the page. Required. This title is used internally to identify the page in Prepr. |
Slug | Slug | Part of the URL that is used to link to this page. The slug can also be used for API queries to request this page and is automatically set to the title of the page in our example. |
Type | List | The type of page, e.g. Home page, marketing page, etc. The front-end uses this field to determine which page template to render. |
Stack | Stack | The Stack field has all the elements that we want to show on the page, for example, the page header, an image and text block, etc. It's possible to create a feature-rich web app easily using this field. |
SEO | Component | SEO is an embedded component which contains fields that are used by search engines and social media. We reuse the same SEO component defined in the Blog pattern doc. |
See a complete list of all other available Prepr field types.
How to model the elements on a page
In our example pattern above we put the page elements into a Stack field. The Stack field allows content editors to create a "stack" of all the elements on a page. They can add both components and content items to the stack. This means that it's easy to create feature rich web pages from this content. See the complete example page model below:
The Stack field contains the following components and models:
Model/component | Type | Description |
---|---|---|
Page header | Component | The page header component. |
Image and text | Component | The Image and text component. This component contains a simple image and text block. |
Article collection | Component | A collection of articles. This component references the Article model in the Blog pattern doc. |
Product collection | Component | A collection of products. This component includes remote content from Commercetools. |
Call to action | Model | A reference to a Call to action. |
Let's look at each element in detail.
The Page header
For the Page header, we create a component with just the right fields for the editor.
See an example structure for the Page header component:
Within the Page header component we define the following fields:
Field name | Field type | Description |
---|---|---|
Heading | Text | The heading used in the page header. Required. |
Description | Text | Descriptive text used in the page header. |
Image | Assets | An asset field that allows an image to be attached to the page header. |
CTA label | Text | The label for the call to action. |
CTA URL | Text | A link to another page when the call to action is triggered. |
The Image and text
We create a component for the Image and text blocks. This particular component is a very common structure and can be used on almost any web page.
See an example structure for this component:
We define the following fields for this component:
Field name | Field type | Description |
---|---|---|
Title | Text | The title of the Image and text block. |
Text | Text | The text content. |
Image | Assets | An asset field that allows an image to be attached. Limit 1. |
Image position | List | The position of the image in relation to the text, for example, image to the left of the text or to the right of the text. |
The Article collection
We create a component for Article collection. For example, an article summary page and a home page can use the same featured articles structure.
See an example structure for this component:
Within the Article collection component we define the following fields:
Field name | Field type | Description |
---|---|---|
Heading | Text | The heading text for the collection of articles. |
Description | Text | Descriptive text for the collection of articles. |
CTA label | Text | The label for the call to action. |
CTA URL | Text | A link to another page when the call to action is triggered. |
Articles | Content reference | This is simply a reference to the Article model in the Blog pattern doc. Required. |
The Product collection
We create a component for the Product collection. For example, a marketing page and a home page can use the same product collection.
See an example Product collection structure:
Within the Product collection component we define the following fields:
Field name | Field type | Description |
---|---|---|
Heading | Text | The heading text for the product collection. |
Description | Text | Descriptive text for the products listed. |
CTA label | Text | The label for the call to action. |
CTA URL | Text | A link to another page when the call to action is triggered. |
Products | Remote content | For product information that is maintained in Commercetools. Limit 3. Check out our Commercetools integration doc for more details. |
The Call to action
We create a model for the Call to action so that it can be reused. For example, the same call to action can be reused on the home page and a marketing page.
Within the Call to action model we define the following fields:
Field name | Field type | Description |
---|---|---|
Heading | Text | The heading text for this call to action. |
Description | Text | Descriptive text for this call to action. |
Background image | Assets | An asset field that allows a background image to be displayed. |
CTA label | Text | The button label. |
CTA URL | Text | A link to another page when the call to action is triggered. |
What's next?
Now that you know how to model a page, let's go a step further and look at how to set up personalization doc.
Other use cases
This guide explains how you can design just one example of a page for your web app. Feel free to use this structure and amend it to your needs.
Below, we list a few more common options.
Marketing page
In addition to the elements listed in the use case above, a marketing page could have additional elements for promotional banners that could also be personalized according to the segment of the customers viewing the marketing page. Check out the personalization doc for more details.
Contact us page
You may need a Contact us page in your web app. Imagine that you need to include a contact form on this page. In that case, you can add a form component to your stack of elements.
Prepr has a built-in integration with Typeform which allows you to include forms. For more details, check out the Typeform integration doc.
Job postings page
In some cases, you may have to access content that is maintained in another system, for example, job postings information. It makes sense that you may want to retrieve the items from the other system to ensure you have up to date information in Prepr. In this example, you can include a job postings element on your page that references the job postings from the external system. Prepr allows you to set up remote content in your model or component which is retrieved from a custom source. Check out how to set up a custom remote source doc for more details.
Want to learn more?
Check out the following guides:
Was this article helpful?
We’d love to learn from your feedback