How can I ensure a global design language when developing Tridion websites?

Question

One problem that seems to plague many Tridion websites (and not just Tridion) is the difference in the language and naming people and teams will use.

For example: a HTML developer may call something a "Carousel" where a Template Developer might choose the name "Slider". The Schema used would be Component List. Another good example is "Pod", "Box", "Promo", "CTA"

How do I ensure that there is a single version of this language across all teams? Are there any tools people use to help this process?

Answer 1

Use pictures (diagrams) with names chosen before implementation in your CMS designs to encourage consistency. Then help guide an organization to use these design choices in Tridion.

Organizations are ultimately responsible for their naming conventions; however, you can definitely explain and encourage good practices while improving the authoring experience.

Before Implementation

The translation Bart describes could be part of a CMS Design's Page Type and Content Types analysis sections, which summarize an organization's pages and content by "type" using information architecture. See my post for an example approach.

A Page Type defines related content types using a picture with descriptive text, typically in a table. "Author-able" Content Types typically translate into Tridion Component Presentations.

Content Type      Schema   Component Template   Functional Description
Article Summary   Article  Article Summary      Show title and description/summary
Article Full      Article  Article Full         Show title and richtext

Ideally schema names relate to content types, but you could have a List of Links or Link List become part of a Right Rail component presentation, for example.

As a (small) part of information architecture (IA) the best tools for this content analysis would be pencil and paper, a whiteboard, and/or your favorite diagramming tool (but there are more tools online).

For an existing or in-progress Tridion implementation, you can use:

• PowerTools 2011 Documentation extension (to get a schema definition in .rtf with 2 clicks)
• Core Service to gather schema-template relationships to reveal any inconsistencies
• Templating (TOM.NET or XSLT) to get template, schema, and field details (as HTML even)
• Event System to possibly enforce something, but this is overkill especially if an organization hasn't/won't define the naming conventions themselves

Post-Implementation In Tridion

Tridion has many ways to then get these design decisions into the implementation. If the implementation team re-purposes these diagrams, preferably as web pages, then optionally have:

• Custom URLs link to content type descriptions
• Custom Pages link to page type definitions
• Experience Manager (XPM) Page Types preview their page type definitions (a setting controls the preview pop-up)

We also have ways to minimize the impact of inconsistent naming conventions on authors. Consider:

• Renaming or optionally localizing schema names and field descirptions (careful with code that depends on schema names but fields name aren't localizable)
• Setting default schemas on folders so authors can create components without selecting a schema
• Page Templates and Content Types can have icons in XPM (hard to get a name in there, but "box" or "pod" might work) :-)
• XPM Content Types have names (and create components with names) independent of their schemas

Like any other information system, Tridion consists of people, process, and technology. The technoloy tools should match the environment. To get consistent naming conventions all you really need is to add some IA to the process and maybe include some pictures.

Answer 2

I'm unaware of tools which can help you here, but I always suggest to adopt the language of the Content Editors as leading in these situations.

The Schema and Templates should get a logical name for the Content Editors to understand where and how they can use it. From that point on-wards it makes sense if the Developers follow the same naming convention.

In that process you might need to create a translation document between the Designers naming and the Content Editor terms (this can can be used by the Developers to understand what is what).

Answer 3

It's all very well to say that the content team is leading in this, but often they are not the ones who benefit most from consistent naming, so they are not highly motivated to push for a good result. Having said that, on more than one occasion I have approached a content team and said something on the lines of "Consistent naming is necessary for us to develop and maintain the code. There are also benefits for you, and definitely benefits for the communication between us, so please will you help". In other words, the benefits for the content team are marginal but tangible, but when you say it's much more important for the technical team, they will almost certainly "get it" and be willing to play their part.

If there is established terminology in use by the content team, then of course, in that sense it is leading, but only if the established terminology makes sense. I worked with a team that routinely used three different names for what we ended up calling an 'overlay'. The code-base was also suffering from this. In the functional design, I added a paragraph addressing terminology, and by the time the design was accepted, this also included the terminology decision.

So please don't write a translation document if you can at all avoid it. It's much better to agree a common glossary and if necessary, have it be a formal part of your designs. At the least, your discussions between the teams will get easier.

Answer 4

I think this is more related to the project management- The only thing that will help you out in this scenario is The PROCESSES. Have a process around this in your software execution env.

1) Create a Naming convention guideline to follow by HTML as well as template developer

2) Code review by a lead,arch or pm

This would ensure the consistency at least before the delivery.