Some Tridion implementations I have worked on/designed make use of just a few schemas and tend to use a General Schema which has a lot of Component Templates linked to it. The Component Templates do not generally make use of all the fields on the schema and often none are mandatory.
What are the advantages and disadvantages of this approach?
It seems to me it makes the solution flexible but at the cost of some editor usability. It would be interesting to hear others' thoughts on this.
A generic content schema can complement a well-designed content model, but shouldn't be the only schema in an implementation.
A generic schema offers:
The generic approach assumes page = rich text format area, which doesn't fit most organizations' content types nor takes advantage of the separation of structure, design, and content.
A generic schema can add user add technical debt, as Jonathan suggests, and has the following disadvantages:
An author's experience with a given content type as a decision tree of sorts. Reducing these options will improve efficiency as well as "trust" in the system--each field is clear and choices have an obvious affect on the site.
Rather than assuming a generic schema, considering the following approaches.
I've joked that a CMS with a single schema and template would be a blog. Speaking of which, I'd encourage other answerers to join the discussion around Tridion schemas and content modeling through their own blog posts or in comments to existing posts.
Reusability is good, but if you have different types of content, it can be an error trying to fit all of them on the same schema. The most affected by these decisions will be the editors, it is good to check with them how they envision the content model.
Advantages:
Reusability. You can reuse the same content with different presentations avoiding repeated content.
Easier for the editors to select the appropiate schema. (This could otherwise be mitigated with default schema per folder)
Disadvantages:
Dead Fields in some Presentations: Some templates will use certain fields, and other templates will user others. The used fields are easier too remember when you have a couple of CT (i.e: summary and detail), but when you go overboard this can lead to:
"Why is this field not displayed?", "What field should I fill in?"Difficulties selecting the correct CT. The editors need to be trained to understand which one of the XX CT corresponds to the presentation the he is looking for. (And what fields will be displayed)
Reduced control over permissions.
The need for new fields is not uncommon. The more content types you fit into the same schema, the more likely you are to add new fields to an already too big schema
Having a single 'General Content' Schema seems to work quite well for content that is actually normal 'marketing' content. However, if you have a lot of fields that are consistently not used, except for in specific circumstances, then this would suggest that you may want a new Schema for this type.
Although keeping the number of Schemas down is important from a maintenance and purists perspective, it is more important that content editors can use Tridion as easily as possible. They will be spending possibly hundreds of hours editing content in Tridion, so it is important to make their lives as easy as possible.
(Obviously you would want to keep common field (XML) names the same between Schemas.)
Additionally to what Angel stated, if it is a Content Type (Contact, News, Article, Product, Service, Card etc...) DO NOT USE a General Content schema. Instead just create a specific schema for that content type, yes... they might have the same field but that is not enough to actually group them together. In case you find it convenient just create an embedded schema to put together those common fields in both (regular) schemas.
There is somthing which is overlooked quite frequently nowadays and it is very surprising to me... PERSONALIZATION. We are moving into an internet which is much more personalized, how are you going to target a visitor with X content type (product, banner, offer, travel) if it is general content??
Great question, and lots of good answers already here so I will not repeat their content in my answer. No-one seems to have mentioned Workflow yet. If you are, or may in the future implement workflow for particular types of content, then it is much better to have separate schemas, as the workflow definition is (at least for version 2011 and earlier) related to the schema. If you have a General Content schema then you cannot have different workflows for different types of content, and more importantly cannot turn workflow on and off for different types of content - its all or nothing!
More reading on schema design can be found here
A fine balance needs to be found between using a massive "all-in-one" schema or specific schemas. The general rule is to reduce the amount of schemas and templates to avoid duplication and promote re-use. But this can quickly get out of hand as well. So in my opinion, use common sense and work with the client to design what works for them.
Alvin discusses this exact topic in his excellent post "10 Extreme Schema Scenarios": http://www.createandbreak.net/2012/01/10-extreme-schema-scenarios.html
And here is another related post: http://www.createandbreak.net/2012/12/when-near-duplicate-sdl-tridion-schemas.html
I think all in one schemas are a disaster waiting to happen if you have any remote need to port content later. In a traditional templating setup, if you don't keep tabs on where CTs or PTs are using the fields then you have an awful lot of regression testing to do whenever you introduce changes.
I prefer to try and stick to one schema per content type. Tridion is a CMS so editors should come first. With the advent of DD4T it's straightforward anyway from a templating POV for developers!
In my opinion, General Schemas work ok, but when you get to the point when adding new editable content to a CT and someone says, "Just use the x field and we'll document how it works" you need to create a new schema.
It's common sense, use it where possible, but don't force nonsensical content into fields just to use the general schema.
In software development generally, the search for re-use has always had to be tempered by the fact that re-use has a dark side. To achieve re-usability, you first have to manage our ancient enemy: dependency. Nowhere is this more apparent than in the relationship between schemas and templates.
The only reason for having several templates related to a schema should be that you genuinely wish to have multiple views of the same data. What's more - all of the templates related to a given schema need to be controlled by the same programmer/team. The schema is then "owned" by that team, who may change it as they wish over time, assuming that they are prepared to manage the changes.
If you have a General schema, any time you wish to enhance a specific feature set, you'll have to assess the impact on, and re-test all your other feature sets, and that's assuming that you don't find yourself so thoroughly painted into a corner that the desired change is impossible without a major re-write.
Even if we were to accept that some benefits of re-use might come from having a General schema, it's not really that likely to help the content workers. If you have a schema with lots of optional fields, some of which are needed in one scenario, and others in another, you have already lost the game. Imagine the training overhead you are inflicting on that team, not to mention the additional concentration they will require every day to do their job effectively. For a lot of less common tasks, they'll have to revisit your (inaccurate?) documentation every time.
You may also wish to consider if you have any dymanic content. For example we have news articles which are regularily updated and which appear across our sites and we often need to show the most recent articles on a number of pages without the need for editors to update each page. For this we dynamically query the broker in our User Controls.
If you use a one size fits all approach, then when you publish the components out dynamically you will soon start to see a big load on the publisher as it has to render the component for each dyanlically linked template regardless of whether it's needed or not.
In the dynamic world it is often better to create separate schemas and embed common fields and then you can control which CTs target which schema. Your templates can be coded to work with the common elements to ensure you don't duplicate these.
Tridion Schema's purpose is to define information and data, like database table :) so the similar question will be "a General database table for everything?" you and many people will have an easier answer for that. practice telling us, general content table exist and specific content table exist too.
i agree to Nick, according to the requirements. you may have both general content schema and specific content schema. also consider general content and specific content have opposite time cost. so for long-term, you will see a better TCO of well balanced design.
key-value setup.
– Alvin Reyes♦
Mar 13 '13 at 22:06
