g2o animated logo transition
welcome to what’s next. ICC and Clutch are now g2o. Click here to learn more.
Notification bar close button
Unfortunately, Microsoft is no longer supporting new web standards for Internet Explorer and recommends that users upgrade their browser experience.

On the bright side, there are some awesome modern browsers like Microsoft Edge, Google Chrome, Firefox, and Safari that can enhance all your web experiences. What’s your next...browser?

CMS building blocks for CX designers: Part 2

Greenfield
by
Jackie
Greenfield
on
September 16, 2019

Understanding your CMS template functionality and how components work together will help you better plan for and execute your work in a meaningful way.

Understanding your CMS template functionality will help you better plan for and execute your work in a meaningful way. Creating more pages than necessary can be a waste of time; creating too few can mean issues later, during development and content authoring.

CMS templates

As explained in the first article in this series, templates are the “base” upon which your pages are built, and can usually be simple or complex, constrained or unconstrained. Templates can be as simple as header/footer, with an area in between to put components. For a responsive site, one “template” would include views for desktop, tablet, and mobile (or whatever your screen sizes are).

You might also have specific templates for complex pages that need to always combine a set of components, such as a product list or product detail page.

Example of a basic unconstrained base lego
Basic, unconstrained base

Example of complex, unconstrained base lego
Complex, unconstrained base

Example of how CMS components relate to a template
How components relate to templates

Why understand templates?

Understanding your CMS template functionality will help you better plan for and execute your work in a meaningful way. Creating more pages than necessary can be a waste of time; creating too few can mean issues later, during development and content authoring.

There may be CMS-specific functionality that you can leverage, improving the end result.

Designing with the right flexibility in mind

Because you can choose how constrained your templates are, you could have anywhere from 1 to 100 templates! You could have only one page template where a content author can put in any component they want, in whatever layout they want; in that case, only one template is needed. Or, you could have extremely specific, locked-down page templates, with every possible variation already available for content authors to pick from.

Typically, a middle ground works best. You want enough specificity to create consistency throughout the site, while also allowing enough freedom that you don’t have to design every single page on the site.

When you are figuring out how many designs/wireframes you need to create, keep this flexibility in mind. If you think two types of pages will be very similar with just a few pieces (components) that differ, you probably only need to create one and annotate the changes that will occur for the other (i.e. “these two components won’t show for articles, but will for white papers”).

Examples of legos in ten different simple design formations
Do you need to create 10 designs?

Examples of Lego designs in complex formations
Or do you focus on the most complex variations,
knowing the rest can be easily created by taking pieces away?

Templates in an Agile framework

The number one thing about Agile and CMS templates: flexibility is key. Every step needs to be accomplished knowing that it will change, from designs to functional specifications to code. And the team needs to be aligned on this from the get-go.

Create a foundation of a few key templates that support a variety of components (pieces) and content types. Design for likely variations up front, such as needing two or three column options within your template, to avoid larger changes down the line.

Using your foundational templates, leverage your site map to plan out the rest of the templates based on content needs. Again, know that this plan will likely change over time.

Understanding CMS template functionality example: default content and content policies

There may be specific CMS template functionality that you will want to plan for. Learn the basics of yours and figure out what you can use.

For example, Adobe Experience Manager offers editable templates, which can be built by content authors with the appropriate permissions. In addition to default components, these also offer the ability for default content and content policies. Default content is pretty self-explanatory — images, copy, videos, etc. — that are on that template. This content can be locked and un-editable on pages using this template, or unlocked, meaning content authors can change or remove it.

Content policies can govern just about every aspect of content you can think of. A common example is determining which components can be edited, added, or removed — the header and footer probably shouldn't be removed, for example. Another example of a content policy would be setting a minimum/maximum dimension for an image.

Example of a content policy screen for editable template
Example of a content policy screen for editable template
https://helpx.adobe.com/experience-manager/6-4/sites/authoring/using/templates.html

Making recommendations for content policies can be a great way to encourage better content down the road. Designers and content strategists are often less involved when content is actually created and entered by content authors, but you can still have an impact this way.

Example of a Lego use guide
Lego guide

Content policies are how you ensure that only Star Wars pieces can be placed into your Star Wars template

Example of a completed Lego set
Completed Lego set

Otherwise, you might end up with red wheelbarrows showing up, completely ruining the look you’re going for!

How to understand your CMS template functionality

Ideally, you’ll have a solution architect who can sit down with you and explain the basics (possibly with Legos).

