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.
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.
Because you can choose how constrained your templates are, you could have anywhere from 1 to 100 templates! You could just have one page template where a content author can put any component in they want, in whatever layout they want; in that case, just 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”).
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.
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.
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.
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:
• Sitecore’s content author documentation of page templates – you may need to scroll to the top to get an understanding of all the types of Sitecore templates
• Adobe Experience Manager’s content author documentation of templates – this is an example where you have to scroll past info you don’t need (role info) to get to info you want (a succinct explanation of static versus editable templates)
Next up: components and configuration options!