Big news in the beginning of this week. No, I'm not back to school :) I recently accepted a new job as an internal SharePoin employee for a company which is not yet an enterprise, but not a startup either. It will be very different than all of my past experience at service providers and consultancy engagements, but I am excited as it's a very innovative organization and we met when it's just about time for some SharePoint(ing).
Now to the point... one of my first tasks is to create the organization's navigation structure for an Intranet portal. We will use Managed Navigation after an evaluation and demos of all the possible methods. I will do this on SharePoint Online for the example, but the method is the same for SharePoint 2013 as well.
The decision to use Managed Navigation is not the scope of this post, a
very good comparison by Microsoft is published here, which evaluates performance, needs and in fact all pros and cons.
One of the main requirements is for the Current Navigation to become collapsible, imagine a Windows Explorer style...like the following example. Now, if you have users that will be switching from file shares to SharePoint, that type of navigation might come handy. I personally don't really like the fact that it does go very big when you expand a lot of nodes, but there's a solution for that.
If the SharePoint site structure becomes deeply nested e.g. Site Collection -> Site -> Site -> Site ... this will also be a pain to navigate in, and most users would most likely prefer the Search option (I got this feedback after conducting a few user interviews and demoing this type of navigation).
Let's review the options to achieve the closest functionality in the SharePoint Current Navigation.
We assume we'll only have one site collection, which is nowadays common for small to medium sized organizations. Especially if you go the SharePoint Online route.
Option 1: Tree View
The way to enable this is simply going to Site Settings -> Tree View -> Enable Tree View.
The Tree View looks like this in a site collection (left) and respectively in a site (right):
Now, I'll share my view, based on experience around this functionality.
Pros:
- Sites are automatically added, no admin overhead
- OOB solution. No custom master page need, hence sticking to the Office 365 best practices.
- Displays lists and libraries in addition to the sites
- Easy to use, nice icons on the left, indicating the type of each node - that's all OOB again.
Cons:
- NOT security trimmed!
- Displays the Apps (add-ins) as well, no way to hide those. The regular user might not need them.
- Can take a large part of your screen and becomes unusable if you need too much scrolling
- Enabled per site level only, e.g. you need to save your site as a template and create new sites based on that if you need Tree View enabled by default
- NOT consistent accross sites. E.g. does not show the parent navigation when you're in subsites.
- NO way to customize it OOB, needs custom CSS (not a big deal, you still don't need to modify the master page for that and the OOB view might suit you just fine in some scenarios.)
Option 2: Managed Navigation + custom CSS
The Managed Navigation requires some planning, manual work and a lot more maintenance then the Tree View. The way to enable it will be out of the scope of this post, but just don't forget to enable the Publishing feature on your sites before you switch to this navigation. It's a prerequisite.
The way it looks in a very quick and simple demo is this:
But it's not collapsible by default!... Even though there are some articles online suggesting the use of
fly-out menu I personally didn't feel it's good enough (e.g. a lot of levels will take a lot of space oon the right of the designated navigation menu control)
There's
another solution which uses jQuery and provides the "accordion" feeling. But this will generally work if your items that you want to expand don't have a hyperlink. E.g. if in the above screenshot Operations doesn't point anywhere, then it would make sense to expand it with a click and see its children. But in our scenario the 1st level items would be links to actual sites...the solution still works... but in order to expand the children, you'd need to wait for the parent link to load. Not good, could be annoying for users and the link might point you to a site which doesn't inherit the same navigation.
So... to just quickly review the Managed Navigation against Structured Navigation and the alternative Tree View option... read further.
Pros:
- Consistent across all sites if you inherit navigation in the subsites
- Very good for public sites or extranets, where you don't want it to definitely reflect your site structure.
- Better performance than the structured navigation
- More compact than the Tree View and very good looking when customized
Cons:
- Sites are not automatically added, it requires some maintenance
- Not security trimmed.
- Not collapsible OOB for use in Current Navigation. Needs custom CSS and potentially JavaScript.
- By default it's set to display only 2 levels of hierarchy - e.g. Projects site -> Project X subsite. If you want to display libraries and lists for example, or anything else... you need to touch the master page.
Now on the collapsing functionality... you can achieve that by using some simple css. Take the example a few lines below and save it somewhere on your SharePoint site. For the demo I've used a file, called sideNavBox.css and I've put it in the Style Library.
I got the original idea from
Dércia Silva at broculus, but that solution seems to work well only for small navigation structures. I don't see it working with more than 2 levels and it requires you to click on a menu item (e.g. a site) to see its children.By default SharePoint will load the site if there's a valid link behind the navigation menu item. Not too good, you might have clicked on it by mistake, and you might not want to wait the load time (imagine it's a heavily customized site). It also uses jQuery, while I think this functionality can be achieved by CSS only.
So I decided to use the :hover pseudo selector instead of the .selected class to address the need for the click issue.
/* Do not show nested ul by default */
#sideNavBox .ms-core-listMenu-verticalBox ul ul {
display: none; !important
}
/* Show nested ul on hover only */
#sideNavBox .ms-core-listMenu-verticalBox ul li:hover ul {
display: block; !important
}
Now you need to refer your site to the custom CSS file. Go to Site Settings -> Master Page -> Alternate CSS URL (preferred solution):
...or if for some reason you can't do the above, then as a last resort insert it in a custom Master Page directly by putting this line in the <head>. (change the path to your CSS). Please have in mind that custom Master Pages in SharePoint Online should be used if no other customization option exist. The reason behind this is that you''ll end up not getting regular updates on master page functionalities released by Microsoft (they only deploy these to the oslo and seattle master pages).
If you're interested in the way Office 365 Sites branding is going forward, I recommend this great explanatory
session by Vesa Juvonen. Then you can decide... to brand... or not to brand :)
If you do decide to ignore the recommendations, here's the control you need to insert in your master page...
<SharePoint:CssRegistration Name="Style%20Library/en-us/Themable/sideNavBox.css" runat="server" />
So, with the hovering trick and some more customizations I've added the nav menu looks like this. Currently I am hovering over the PMO link which is a site in a site collection (could be anything) and Project 1/2/3 are sites under PMO (again could be anything you add in the Managed Navigation through the term store management tool)
The extra styling is just for some similarity to the Tree View menu (the icon is a shameless steal from there)... The "Edit Links" item is hidden and colors/sizes are slightly changed. Some cheeky icons added on the left to make it look more intuitive, too. Pretty basic for the means of our example today:
Here's the additional CSS I applied:
/* Any style you want for the left-hand nav control*/
#sideNavBox {
background-color: #DBE8F3;
}
/* Making some room for the icons on the left */
.ms-core-sideNavBox-removeLeftMargin {
margin-left: 5px; !important
}
/* Insert the plus icon for the ul */
#sideNavBox ul {
list-style-image: url('/Style%20Library/Images/Expand_01.gif'); !important
}
/* SP treeview expand icon for the nested ul */
#sideNavBox ul li ul{
list-style-image: url('/_layouts/15/images/tvclosed.png'); !important
}
/* Hide the Edit Links button in the current nav */
.ms-listMenu-editLink {
display: none; !important
}
And now to the levels... we have the requirement to display more than the two level of hierarchy on the screenshot above. Now if you get to this, and you definitely want to use Current Navigation (rather than Global Navigation) for this (regardless of the fact if you use Structured or Managed Nav in the background) then you need to edit your Master Page e.g. use a custom Master Page in SPO.
So, in a bit more details:
1. Create a blank master page
2. Open your seattle master page and copy all the code to the new one.
3. Go to the V4QuickLaunchMenu control.
<SharePoint:AspMenu id="V4QuickLaunchMenu" runat="server" EnableViewState="false" DataSourceId="QuickLaunchSiteMap" UseSimpleRendering="true" Orientation="Vertical"
StaticDisplayLevels="3" AdjustForShowStartingNode="true"
MaximumDynamicDisplayLevels="0" SkipLinkText="" />
To properly achieve your goals, you might need a bit of clarifications on this above piece of code.
StaticDisplayLevels are the hierarchical items that will show in the navigation control. You would imagine that this solution will work like a charm and display the navigation representing the term store hierarchy. The problem is, if you increase that to 4, for example, you'll get this due to the lack of space in the OOB control. To visualize what I mean I've shown a small part of the term store managed navigation and the way it was represented after I've increased the
StaticDisplayLevels.
So the expectation would be to see the same structure as on the left hand-side.
... but the reality is different:
Let's look at the solution for this:
MaximumDynamicDisplayLevels are the hierarchical items that will show outside of the control.
Increasing that number will give you the items, but outside of the Quick Launch menu. Not too bad.
This functionality works OOB in the Global Navigation, so it's a good idea to consider that as well.
So... just a slight tuning here, in order to achieve the same styling as on the regular list items, I've had to apply the below CSS (not needed if you didn't use custom styling for this at all).
/* customize the dynamic ul */
#sideNavBox .ms-core-listMenu-verticalBox .dynamic {
background-color: #DBE8F3; !important
}
That's it folks, hope you enjoy your new collapsible current navigation. If not, you can always switch to the Global Managed Navigation - it will collapse by default, it kind of uses the space on the screen in a more rational way and could be customized to the same extent. It's the user preference -horizontal or vertical menus... you could even go for the trendy mega menus in the Global Navigation (more suitable for public websites in my personal opinion anyway).
