SharePoint Intranet: How We Did It, Part 4: Team Site Extreme Makeover

Greetings from beautiful Switzerland! Just three weeks after the Olympic Games, I’m back in Europe for a series of SharePoint meetings and events, then in Chicago for SharePoint Fest, delivering my Governance Master Class on Tuesday, September 25. This is my last full-day SharePoint governance workshop in the Midwest in 2012. I’ll also deliver several sessions in the main event, and sign my SharePoint 2010 Training Kit at the AvePoint booth, with a limited number of free copies provided by AvePoint.

Here in my SharePoint intranet series, I continue documenting “How We Did It”—how I built the SharePoint intranet to support NBC Olympics. If you missed previous articles in the series, check them out to get some context and understanding of the environment, the desired outcomes, and our “requirements.”

Now I'll focus on what I did to try to meet our “usability” requirement. Solutions I built had to be instantly usable, with no user training, as we had close to 4000 users, most of whom had zero experience with SharePoint—especially SharePoint 2010—and zero opportunity to deliver training.

My discussion centers on team sites. As it is for many organizations, collaboration was a critical workload—in fact the most important workload that SharePoint supported. To make team sites and collaboration as usable as possible, I focused on several things:

• Simplify, simplify, simplify
• Discard out-of-box terminology for concepts and terminology that users would instantly understand
• Provide inline, in-context, task-based guidance

Let’s look at the details. And as we do, if you’re familiar with SharePoint 2013, see how many similarities you can spot—things that I baked in to SharePoint 2010 to make it more usable, that are now implemented out-of-box in SharePoint 2013.
 

Simplify

I think most of us have a solid understanding that software—especially Microsoft software—can be complex to adopt because too much functionality is placed “up front,”making it difficult for users to get to the features and capabilities they really need.

With that in mind, I took an axe to the standard team site template. The “baseline” team site landing page is shown in Figure 1 below.


Figure 1: The baseline team site landing page (click image for larger size)

I’d like to point out several features of the baseline team site:

• (Almost) zero branding. I’m not a fan of branding SharePoint, especially at the team site level, but even at much or all of the “intranet” level as well. (Navigation is an exception). My experience is that branding makes it difficult to upgrade and adopt new solutions that “plug in” to SharePoint.

Most of my clients are quite large, and they have communications and web content and intranet teams who believe their job is to brand everything and maintain corporate identity, even on internal web properties. I think that, in most scenarios, that’s a complete waste of resources. Especially now that the world is moving to web applications and services.

The question I ask customers who want to over-brand SharePoint is: “So, have you finished branding Word, Excel and PowerPoint? I assume you’ve added your logo to the ribbon, changed the location of the task panes, and modified the color schemes of dialog boxes?”

That snarky question is basically to point out that not everything warrants branding. An app is an app, not a statement of corporate identity. Put those talented designers and communications experts onto workloads that require their help: the public web site and an extranet (perhaps).

You’ll notice the large NBC Olympics logo in the upper right. That's simply an image inserted into the rightmost panel of the layout. It’s content, not frame branding. Putting it on the far right ensured that users with narrower screens would still have plenty of functional real estate… the logo would be “off screen” on the right, reflecting its lesser importance.


