In this final post in the removing distractions series, I’m going to discuss another way to streamline the editorial experience – by simplifying the (content and metadata) fields that an SDL Web editor is presented with.
When an implementation first starts out, (hopefully!) the schemas and fields are carefully thought out by the content model designer.
Questions asked will probably include things like:
- Which Schemas will be mapped to which elements in the designs (i.e. What are the Component Templates)?
- Which elements within those Component Templates will map to which Schema fields?
- Does Schema field X need to contain rich text?
- Should this heading be part of the rich text field or a separate (probably plain text) field on its own?
- Which formatting options will an editor need on the rich text fields? Are there any exceptions to this in specific scenarios (I.e. For specific fields within certain Schemas)?
However, as the website requirements develop and change, the schema fields often need to be extended or modified to accommodate extra content. For example, the website owner may say that as well as an image, an article may also need to contain a separate video.
There are two main consequences to these types of request:
- Fields are often added, but rarely taken away when no longer needed. This results in editors are presented with an ever-increasing number of boxes and options to consider.
- New fields are often just added to the bottom, with no thought to the editorial workflow when creating and entering content. (I will cover this in a separate blog post)
These problems are even worse when schemas are shared between multiple websites managed within SDL Web or have to accommodate country-specific content requirements.
Right. Enough about the problem. What can we do to improve the situation?
I’d recommend tackling this in three steps:
- Analyse what you currently have
- Determine which fields could be removed
- Implement and test
Step 1 – Analyse what you already have
The first thing I’d suggest doing is taking stock of what you already have. For this, you could start out by mapping which schemas are used with which templates.
(You may be surprised to find out that some of your schemas aren’t used at all!)
Then assessing which fields are used by each of these templates.
And then gather information about how many components of each type there are, how many of these are actually published, and how frequently each of the individual fields within these are populated. To figure this out, you could review a subset of your content, question your content editors, or write an automated tool (probably using the Core Service).
Step 2 – Determine which fields could be removed
Once you’ve done a complete audit of your templates, schemas and fields, you can go about assessing which (if any) fields can be removed.
It’s not always a straightforward task to interpret the content analysis. Although the existing content will give insight into the volumes of each type of content and how often the fields are being used, it may misrepresent how the content should be modelled. Some examples of this include:
- A field that is never used, and can be removed completely, but the fact that there is a default value (when the component is created) can make the audit look like it is still used and needed.
- Just because a template outputs a field, it doesn’t mean that the field (unless mandatory) is actually filled-in by the editors.
- Even if a field isn’t rendered out by a template doesn’t mean that it isn’t used. For example, a ‘Publish date’ (custom metadata) field could be used for filtering or ordering results on the website. Or a ‘Content owner’ field could be used for internal reporting within the Content Manager (using a Custom Page or similar).
This is where you’ll need to rely on a few key things:
- Your analysis of the existing content structure
- The knowledge of your super users
- Your investigation into any customisations (Event System, Custom Pages, etc.) and application code
Once you’ve completed your investigation, you should have a list of fields that can be removed.
Step 3 – Remove
Unfortunately, once a schema field is removed and the content re-saved, then that content is deleted from the CMS completely.
With this in mind, the steps below outline a cautious approach for deleting the unneeded fields:
- Inform your editors about your plans to delete the unnecessary fields as early as possible
- Thoroughly test that your sites and customisations work before removing the fields and ask your stakeholders to sign this off. (This can save a lot of finger pointing afterwards!)
- Backup your Content Manager databases from earlier environments (Dev, Test & Acceptance)
- Remove the fields and and code that references them from earlier environments (Dev, Test & Acceptance), republish the content and check nothing functionally breaks on the site (or Custom Pages, Event System, etc.)
- Backup your Content Manager database in Production
- Remove schema fields and any code that references them in Production and republish the content
- Re-test the sites and customisations
- Go to the pub to celebrate
As mentioned above, the ‘out of the box’ behaviour is for content to be removed once the schema field is removed and the content re-saved. However, a lower risk alternative to this would be to use a GUI extension (such as the one here from Robert Curlette) to just hide the unwanted fields or make them read-only until you’re confident that they’re no longer needed.
Removing unnecessary fields is just one more example of improving the SDL Web experience of your editors. However, this doesn’t need to apply to just Component Content and Metadata fields, the same principles can be applied to Page, Structure Group, Publication & Keyword Metadata fields too.