Content modeling best practices recommendations

Question

Who all should be involved in Content Modeling exercise, would only Tridion Architect and Tridion Developer with high level requirement knowledge suffice or Business Analysts with in depth knowledge of requirements should be part of it. If both needs to be involved, who needs to drive it? What should be the approach of content modeling in agile kind of project? Are there any good resources/links available for content modeling process and best practices? Sorry for many questions, I thought since all are related to content modeling I should phrase it at one place.

Answer 1

There are two parts to content modeling for any CMS:

• Web Content Model, or the relationship between pages, content, and possibly "regions" (what content can show on which pages in what quantities)
• CMS or in this case, SDL Tridion Content Model including:
  • BluePrint
  • Schemas
  • Default Component (Content Types)
  • Component Templates
  • Page Templates
  • Default Pages (Page Types)

While I've seen multiple roles understand how a given Web Content Model works, I think it's challenging to make a Tridion Content Model without the full context of both delivery and authoring needs.

Your delivery-side technical formats should not dictate a content model, but "user-friendly" isn't enough because you need to consider people, process, and technology.

Who all should be involved in Content Modeling exercise?

I've rarely seen an entire Website's functionality and design created by one role. The Tridion authoring forms (Components based on Schemas) create an internal application of sorts so some type of analysis is needed, even if not filled by someone with a formal title.

Who needs to drive it?

The project will create constraints on time and resources, which sometimes means architects or developers may drive a content model. Authors typically need to live with the content model long after the main development is done, so drive accordingly.

I believe technical constraints and preferences should inform the content model, but not dictate them. For example, Website navigation can be created with an XML file. This does not mean Tridion should have a schema that matches that XML file's format.

Even the strongest analyst can't predict and know all the use cases for a given content model. The best qualified to drive a model would be someone who's willing to measure, adjust, and refactor it while collaborating with authors.

Content modeling in agile kind of project?

The agile manifesto values both customer collaboration and contract negotiation, but customer collaboration more. With a CMS you have external and internal customers. Add Tridion and I see these modeling practices help with agile projects:

• Collaborate and be ready to incrementally develop the content model (top-down or bottom-up, up to you). The hallway test should applies to CMS forms, before needing to build any template code.
• Increment or add "as needed." You would rarely see unused fields or functionality on a website (i.e. "this feature is under construction") without a disclaimer. In the same way, don't release authoring forms (schema changes) until they actually do something. At the minimum, show new features in a sandbox or QA environment of sorts.
• Understand the impact of schema changes. Be agile with descriptions--they have very little impact, so changing them should be up to the business, if not actually made by authors.
• Understand BluePrint changes and what's easy to move. The BluePrint is probably something you don't want to do completely agile unless you've mastered the Content Manager-side APIs.
• Leverage the CM-side APIs and tools (Core Service and Content Porter). You can't make schema changes in an agile fashion and expect authors to keep up without some programmatic help. If truly agile, develop scripts into re-usable tools or extensions.
• Manage the definitions by considering scalable schema fields and feature-driven CMS design. Options driven by keywords means authors can bulk apply or search for options while developers can add new "features" without schema changes.
• Simplify documentation by offering "self-documenting" examples. Good descriptions, page types, content types, examples, Custom Urls to examples, and Custom Pages can all help here. For example, I've made a script to output organizational item settings. There's also a PowerTools extension that documents schemas.
• If using Experience Manager, start with the easiest parts first (pages and in-context editing over inline editing).

Basically keep technical debt low to stay flexible.

Most companies would never build a website site unseen without: * designing the experience * confirming instruction fields * possibly prototyping an interface

You can do this easily with a CMS since it takes moments to prototype a use-able content entry form. So here's a final practical practice: work with authors when creating their entry forms. They shouldn't be surprised by schemas with an agile CMS approach.

Answer 2

Vinit, welcome to the field of WCM. Your question actually applies to any CMS, not Tridion in particular. Actually, it applies to any application that has users, not just a CMS. Here is why...

The system should be tailored to its users. Typically, developers/techies aren't very good at determining that since they sit in their own introverted world of Eclipse and Visual Studio. So folks that understand the users of the system (or the users themselves) and what they want should provide the usability requirements. In the world of WCM and Tridion, this is Functional Design (and Content Modelling is a part of it).

Content Modelling is a way to tailor the CMS system to its users, i.e. Authors and Editors. It defines how they will enter and manage their content. Having techies decide that without usability testing by the people that will use it will most likely yield a very technical and not-user-friendly model that the editors will loathe.

As far as who needs to drive this process depends on how your org is structured. This should fall on the plate of the business analysts, however, often they don't know Tridion, so this falls on the plate of the Tridion consultant. SDL Professional Services, for example, has a dedicated team of Tridion Functional Consultants that specialize in this. They work together with the techies to question the editors and design a system for their specific use cases. My team, and many other Tridion organization's teams' consultants, are trained at the functional and the technical sides. Either way, there must be a process where the content model is vetted out and tested by the end users - the authors/editors in this case.

Here are some helpful links on the topic: "The schemas are the easy bit… right?", Will Price, http://www.tridiondeveloper.com/the-schemas-are-the-easy-bit-right

"Tridion Content Analysis", Alvin Reyes, http://www.createandbreak.net/2012/09/tridion-information-architecture-part-1.html

Actually, http://www.createandbreak.net is a blog dedicated to good functional design in Tridion. There are many articles there that speak to content modelling.

Answer 3

Vinit,

Nice to meet you on the Tridion Stackexchange :)

To answer your question straight forwardly:

1. Who all should be involved in Content Modeling Exercise - Primarily Business Analysts, Business Users (for understanding their expectations) and Tridion Consultants/Architect. As Nick has pointed out, Developer level people might not be good choice as they may not have been exposed to the Business Context and various things which comes above the coding like User Experience/Usability, Future Considerations, Other projects in site etc.
2. Who will drive this - In my opinion the Business Analyst should be the guy as he is supposed to be most close to the Clients, of course he should take help from Tridion consultant/architect for any hit on implementation - for example: Having a schema with 5 level of embedded schema may be suggested by functional consultants considering the user requirement but may not be good from implementation perspective and an alternate can be used for a good content authoring and implementation ease (balanced experience)
3. Approach - It should take the User experience/Usability or ease of content authoring on top priority and technical best practices, implementation ease etc. on the second priority. The techies may suggest an art of a solution which is a gem in programming world but if it is not giving user/content author an ease to use; the solution is a waste. For example: You may choose to implement a complex solution to minimize templates by creating a single Schema which may be accommodating multiple Content Types but if the Users are anticipating to utilizes XPM Layout features to review the changes inline then it may make more sense to have multiple schema. In a nutshell, the approach depends more on the specific business needs rather a traditionally defined approach.
4. Resources - Nick has already shared few nice articles to follow. In addition, you may want to refer below links as well:

http://www.slideshare.net/gadgetopia/content-types-the-building-blocks-of-your-content-model-2645854