• Top Navigation. I treated the header of the page as the primary “portal” navigation. The one “branding” change I made to the team site was change the site icon—the logo in the upper left corner. This is a property of the site collection. I also changed the behavior of the icon, so that clicking it navigates the user not to the top of the site collection, but rather to the home page of the intranet itself (http://oly2012).

This required one change to the master page. I’ll discuss how I deployed that single “branding” change in a later article—it was not with a “SharePoint Solutions Package.” The breadcrumb in the header provides an out-of-box navigation from the site collection “down” to the current location. So if a user wanted to navigate to the top of the site collection, they could click the first link in the breadcrumb—something that users seemed to figure out themselves (discoverability/usability).


  • Global navigation as context navigation. Within a “context,”I used the tabs of the global navigation to give users quick, consistent links to most-used resources. A “context” was a logical construct related to what users were thinking about or trying to do, and generally a context equated to a site collection in the SharePoint logical architecture.

If users wanted to go to the top of the site collection, they could click first “tab” in the global navigation bar. After that, the tabs of the global navigation were used to get users to most-useful content, typically (but not always) subsites of the site collection, but also links to specific lists, libraries, or pages.


• Quick Launch as detailed navigation within a sub-context. I used the Quick Launch to provide more detailed navigation, which could vary within a sub-context (i.e., within a site, rather than for the entire site collection). I made sure that all resources that “typical” users would need appeared in the Quick Launch. The only people who would need to go to “All Site Content” would be people with specific needs to administer hidden content and functionality, for which they would have received explicit instructions to “click the ALL SITE CONTENT link.”

My experience was that these small changes made a world of difference in aligning how SharePoint actually behaved with what users naturally expected from navigation. And the über-clean UI of the team site made content and functionality more easily identifiable.

The one thing I did not do was to remove the “I Like It” and “Tags” buttons of the ribbon. This is definitely do-able, and I wish I had done so from a “purist” perspective, because I don’t like exposing functionality that I’m not preparing users to use correctly, or managing on the back end. But my experience is that users just ignore these two buttons—for whatever reason (they are pretty enough buttons!)—so I just didn’t worry about it.

Exorcise SharePoint Geek Terminology

Notice the Quick Launch in Figure 1. No more “Libraries, Lists, and Discussions.” The first two of those standard team site Quick Launch headings mean nothing to the typical user. After quite some experimentation, I landed on Content and Apps as the standard two headings.

Every team site had two libraries by default: Files and Media. I wanted users to “fall into” the default behavior of storing any kind of file in the Files library.

I’ve found that the default name, Shared Documents, makes some users restrict their thinking to sharing documents (Word and maybe PDFs) but not thinking about sharing Microsoft Visio diagrams, PowerPoint presentations, or Excel workbooks.

Also, the URL for the default library is http://site.../Shared%20Documents which is ugly, versus http://site.../Files. Small thing, but easy to remedy. I wanted users to default to saving pictures, music, and videos to an Asset library which provides enhanced media management and viewing, so I had a separate library for “Media.”

Almost everything else is an “app.” Users "get" apps. The vast majority have smartphones or Apple iPads with app stores, Facebook apps, or have some other experience with the idea that functionality is plugged in with apps. Even discussions—when I added them to a team site—went under Apps.

A couple of points about this approach:

• See a similarity to SharePoint 2013? Great minds think alike, I’d like to think… In SharePoint 2013, everything is an app.


• I don’t necessarily think the SharePoint 2013 answer is the best approach, but as an out-of-box default I think it’s the best Microsoft could possibly do. But I find a distinction between “content” and “apps.” The line is blurry, to be sure—some apps are very content centric. So you have to make a call about what is an app versus what is content.

I’m still experimenting with defining the difference, but for now let me say this: If it’s a library, if it’s mostly simple content interactions (add, view, modify, delete the document), and it’s broadly used within a context, it’s content.

If it’s more about the process, then it’s an app. So a form submission process would probably be an app. Yes, the line is blurry. Think like a user, not like a developer.


• I’ve used this “apps” approach with other clients. The next logical step is to create an app-store-like experience, where, when users want to add functionality to their site, they “request” it. That allows the enterprise to deploy customized solutions and to monitor what is getting added—and, later, used—throughout the SharePoint environment.

Almost everything you see on the team site in Figure 1 is deployed using a provisioned request procedure. Someone (e.g., a business owner) can request a site. A script runs that deploys the site, adds the functionality, tweaks the UI, etc. I’ll be describing the provisioning engine very soon (in the September timeframe)… I know a lot of you are very interested in that part of it.

The bottom line is that it is less than five minutes of my effort to deploy a site completely. I could have reduced that to zero, but in this scenario the effort wasn’t worth the payoff. In an enterprise where SharePoint would have a life of longer than a few months, I would have!

Provide In-line, In-context Help

This is a really key element of creating a usable, low-support SharePoint implementation: It starts with knowing what your users will do with SharePoint. Now notice I didn’t say might do with SharePoint.

You should have a solid understanding of the desired outcomes and functionality wish-lists of your business users. You should have a goal in mind. If you don’t, you’re implementing SharePoint too early.

And if your answer is “My users will collaborate with SharePoint” then that’s too broad. You should also provide guidance and priorities for what collaboration means.

After you’ve established what will be important to your users, you can start deploying solutions with built-in, “in-line” help. Take a look at Figure 2, which is a slightly more specific team site.

On this site, the team needed a customized Issues list, which I created. I knew they’d have two basic needs: to manage security and to customize the list. So, on the team site home page, I created instructions and links that made those tasks easy.


Figure 2: A slightly more specific team site (click image for larger size)

And, in Figure 3, you’ll see another example of in-context help for a document library. By the way, yes, on this site I used the term “Document Library.” (Long story. Pretend you don’t see that.) What’s most important here is the fact that I knew that users would need to do three things: view, add, or work with multiple documents. I added a content viewer Web Part to the main library form—straight from the ribbon—that had instructions for those tasks. Such a customization could easily be deployed as a SharePoint solution or custom list template.


Figure 3: In-context help for a document library (click image to see larger size)

The bottom line here is that you must anticipate what users will need—what support requests they might generate—and design, or modify your sites based on actual user needs.

These are very simple examples of a simple, but critical point: Out of box, SharePoint exposes everything – all of its functionality – with basically equal weight. You must modify SharePoint to reflect the importance of functionality to each solution you deploy.

I have to give a shout out to my friend and colleague, and fellow SharePoint Pro author Asif Rehmani. He has really got this idea nailed, and has taken his extraordinary library of video “snippets” of SharePoint training and added them as a ribbon tab, in-context. So, in a document library, a user can view quick videos about exactly how to work in a document library.

I discovered his incredible new resource a bit too late for London but will definitely be integrating it into future client projects. I’ve been doing end-user training and adoption solutions for twenty years, and he’s got exactly the right idea.

And, finally, notice a similarity to SharePoint 2013? Microsoft has done an extreme makeover on team sites, to “bubble up” functionality in more logical, user-centric locations. Microsoft is showing us that it’s important, and is providing a solution out-of-box.

But smart enterprises will take it to the next level, and make such in-context, in-place guidance and functionality specific to each solution and workload.

I hate to give this caveat each week, but I feel it’s important to remind ourselves that none of this is rocket science. Each piece of what I did to create an intranet for 4,000 users this summer is easy. It’s how you put the pieces together, and why—all based on your specific requirements—that is the magic.

I am glad so many of you are benefiting from these articles. Keep your feedback and comments coming—you can post below this article, to our Facebook site, and you can email me directly (dan dot holme at intelliem dot top level commercial domain).

Best wishes, and, from the Alps of Switzerland, yo-de-lay-hee-hoh!