Mega Solutions for Mega Menu Problems

I’ve been working with Sitecore since 2009 when I began my career as a web developer. Here are a few things I’ve learned about navigation along the way.

Everybody loves ‘mega’ menus. Every website I’ve ever worked on (bar one) has a mega menu. They’re a quick way to get users around your website to the important bits without lots of scrolling. Here are a few approaches to building them in Sitecore.

Use the content tree

How: Create a base template all potentially navigable page items will inherit from with a checkbox field indicating whether or not that page is navigable. Then, either create another base template for panels, or integrate it into the navigable item base template and tell users to ignore the extra fields depending on where the page is.

Pros

  • No additional items needed.

  • The navigation follows the structure of the tree.

  • If you have simple navigation panels, you can get away with just having one template that covers all the bases.

Cons

  • Depending on how flat the site is and how MEGA your mega menu is, you may have to scan a lot of items to build it.

  • If you want many different, detailed panels, you’ll need to create variant templates that have those fields and are only used at the top levels of the tree. This can lead to a scenario where you have several versions of each page template depending on where it will be used, causing confusion for authors, or dissatisfaction when they discover they can't have just any panel they want for a given item.

Create a navigation data tree

How: Create data templates for different types of navigation elements as they appear in the mega menu. Then, construct a tree representing the structure of the menu in the data area of your website.

Pros

  • Authors can easily see and understand what’s what, and how to set up the different elements.

  • For the few instances where an author wants there to be a contextual link that doesn’t reflect the site’s structure in the content tree, they can do it easily.

  • You can have dozens of different mega menus defined and used arbitrarily across the site.

Cons

  • Since it’s not tied to the actual website content tree, they can become wildly divergent.

  • Authors can create relationships that aren’t reflected in the content tree, turning your website's navigation into a rats’ nest of links.

  • Authors may not understand that there are two items in separate parts of the site representing the same content.

Use data items in the content tree

How: Create data templates for the different types of navigation elements as they appear in the mega menu. Then, to add an item to the menu, an author would create one of these navigation items as a child of a page item, or in a handy-dandy data folder to keep things tidy.

Pros

  • Using rules, you can control the available insert options for an item, making it clear at any point what options are available to an author.

  • Your page templates don’t have to care about their navigation data, except perhaps to indicate that they’re navigable items.

Cons

  • You have to scan even more items than with the content tree approach, depending on how deep the mega menu goes and how wide the site is. Even with caching, this can take a while for the first unlucky customer to load it.

Conclusion

I try to keep menus shallow where possible. If users want to link to a special item that’s deeper in the tree because it’s dear to their heart, you can use a redirect class that represents that link in your content tree, or move the item if that’s an option.

Comments

Post a Comment

Popular posts from this blog

Quick Fixes: Rendering Parameters and Standard Values

Although the rendering parameters editor uses a template to define itself, it's important to remember that it does not actually render standard values--even though those values show up when you view the editor. This makes sense; the template is used to control what fields are exposed for editing, rather than to define a data structure for an item, and the editor must rely on the same methods that are used to populate the item editor. There isn't really a good way to get around this, because of the way the information is stored in a parameter string. Sitecore never asks for field values when it calculates the parameter string, only whether or not the key is found in the string. So, in my opinion, the best practice in this situation is to tie these values to the datasource item instead of the rendering parameters, and to avoid setting standard values for rendering parameter templates at all. This way you can take advantage of standard values without confusing your authors.
Read more

Quick Fixes: Language Ordering

Say you want to add a language switcher to your site. Simple enough, right? Now say your users want to control the order the languages appear in. Somewhat surprisingly, when you get languages from an item or from the context database, the order they're retrieved in doesn't reflect their order in the content tree. To work around this, you can retrieve the associated items and order them by their sort order using the LanguageManager.GetLanguageItem(language, database) method.
Read more