What is Content Model:
A Content Model is a depiction or presentation of various types of content and relationship among these content types. For example: Consider a Hotel. A Hotel will have Content Types for Room, Facilities, Promotions, Hotel Information, Testimonials etc. Similarly a Restaurants will have content types for Restaurant Information, Menu, Offers, Specialties, Testimonials etc.
What is Content Modeling:
Content Modeling is the process of identifying these Content Types along with establishing the relationship among them.
Content Modeling and Best Practice in SDL Tridion:
To be frank there is no best or worst practice defining the content models while working with SDL Tridion (or infact with any of the CMS system). It entirely depends on the business requirements and even for the same business requirement, two people working upon, may end up producing different content model as there may be different ways to achieve the same goal.
However, there are few guidelines which we should keep in mind while modeling the content structure in general and also while working with SDL Tridion WCM tool:
- A good content model must fit well with in the Business Context and should be balanced in usability for both non-technical Content Authors as well as technical Developers with a somewhat inclined approach towards the non-technical Content Authors in terms of “ease of use”
- A good content model must consider not only the use of content in known business context but also the use of content in unknown business context (the short and long term vision of content authoring, content structure and content use)
- A good content model should be able to “clearly describe” your content
- A good content model should be re-usable, flexible and scalable – This itself is a big topic and I may cover this in a separate blog
- Content Model should be balanced in terms of granularity – It should not be too much abstract nor it should be detailing to a very deep level. As per SDL Tridion, it is recommended that you should not go down to more than 1 level deep (means should not have child of child). It does not mean Tridion does not allow or people are not using deeper level of Content Model, but they may need to pay the penalties in terms of small customization for few minor things as they may not work Out of the box (like accessing information at a deeper level in content in plain DWT Templates)
- In terms of SDL Tridion Blueprinting, you should choose to create your Content Models/Schema at the top most level. This allows you to re-use them for all the publications down the hierarchy. Again this entirely depends on the business requirements – For example: if there are multiple unique products publications in the Blueprint and for each one you have individual schema and you may want to see only the specific schema while working with a specific Product, you can still choose to have schema in one publication only and keep them separated through security features (Thanks Nuno Linhares for the suggestion). But further if you come across with a requirement that each Products will have a Tridion System Admin and they also do not want to see the schema for other products, then you may either convince the Requirement Owners or choose to have sibling publication for schema. Ofcourse, you may need to pay the penalty either in terms of Redundancy or lots of rework if in future few of the schema of these products become common.
- Embedded Fields Vs Component Link Fields in Schema – both approach have their own pros and cons and different experts have different views on them; however, in very generic scenario, you should be defining a field as embedded schema type if number of fields are not huge and the information is not going to be reused at multiple place. On the other hand you should be defining a field as component link in case you want to include a complex content structure with in your content structure and reuse these component individually. Depending on your requirements there may be other criteria as well for choosing a field as Embedded Schema type or Component Link type.
- Plain Text Field Vs RTF Text Field in Schema – The most basic guidelines is that if you want to give your authors the liberty to format the content (Bold, Italic, Underline, Font Change, Color Change etc.) in a field in a WYSIWYG way then make the field as RTF else keep it plain text.
- Metadata Field – In a schema, whatever is visible on the site/page and configuration values used by non-technical authors for making a visible change on the site/page should be part of the content schema and whatever information is used to describe the content or used for back end processing (code, logs, reporting etc.) should be part of the metadata
- Numbers of Schema – There is no guideline about the number of schema whether you have 10 or 100 schema. If you are following all above guidelines and doing some brainstorming, you may end up having an optimized number of schema. Tridion won’t restrict you creating hundreds of schema, but you may need to restrict yourself while creating the schema considering the maintenance of all those schema, impacts of having so many schema etc.
Comments Welcome 🙂