SharePoint Intranet: How We Did It, Part 3: Discoverability, Nav, and Portal

I'd like to continue my explanation of how I built the SharePoint intranet for NBC Olympics with a look at how I addressed some of our key usability requirements related to discoverability and navigation—in short, the “portal” functionality of the intranet.(Part 2 tells about making the home page easy to access; and Part 1 details the Intranet requirements.)

To clarify language, from my perspective, a portal is a presentation-layer discussion that “pulls together” resources that a user needs to get his or her job done—a gateway [“portal”] to what they really need.

Before I dive into details, I am happy to announce that I will be delivering my first events in the gorgeous country of Switzerland next week. IOZ, an organization based in Sursee, has invited me to lead a discussion on SharePoint 2013 next Thursday (06 September) evening at 16:00. It will focus on business, IT, and development considerations regarding SharePoint 2013. The event is free—you can register at the IOZ site. The following Friday and Saturday, I will be joined by eight colleagues—experts from Microsoft, from the MVP community, and from IOZ—for a two-day SharePoint 2013 “Boot Camp,” presented at the Wellness Hotel Stoos. For those of you in the area, I hope to meet you!

Now, let's look at discoverability, navigation, and “portal.”
 

The Requirements

I laid out our requirements in the first installment of this series. Requirements in this week’s “usability” discussion came from desired outcomes and constraints. This was the desired outcome: A single point-of-entry for most or all of our online tools, apps, resources, and content. Effectively, anything that wasn’t a dedicated system or installed as software on the local machine should be easy to get to from one place.

The constraints included the following:
• No resources (lack of time, primarily) for customized navigation or branding
• No time to train up to 4,000 users; it had to be instantly and self-sufficiently usable (i.e., “discoverable”)
 

The SharePoint Intranet Portal: 3 Approaches

What I decided to do for the “portal” was to leverage three easy, out-of-box approaches to “pulling together” the variety of tools and resources our users need to work.

1. Build In SharePoint

We delivered some business solutions directly with SharePoint. We did our data and file sharing within SharePoint, and moved several formerly paper-based processes into SharePoint workflows.

For example, we have a pool of “runners”—mostly interns who are there to do whatever is necessary to support the production—and we built a runner request and assignment solution using InfoPath forms and SharePoint Designer workflows. All of the solutions in this category fit the typical collaboration and business process automation workloads.

2. Present Applications in SharePoint Using Page Viewer Web Parts

We have several applications—.NET web applications—that automate certain processes like equipment management, laptop checkout, and user provisioning. We presented these applications in a way that made them look like they were part of SharePoint.

We did the same thing with printer deployment—we presented users with a view of available printers that they could simply double-click to deploy. It appeared to be part of SharePoint though it wasn’t.

These solutions were integrated into SharePoint using standard Page View Web Parts. Three such solutions are shown below, and I’ll be discussing the printer installation solution in a later article.

 
Figure 1 (click image to see full-sized version)

Figure 2 (click image to see full-sized version)

 
Figure 3 (click image to see full-sized version)

As you probably know, a page viewer web part is effectively an IFRAME. There are several considerations when using this approach.

• First, it’s an easy way to present an existing web-based application, tool or page within SharePoint. Navigation to the app is through the standard SharePoint navigation controls, and users are none the wiser that the tool isn’t actually part of SharePoint.
• It’s also easy in situations, like ours, where it is more efficient for developers to develop off of SharePoint (in fact, these are legacy apps built before it would have been reasonable to do them on SharePoint). It would be completely reasonable in many scenarios to wrap those .NET applications in a Web Part, but for what we were doing, the time and resources we had to do it, and the fact that these were short-lived solutions, this worked perfectly well, and could be accomplished by me as the solo SharePoint “shop”, without cracking open Visual Studio.
• You do have to consider the size of the page viewer Web Part. Unfortunately, IFRAMEs and the like cannot auto-size to the content they present, so you generally have to resort to setting a fixed size. In our case that worked, and we set a size large enough to prevent the “double-sets-of-scrollbars” problem.
• The page you’re framing needs to have minimal branding and navigation of its own. Otherwise you end up with too much clutter and duplicated navigation controls (e.g. two top navigation bars: one from SharePoint, one from the app). Over time, we’ve reduced the “surrounding material” on our web apps so that we could present them within SharePoint or users could go directly to the web site of the app, with a good experience either way.

Of course, at the highest level, the general approach of building apps off SharePoint then using SharePoint as the glue and the portal is exactly where the trajectory of SharePoint is going. SharePoint 2013’s service-based structure and new app model allows apps, off-box, to integrate very nicely into the broader SharePoint user experience.

3. Use Links

When we couldn’t integrate easily into SharePoint, we simply included links—generally in the global (top) navigation—to the application or resource.

With these three simple approaches, we could pretty much start any user at the intranet home page: http://oly2012, and with one navigation choice, get them to what they needed.

NAVIGATION AND DISCOVERABILITY

For our needs, we wanted to provide simple navigation to resources within and external to SharePoint.

We focused on the intranet home page. We used the global (top) navigation on the intranet “home” site collection to get people where they needed to go.

I could have gotten all fancy and scripted, but given the variety of other priorities I had, we simply added new links manually to the global navigation as solutions were plugged into the environment.

In many organizations, there’s a feeling that each business unit, department, or function feels that it’s resources and links are “most important.” Everyone thinks their links should be most visible and easiest to get to.

That’s a political and cultural battle that I, fortunately, did not have to fight in this environment. As the sole member of the SharePoint Governance Team (LOL), I got to decide where links went. There were often discussions about navigation, and sometimes the business owner had good reasons, which I listened to, for increasing the visibility of their resource, but in the end every navigation choice was made based on what the end users actually would do with the intranet.

And because London was my fourth Olympics with SharePoint (we started in Torino with Windows SharePoint Services 2.0), I was pretty well aware of what users needed, how often they needed it, and how “easy” (visible) something needed to be.

You can see the resulting categories in the screenshot below (FIGURE 4).

You can see that the first few links in the global navigation are actually single-click links to specific resources. The further to the “right” you go, you get into “menus” of options, with more universally-needed menus first (e.g. the Help Desk menu, which included self-service printer and application installation options for users), followed by commonly-needed technical and non-technical resources, and finally the “Departments” menu, which linked to team sites.


Figure 4 (click image to see full-sized version)

If we had gotten particularly fancy, we could have used audience targeting to show and hide links, but given the nature of our business, where almost everyone might need almost anything, we decided to keep navigation completely consistent across users.

The left navigation (the “Quick Launch”) on the intranet home page had other resources that are needed very regularly by lots of users. Again, the SharePoint Governance Team (me) decided (with input) on what deserved to go there.

Many of our business owners, and even the IT team, wanted to put a list of links (a standard SharePoint links list) on the right, but I convinced them to keep all navigation on the top and left. Personally, I hope to stop using left navigation for any inter-site navigation for our next intranet in Sochi for the 2014 Winter Olympics.

I want the left navigation to be used only for intra-site resources (lists, libraries, apps within a team site, for example)—nothing “out” to another site. So left navigation is “current context” rather than “to new context.”

The result, we could tell any user to go to http://oly2012 and click once (or one menu and a link) to get to any resource. But we found that most users just “figured it out” on their own.

The intranet home page itself was purely a “landing page” and portal from which users navigated to what they really needed. We did put a photo rotator on the home page to make it “pretty and fun” and we put some critical, all-employee notices in a customized Announcements list view on the home page.

Finally, we had links to our daily newsletter (on the right). But the home page was very clean, and very focused on getting users off that page quickly. Our focus on that goal, and on really thinking about what users really needed—not what business owners wanted users to see—made for a clean, discoverable navigation that was easy for everyone.

The final navigation note is that we used the “site icon” in each site collection as a link back to the intranet home page. Rather than branding the master page with an additional logo (for example, in the top left corner), we customized the URL attribute of the site icon, and used a very small logo there.

I’ll return to this point in later weeks, as we discuss branding. But the bottom line is that, no matter where you were in the SharePoint environment, clicking the small and unobtrusive logo in the upper left took you all the way back to the intranet home page, http://oly2012.

Now let's go to part 4 of the SharePoint intranet "How We Did It" series!