Tridion Setup Considerations for End-User

Some gotchas and things to keep-in-mind when setting up Tridion for end-users. I've seen some of these issues a few times with the (internal-to-my-company) teams I've trained.

Architecture Affects End Users
Tridion blueprint design and implementation options are flexible enough to create different solutions for different websites. However consider the effect on end users. If using "index" components as well as individual dynamic component presentations, it means end users will have to understand two publishing paradigms: "Here you remove items and re-publish the list, but here you unpublish the items individually." Ummm, huh?

Additionally adding unexpected target types, changing the frequency for publishing, or showing more publications or folders they typically work with can confuse end-users. Consider using the MMC snap in setting to reduce unwanted folder visibility in addition to separating end-user groups by folder permissions.

Forecast... Content. Lots of Content!
Anticipate growth. Legacy systems or procedures may have introduced artificial bottlenecks when it comes to content creation and release. Don't be surprised to see several times the amount of content, large binaries, and requests outside the original functional requirements such as one-off templates, formatting features, and other details such as hyperlinks.

Unless you want end users to hard-code all links, the templates are not trivial because you may have to handle various scenarios such as:

• internal links to non-Tridion content
• external links (and any disclaimers associated with these)
• links to Tridion components

Scope creep aside, be sure the system design and architecture (design, settings, file space, etc) can handle seemingly simple increases in file size and quantity. Train end-users to schedule publishing of large files or large amounts of content after hours.

Good Templates Help
To avoid rework consider investing in a good functional (feature rich) template early on. As tempting as it is to treat everything as plain text--try to make or use good templates that can handle links and at least basic formatting like emphasis and strong. (Note restricting font styled in schema filters removes centering; consider filtering the style="text-align:center" attribute on the template side or using another work around). End-users judge the CMS by how often they have issues and how much they have to "fight" hack at making it do what they want.

Increase buy-in and long-term satisfaction by making useful templates that can handle rich text formatting, missing binaries, and can do center if it's expected. I'm all for incremental increase, but why get a leading CMS if all it does is output plain text?

On Training...
Though they do so much and we put so much effort into them, I've learned to avoid discussing the details of templates with end-users beyond the fact templates make content look a certain way. Templates are simply a drop-down selection for end-users. Some end-users publish dynamic component presentations (dcp) and may not even be aware of the template that renders the content. To new users or even devs I've found people's definition of "template" is something more like "schema."

Sometimes a dev will forget there's even a template involved with publishing. "I published everything but nothing happened!" "Did you publish the template?" "What template?"

Happy designs and coding!