Barring that, look online! Check out your CMS’s content author documentation. Avoid the developer documentation, unless you are one.

For example, these have some pretty straightforward explanations:

Experience
Experience
Experience
Experience

CMS building blocks for CX designers: Part 2

Greenfield
by
Jackie
Greenfield
Jackie
Greenfield
on
September 16, 2019

Understanding your CMS template functionality and how components work together will help you better plan for and execute your work in a meaningful way.

User Experience
Navigation arrow back
Scattered lego blocks

Introduction

Understanding your CMS template functionality will help you better plan for and execute your work in a meaningful way. Creating more pages than necessary can be a waste of time; creating too few can mean issues later, during development and content authoring.

CMS templates

As explained in the first article in this series, templates are the “base” upon which your pages are built, and can usually be simple or complex, constrained or unconstrained. Templates can be as simple as header/footer, with an area in between to put components. For a responsive site, one “template” would include views for desktop, tablet, and mobile (or whatever your screen sizes are).

You might also have specific templates for complex pages that need to always combine a set of components, such as a product list or product detail page.

Example of a basic unconstrained base lego
Basic, unconstrained base

Example of complex, unconstrained base lego
Complex, unconstrained base

Example of how CMS components relate to a template
How components relate to templates

Why understand templates?

Understanding your CMS template functionality will help you better plan for and execute your work in a meaningful way. Creating more pages than necessary can be a waste of time; creating too few can mean issues later, during development and content authoring.

There may be CMS-specific functionality that you can leverage, improving the end result.

Designing with the right flexibility in mind

Because you can choose how constrained your templates are, you could have anywhere from 1 to 100 templates! You could have only one page template where a content author can put in any component they want, in whatever layout they want; in that case, only one template is needed. Or, you could have extremely specific, locked-down page templates, with every possible variation already available for content authors to pick from.

Typically, a middle ground works best. You want enough specificity to create consistency throughout the site, while also allowing enough freedom that you don’t have to design every single page on the site.

When you are figuring out how many designs/wireframes you need to create, keep this flexibility in mind. If you think two types of pages will be very similar with just a few pieces (components) that differ, you probably only need to create one and annotate the changes that will occur for the other (i.e. “these two components won’t show for articles, but will for white papers”).

Examples of legos in ten different simple design formations
Do you need to create 10 designs?

Examples of Lego designs in complex formations
Or do you focus on the most complex variations,
knowing the rest can be easily created by taking pieces away?

Templates in an Agile framework

The number one thing about Agile and CMS templates: flexibility is key. Every step needs to be accomplished knowing that it will change, from designs to functional specifications to code. And the team needs to be aligned on this from the get-go.

Create a foundation of a few key templates that support a variety of components (pieces) and content types. Design for likely variations up front, such as needing two or three column options within your template, to avoid larger changes down the line.

Using your foundational templates, leverage your site map to plan out the rest of the templates based on content needs. Again, know that this plan will likely change over time.

Understanding CMS template functionality example: default content and content policies

There may be specific CMS template functionality that you will want to plan for. Learn the basics of yours and figure out what you can use.

For example, Adobe Experience Manager offers editable templates, which can be built by content authors with the appropriate permissions. In addition to default components, these also offer the ability for default content and content policies. Default content is pretty self-explanatory — images, copy, videos, etc. — that are on that template. This content can be locked and un-editable on pages using this template, or unlocked, meaning content authors can change or remove it.

Content policies can govern just about every aspect of content you can think of. A common example is determining which components can be edited, added, or removed — the header and footer probably shouldn't be removed, for example. Another example of a content policy would be setting a minimum/maximum dimension for an image.

Example of a content policy screen for editable template
Example of a content policy screen for editable template
https://helpx.adobe.com/experience-manager/6-4/sites/authoring/using/templates.html

Making recommendations for content policies can be a great way to encourage better content down the road. Designers and content strategists are often less involved when content is actually created and entered by content authors, but you can still have an impact this way.

Example of a Lego use guide
Lego guide

Content policies are how you ensure that only Star Wars pieces can be placed into your Star Wars template

Example of a completed Lego set
Completed Lego set

Otherwise, you might end up with red wheelbarrows showing up, completely ruining the look you’re going for!

How to understand your CMS template functionality

Ideally, you’ll have a solution architect who can sit down with you and explain the basics (possibly with Legos).

Barring that, look online! Check out your CMS’s content author documentation. Avoid the developer documentation, unless you are one.

For example, these have some pretty straightforward explanations: