Mega Menu for SharePoint – Part 2 of 3

This is the second part of a three part series where Heather Solomon and Dustin Miller are exploring the ever-popular “Mega Menu”, and how to create a powerful, styled and functional mega menu for use on your SharePoint sites. After creating the HTML markup and the CSS to meet the functional requirements, it is time to take a look at the importance of taxonomy in navigation and check out the XSLthat will be used for the mega menu.

Please note this article is cross posted on

Taxonomy and Web Site Navigation

Heya! Heather here and one thing I hold near and dear to my heart is web site taxonomy and usability. It is an often overlooked aspect of web site development when a project gets kick started. Be it budget, time or lack of priority, site taxonomy (and by association content requirements) is usually brushed aside, done in a hurry or just flat out kicked to the curb. It is hands down one of the biggest mistakes I see organizations make when they start a web project.

It shouldn’t be this hard

If you are ever feel the urge to read a bunch of 50 cent words peppered throughout a cacophony of statements that is marketing speak meets technical mumbo jumbo, go search online for taxonomy advice. Holy cow Batman, can things get any more confusing? It is pretty ironic that a topic that focuses on creating clear and concise content organization can be so darn confusing. It is no wonder so many projects skip this important step. We are firm believers of cut to the chase and that is precisely what we aim to do here as we walk through some key points of taxonomy and its relationship to great web site navigation.

Looking past the big words, what is taxonomy?

Taxonomy = classification

Classification = another way of saying organization

Organization = groups, associations and labels

Taxonomy is about grouping site content together and creating associations between those groups. Then you label everything so it is discoverable.

It is easy as web developers and designers to get wrapped up with the cool factor of the web. How many different things can you do to your web site to make it sexy? How far can you push the technology and just how tiny can you get all your files? All of those things have their place, but none of us would be here if it wasn’t for the need to get content out to users, and in the most discoverable way possible.

Connecting users and content

In order to make content discoverable to the largest number of users, the grouping, associations and labeling of the content has to be generalized. It needs to be simple and friendly. A great test that can be conducted is to present web site content to someone as if they were a new hire to the company or brand new to your Internet site. Give this person a few tasks that would result in a detailed content search. For example, have the user find:

  • Contact info for their assigned Human Resources representative
  • Product dimensions for installation use
  • Expense report form and how it should be submitted

Immediately the user will mentally label the task with a larger, more general access point(s) where they think they will find the information and then look for that access point on the web site. Everyone scans web pages. Users do not look at each link and carefully consider if that link could lead them to their ultimate destination. Looking at the examples again, here are some likely labels that the user would assign to each task:

  • Contact info for their assigned Human Resources representativeHuman Resources, Contacts
  • Product dimensions for installation useProduct catalog, Product search, Product detail
  • Expense report form and how it should be submittedForms, Employee Services, Accounting

Every user goes to a site with a task and they have already mentally labeled that task with what they think the access point should be. One of the main goals when creating site taxonomy and navigation is figuring out what labels/access points users will associate with their tasks. Those labels should be the site navigation.

There isn’t a magical tool that will generate site navigation. It simply comes down to knowing your content and users and creating a path to that content based on simple and common sense labels, groups and associations. Often these are multifaceted. With the large amount of content in most web sites, there are usually nested groups, several associations and multiple labels for one item of content. This can be tedious to think about but is essential for discoverability.

Mega menu anyone?

Users think in many different ways. Each of the example tasks above will generate multiple labels when the user considers possible ways to find the information. User 1 could easily think “Human Resources –> Contacts” while User 2 thinks “Contacts –> Human Resources”. So what goes into the site navigation? Human Resources or Contacts or both? Pick one for a lively and long team meeting over the subject or do both and watch your navigation quickly spiral out of control with too many options.

There is another path. Use a mega menu to create an educational and/or multi-labeled navigation system. Put in place key words that will catch the user’s eye (they are just skimming the page after all) and tell the user what to expect from a given site content area. Perhaps the user is presented with this:

  • Departments
    • Human ResourcesBenefits, contacts and important forms.
    • AccountingSubmit reports, request payments and contacts.

This could easily be done in another way using multi-labeled navigation:

  • Departments
    • Human Resources
      • Benefits
      • Contacts
      • Forms
    • Accounting
      • Submit report
      • Request payment
      • Contacts

