Tag Archives: navigation

Adding the Top-Level Site Title as a Navigational Aid

I’ve had an interesting requirement show up in the last few projects. All of them were public-facing, and they wanted to have a navigational aid above the quick launch to show the top-level site title. In other words, if the site is contained within a top-level site called “What We Know,” then above the quick launch that text will show up to aid give the user an additional aid in understanding what section of the site they are in.

Site Title Above Quick Launch

I had no idea how to accomplish this so I reached out to my talented co-worker at Portal Solutions Carlos Fernandez. Carlos was able to give me an interesting and reusable solution I’d like to share. I take no credit for this code. I modified a part of the jQuery to pull in the anchor, but the approach and everything else was his work.

Including a Custom AspMenu

The first thing that has to happen is including another instance of the ASP.NET AspMenu control, but it uses a custom sitemap provider with custom attributes. Notice that it has a custom SiteMapProvider, and it has a StartingNodeOffset value. I also use the SharePoint:ProjectProperty control to give the title and URL of the root site; the reason for this is that the AspMenu renders nothing in the root site since it’s using an offset.

<span id="siteTitleValue" style="display:none;">
 <PublishingNavigation:PortalSiteMapDataSource
	ID="SiteTitleDS"
	runat="server"
	EnableViewState="false"
	SiteMapProvider="CombinedNavSiteMapProvider"
	StartFromCurrentNode="false"
	StartingNodeOffset="1"
	ShowStartingNode="true"
	TrimNonCurrentTypes="Heading">
  </PublishingNavigation:PortalSiteMapDataSource>
  <SharePoint:AspMenu
	ID="SiteTitleNav"
	runat="server"
	EnableViewState="false"
	DataSourceID="SiteTitleDS"
	UseSeparateCSS="false"
	UseSimpleRendering="true"
	Orientation="Vertical"
	StaticDisplayLevels="1"
	MaximumDynamicDisplayLevels="0"
        CssClass=""
	SkipLinkText="<%$Resources:cms,masterpages_skiplinktext%>">
  </SharePoint:AspMenu>
</span>
<span id="rootSiteTitle" style="display: none">
	<SharePoint:ProjectProperty Property="Title" runat="server" />
</span>
<span id="rootSiteUrl" style="display: none">
	<SharePoint:ProjectProperty Property="Url" runat="server" />
</span>

Using jQuery to Surface the Title

Using jQuery we can pull the top-level site title that the subsite is contained in and display it in custom HTML without all the HTML from the AspMenu. First is the HTML you used to embed it in the desired location. This uses a heading one which if you use that element elsewhere you might want to downgrade the header (as a semantic best practice you keep a single h1).

<h1 class="siteTitleDisplay s4-notdlg"></h1>

Here is one example where you don’t need the title to be an anchor. Notice how the PrepareDisplayValue function deals with the root site, because as mentioned above the menu doesn’t render anything for the root site.

jQuery(document).ready(function ($) {
var titleText = $.trim( $("#siteTitleValue .menu-item-text").text() );
$(".siteTitleDisplay").html(PrepareDisplayValue(titleText));
function PrepareDisplayValue(titleText) {
	if (titleText.length == 0) {
		var titleText = $("#rootSiteTitle").text();
			return titleText;
		}
	else {
		return titleText;
	}
}
});

If you want to include the anchor to the top-level site you can use the following jQuery snippet.

jQuery(document).ready(function ($) {
var titleText = $.trim( $("#siteTitleValue .menu-item-text").text() );
var titleURL = $("#siteTitleValue a.menu-item").attr("href");
$(".siteTitleDisplay").append("<a href='" + PrepareUrlValue(titleURL) + "'>" + PrepareDisplayValue(titleText) + "</a>");
function PrepareDisplayValue(titleText) {
	if (titleText.length == 0) {
		var titleText = $("#rootSiteTitle").text();
		return titleText;
	}
	else {
		return titleText;
	}
}
function PrepareUrlValue(titleURL) {
	 if (titleURL == undefined) {
		var titleURL= $("#rootSiteUrl").text();
		return titleURL;
	}
	else {
		return titleURL;
	}
}
});

Visual Demonstration of Folders vs. Metadata for Classification

Of all the posts I’ve done on this blog relating to SharePoint, my article denouncing folders is by far the most popular. I later wrote about improvements to folders in 2010, and this video is a culmination of those two posts. I was asked in the comments on the former post about a visual representation explaining why using custom content types and metadata is superior then just using folders to classify content. I looked to see if anyone had done something like it already, but I surprisingly couldn’t find anything.

This video demonstrates two extremes, and I also explain the technological improvements that allow you to walk the line between then. It is still important to note, however, that folders still fall short as a classification method. SharePoint provides a great opportunity to rethink how information should and could be classified to maximize your organization’s information and assisting others in finding it. I also mention a post on documents sets by my friend Michal Pisarek that can be found on the Microsoft Get the Point blog.

19 Replies

Making DHTML Menus Suck Less

