“Many from one!” That might sound a bit like witchcraft. But it is common practice in our SCHEMA ST4 Component Content Management System. One of the things most users really appreciate about their CMS is that several operating instructions for similar products can be generated from one project. So many really can be created from one. However, you can soon become overwhelmed if the wrong strategy is employed – just like Goethe’s Sorcerer’s Apprentice. In this post, you will learn how to have the right magic spell to hand, with taxonomies and filters.
Let’s say we want to create several operating instructions from one database, then we need three things: 1. The objects that are being filtered, 2. Criteria for filtering them and 3. Rules that are applied for the filtering.
So how does that look when applied to SCHEMA ST4? First of all, what can be filtered? In ST4, all types of nodes can be filtered as well as, for example, fragments, structure fragments, callout graphics or data nodes in dynamic tables. The sky is virtually the limit. Only content elements in the editor (e.g. paragraphs) cannot be filtered. However, should you need to do this, such content elements can also be stored in fragments (i.e. converted to dedicated nodes and then filtered again).
If you want to filter out nodes, then you need criteria for making a selection. Such criteria are best stored as a structured, hierarchical collection in a taxonomy. However, the choice of taxonomy is important. This is most evident when using a product taxonomy. Almost every company has several different products, each with several product variants. This product structure is known within the company and so it can be easily, quickly and fully represented in a taxonomy. Afterwards, each node only needs to know for which products and product variants it is relevant and the database can be filtered…
… or so you’d think. In practice, there is a major drawback to this process, or to be precise, two. Firstly, it is difficult to represent custom products and individual solutions in this way. However, what is much more problematic about a product-orientated taxonomy is that, each time a new product is added, the database must be re-evaluated and if necessary re-organised. So, the rapid creation of the taxonomy during setup comes at the cost of (significantly) increased maintenance during operation.
What are the alternatives? Property-orientated taxonomies are a starting point. They capture the available product options (such as size, colour, engine power). These product options can also be kept in a taxonomy, via which the content can be filtered and controlled in detail. The advantage of this approach is clear when a new property is added (let’s say there is now also a product variant with a display). In this case, the database does not need to be touched, just the new nodes that need to describe the display “learn” that they are responsible for the display. In the case of existing nodes, it is automatically clear that they have nothing to do with this new property. Granted, it can be time-consuming to compile all product properties for a taxonomy and the taxonomy can be very extensive. However, the administrative burden during operation falls dramatically.
So we’ve covered product-related taxonomies. Other taxonomies can be set up as required, based on target group, sales region or manual type, for example. You should not integrate such information in the product-related taxonomy, but in dedicated, separate taxonomies. This is because when such non-technical criteria is mixed with product features, for example, it results in multiple dependencies, which multiply through authoring processes into an exponential number of combinations.
With these taxonomies, you can build a hierarchical classification of your database. This provides a basis for carefully targeted selection of content for your communication requirements. Let me explain what carefully targeted means here: When classifying your content go as high as possible in the hierarchy – If a node applies to all products, then select the highest level, if it applies to series A, then select the taxonomy entry “Series A” and not all products that are listed under series A. In order words, use as general a classification as possible.
When creating taxonomies, there are a number of recommended settings that you can select. Make your filter taxonomy language-independent, allow the taxonomy to be used in the properties, variant management and advanced search and switch inheritance off. As already mentioned, it doesn’t usually make sense to only be able to select the lowest entries in a taxonomy. This will configure your taxonomy in a manner that works for most requirements.
Let’s now turn to the last aspect, which allows you to create a number of documents from one master project – the filters. It is important that you create highly-specific filters. One filter must contain all criteria, e.g. each product property must be covered by the filter. Did you know that you can use the APX module to import data collections and automatically fill the filter?
While it is advisable to select the highest level up as possible in the hierarchies in the case of taxonomies, the reverse applies for filters. Filters need to be highly specific; they make a statement about each property at the lowest level. Also include in your filter what happens if a property doesn’t exist or is not used. In other words, a filter is the fingerprint of an individual production – a complete definition of the product and document properties.
When configuring the filters, make the following settings: Set it so that the filter relates to the selection or the higher-level property and select the OR operator within a taxonomy. Various taxonomies automatically have an AND operator.
Overall, the filter and taxonomies represent a powerful tool. When applied correctly, they allow you to create any number of targeted documents from one single project. And if you use the tips provided in this post, it is anything but witchcraft.
Udo Weber studied chemistry at the Friedrich Alexander University in Erlangen. He then gained over 20 years of documentation experience in the fields of software and telecommunications. Since 2010 he has been working for SCHEMA Group as an editor and trainer, responsible for customer training and workshops, among other things.