If the site is limited to a more traditional drop down menu, the same level of detail and information can’t be presented in the first glance. Instead multiple fly out menus have to be used (awful usability), or just rely on users to hunt for the information (frustration galore for the user).

When building out content for a mega menu, consider the path the user will take to arrive at that content. What are the labels, organization and associations? How can the information be presented in a clear and concise way that will get people to the right place as quickly as possible with the least number of false starts? Happy users = great site.

I’ll turn the keyboard over to Dustin now for the SharePoint nitty-gritty.

SharePoint List for Nav Item Storage

Now that the CSS and markup is complete (from part one), it’s time to create a SharePoint List to store the navigation items.

Our list is set up with a self-referencing lookup field so that it’s easier to link any navigation item to any other item, making a hierarchy of links. Remember: this Mega Menu has two levels of links, with the second level optionally grouped together.

Get set up

  1. Create a custom list. Give it a name: “navlinks” (you can change the list to have a “prettier” name later).
  2. Update the list settings to include some new columns:
    • URL (Single line of text)
    • Description (Multiple lines of text, with enhanced rich text)
    • Parent Link (Lookup field, connects to navlinks list and returns Title)
      • Under “Add a column to show each of these additional fields”, select ID
      • All other column settings should be left at the default
    • Group (Choice field)
      • Create these choices: None, Products, Services, News, Other
      • Default value: None
  3. When finished, add some data.

Custom Views with XSL

Time to create a custom view to test out the Mega Menu. You’ll be taking the SharePoint list content in XML format and transforming it into HTML using XSL.

Wait, what?

XSL. You know, Extensible Stylesheet Language? I plan to write up a nice SharePoint-friendly primer for a future article. For now, here’s the important part:

One template will create the wrapper around the custom output, and the other template is the repeating section used to build the list items themselves.


The XSL will include two “templates”, which are used to transform the data that comes from SharePoint into HTML:

  1. “/” (which ends up being the wrapper around the repeating section of your output)
  2. “Row” (the repeating section itself)

Things get a little trickier with a list that can be grouped. SharePoint has one way of doing grouping of list items, and frankly, it’s not the most elegant or efficient way of doing it. The XSL for the Mega Menu should be elegant and efficient.

How does SharePoint do it?

When you group list items in a SharePoint list view, the XSL that generates that view loops through each item in the list and compares each line of data to the previous line of data. If the grouped by field changes, the template spits out the HTML that will be used as the new group-by header, and then emits the HTML for that item. If the grouped by field stays the same, it skips the header and just emits the item HTML.

Simple, it seems. But inelegant. It’s nearly impossible to change the CSS styling of elements like this, and the output (from SharePoint’s default grouping template) isn’t truly nested. The Mega Menu requires a series of nested list items.

What the XSL needs to do

Ready? Take a deep breath.

  1. Create a nav element (cuz HTML5 r0x0r5) with a ul child. Inside the ul
  2. Start looping through items that don’t have a Parent Link specified. For each of those items:
    1. Create an li element with a CSS class name based on the Title of the link
    2. Inside the li, create an a element and also the Description (which SharePoint automatically wraps in a div tag)
    3. Create a ul inside the li for the second level of links
    4. Figure out if the second level of links has a Group or not:
      • If yes, the ul gets a CSS class to make it easier to style
      • If no, the ul doesn’t get a CSS class
    5. Render the second generation of links by matching the Parent Link:ID to the current item’s ID
    6. Close the li element
  3. Close the top level ul and nav elements.

Still here? Got a headache yet? Mega Menus are historically one of the harder things to automate with scripting or templating because the relationships can be difficult to ascertain without a hierarchical data source, like an XML file. Most end up being hard coded. By taking a flat SharePoint list with a self-referencing lookup field, this Mega Menu template creates its own hierarchy on the fly.

Enough theory; show me the code

Okay, okay! Here’s the XSL.

That’s all for Part 2!

“Woah, woah, woah. Wait a minute.”

I know. You have questions. You want to know how to use this XSL, how it works, and how to get this mega menu into the master page. So check out part 3 for more.

5 thoughts on “Mega Menu for SharePoint – Part 2 of 3”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.