There are designers on both sides of the DHTML menu issue. Some are liberal to use them and have no issue with them, and there are others (including myself) who think it’s not the ideal solution to a navigational structure. Navigation is unquestionably the most important part of any web application, and if it is poorly implemented it makes your application unusable and, more often than not, no one will use it.

I think most DHTML menus are simply a band-aid for poorly conceived information architectures. There also is this idea that has stuck for the last decade that everything should be “within three clicks” as if have four clicks suddenly means the application is less usable. In truth it is a myth: “The reality is that users have no problem with clicking, as long as they are confident they’re heading in the right direction.” Since most of the time designers simply use existing complex information architectures instead of honing and refining them they default to DHTML to expose all of their site structure.

Let’s look at of the reasons that DHTML menus suck, and I will elaborate on several below:

As mentioned, often times DHTML menus are used to hide bad information architectures.
Many DHTML menus have no visual indication that there is a menu beneath it.
Users become frustrated when they have to follow a complex path for a sensitive menu.
Navigating by a keyboard loses its luster when using DHTML.
DHTML menus are often not built with the ability to designate where the user is at in the site structure.
These menus are often inadvertently activated by a browsing user leading to a jarring experience.
Even though this is less of a problem then it was even five years ago many DHTML menus use horrendous markup, inline styles, and inline behaviors that fail to degrade gracefully.
Some DHTML events, such as onmouseover, are becoming obsolete with the rise of multitouch devices.

DHTML Menus and Information Architecture

Before deciding that a DHTML is the way to go most designers don’t want to work a client through a process of investigating the information architecture to see if the application even needs the DHTML. Do you really need three different levels in your menu? Have you done a proper card sorting exercise to determine the ideal labels and structure for your navigation? Can you implement secondary navigation on pages that will compliment a more global navigational structure instead of having to expose all that content in a single menu? These are some of the questions to consider if your application truly needs the DHTML.

DHTML Menus and Indicators

I am literally amazed at the amount of sites I visit that fail to use any kind of indicator in their DHTML menu to tell the user there is content to be exposed. Most commonly when an indicator is used a down arrow or something close is used to designate that there is content beneath the navigation element. Below are two screenshots of sites that do and don’t use the indicator.

No indicators on Best Buy, Microsoft, and even Portal Solutions.

Sites with indicators include SharePoint 2010, Reuters, and Google.

DHTML Menu Sensitivity

Another issue that frusturates users is how sensitive DHTML menus are. If a mouse cursor accidentally slides off the menu the entire thing collapses and you have to start over. If the DHTML menu has multiple levels this can be even more frustrating! The complexity of so many DHTML menus is often the thing that makes them the least usable.

In addition to the menu accidentally collapsing, DHTML menus also have a tendency to expand even when the user had no intention of opening it by initiating the onmouseover event unknowingly which can be a jarring experience. This is especially bad when it is coupled with no indicators as mentioned in the last point.

Getting Lost in the Navigation Structure

One of the primary purposes of navigation is to inform the user where they are at in the site structure. DHTML menus are notorious for never showing where some is at in the site/navigation structure or where they’ve gone (the latter is less of an issue in my opinion for a navigation structure). A user is often left asking themselves, “Where Am I?” Proper and helpful navigation should at the very least designate where they are in the site as it corresponds to the navigation.

Often this has to be done with a dynamic programming language to allow the menu to show where the user is at in the navigation. An example I can show is how WordPress chooses to implement this functionality.

A Remedy: Superfish

One of the best implementations I’ve seen of DHTML is the jQuery plugin Superfish. It is based on the Suckerfish style of markup which is ideal when putting together navigation on the web. While I don’t gravitate towards DHTML, if you’re forced to use it by a client or some other circumstance then this is the best solution I’ve found.

Suckerfish is an ideal solution, because it deals with many of the issues I’ve mentioned above.

There is an option for timed delay on mouseout. This alleviates the issue of someone accidentally mousing out and not having to start the menu traversal all over again. It can be adjusted to the best timeout for your audience.
Keyboard navigation is fully supported.
It supports the awesome hoverIntent jQuery plugin so it won’t accidentally fire when moused over. It also supports a new variation on the hoverIntent plugin called $.event.special.hover.
It can automatically add arrows for you when there are menus beneath, but it also has a specific CSS class attached to those nodes that you can add whatever you’d like to designate content beneath the current menu item.
It uses solid markup, and it offers a lot of custom classes added throughout the menu to style various states and elements.
There are many examples showing you horizontal, vertical, and other variants on the menus appearance (check out the “nav-bar” example which I like a lot).

Conclusion

While I still firmly believe DHTML menus are not the best solution to the problem, Suckerfish at least provides as usable as an alternative as I’ve seen. DHTML still, I believe, is not necessary when constructing good user interfaces with good information architectures. It is a quickly deteriorating technology due to the use of multitouch devices, but if we’re going to use it we might as well make is as usable as possible.

Siolon

Musings on SharePoint, User Experience, and More