Please see below slides for the discussion we hope to have initiated in the Community Webinar held on the 14th March 2012.
Essentially, as a wise man once noted, there are as many ways of rendering navigation as there are Tridion Consultants… The purpose of this discussion is for us, as a community, to share and discuss our experiences.
Please feel free to post links to blogs with specific examples but ideally here we would have more of a discussion of why we would choose one method over another (implementation timescales, environment, editor requirements etc.) and whether, on reflection, previous decisions would be the same…
Let’s talk….
I have not had a chance to watch the Webinar yet, but I have followed the discussion a bit after Chris’ example of a Taxonomy driven navigation. Personally that seems for me the way to go as well. However, you won’t avoid having to use the three digits in the description to get some sort of sorting, I guess.
Which brings me to my most commonly implemented navigation in a WYSIWYG manner. The structure groups have three digits in front for sorting purposes. And you publish some sort of navigation XML. Advantage is that for the webmasters it is immediately clear where a page or navigation item can be found in Tridion and vice versa. Disadvantage is of course that sometimes this navigation XML can get really large and slow, and more and more functionality gets added to it (which makes it even more slow).
In a Tridion R5.2 implementation at a customer we were using an old navigation builder custom page (co-developed by Chris Summers I believe), which was working nicely as well with sorting and more. But, this one was extremely difficult to modify or add extra functionality to. And would sometimes be confusing for webmasters. (it was a nice tool however!)
The last couple of ASP.NET sites I’ve worked on have been using the same technique Hendrik describes – structure groups sorted by numbering published to a “.sitemap” file.
I’ve also seen category/keyword + keyword metadata using Bart’s Item Selector extension (http://www.sdltridionworld.com/community/2011_extensions/itemselector.aspx), published to a “.sitemap” file – to allow editors a degree of flexibility over exactly which page acts as the “root” page for a given section.
I’ve seen:
– Non-Tridion, not handled by Tridion
– XML Sitemap (as Niel describes), Tridion generates and publishes a XML navigation (sitemap) file, transformed on front-end using XSLT, .NET, or other framework.
– Facetted, taxonomy-based navigation using categories and keywords (nice stuff, Chris Summers, Yale, and other examples)
“Non-Tridion” seems appropriate for setups where style, design, and structure decisions are outside of the content organization. Tridion may have authors, but they may publish dynamically and typically don’t create Pages. The development team sets up broker queries or code to query the published content (typically in XML or database or XML in the database).
XML Sitemap seems useful for sites with an existing setup where Tridion publishes the same format to an “in place” setup. This helps manage scope and may help with testing, which can focus on making sure the old and new files matcs. The nodes and attributes will match and may be managed by naming conventions (inlcuding the 3-digit technique mentioned above) and/or metadata.
Facetted navigation looks promising for SDL Tridion 2009 (and up) setups, where the development team is comfortable with the content delivery (CD) side dlls. I say 2009+, party because of nested keywords but also because of the increased availability of examples in recent years. If there’s a “no Tridion CD dll on the presentation server” requirement, then tried-and-true XML-based navigation might be better.
It comes down to finding a “best fitted to the organization” solution, which makes the process of _navigating_ the trade-offs so fascinating and challenging.
As with all architecture level decisions there are many driving factors for making them and they vary in importance for different customers :
– cost
many customers are not on a huge budget and fully customized solutions (gui extensions and all) are expensive over reusing a tried-and-true “standard” solution
– usability
The “navigation follows website structure” metaphore is a VERY potent tool to let your visitors explore your website in full and ensures a short and shallow learning curve for both visitors and content managers. All other methods of generating navigation more or less obfuscate the structure of the site (if that is a requirement that can be a good thing but as a visitor I tend to frown upon sites with unclear site structures…)
– flexibility
The capability to implement various business rules (such as navigation items pointing to external links or downloads, the ability to order navigation items explicitly, navigation items pointing to a redirect, having both structuregroups and pages as navigation items, having items in the top but not the left navigation, etc).
– maintainability
The more code the solution requires the harder it will be to maintain. Re-use of existing code will also help drive this down as “stable” code reused from existing solutions is expected to generate less bugs over time.
– performance
The tradeoff is usually render performance vs runtime performance but there are optimizations possible for all Tridion based scenarios with respect to both render and runtime performance. Using Tridion 2011 usually eliminates the “publishing single page with all navigation data” publish performance issues that plagues pre-2011 implementations that followed this model…
In my opinion the commonly used “publish structure as XML and transform with XSLT at runtime” scores relatively high in all areas but never scores top marks anywhere (except maybe usability). Especially cost-wise it is very hard to beat and most of the customers i’ve worked with tend to be budget-constrained…
Interesting article with YetAnotherNavigationMethod… http://www.createandbreak.net/2012/12/yet-another-sdl-tridion-navigational.html
As a follow up to the Component Presentation-related approach for navigation, I’m seeing content drive navigation in more projects. You’ll find “flatter,” less nested content models when settings up Tridion for Experience Manager, SmartTarget, Campaigns, or Mobile. Pages either have regions or will expect (dynamic) Component Presentations.
This would still complement the Structure-based approach, which has two other points in its favor:
– “cut and paste” control over URLs and page nesting (useful when the client want specific URLs as part of their SEO requirements without needed any redirect logic)
– dynamic linking, where from a given site “section,” you can manage links to the same set of items, but in different Structure Groups