Hiding The Toolbar in Sharepoint 2010

The Toolbar is one of those in-between metaphors in the Sharepoint 2010 environment. It is designed to make things more comfortable for people used to Office 2010, yet it makes using a web metaphor complex and somewhat needlessly difficult. Here is how you hide it.

Why You Want To Hide It But Not Pull It Entirely
Really, Sharepoint is constructed to rely on the damn thing. Unfortunately, if people don't have permission to do shit on your site - and most of your users are readers, not contributors - you don't really want them poking around the various grayed-out links.

1. Pop open Sharepoint Designer and find the site you need to get into.
• Side nav - Master Pages
• Your custom master page from when you wiped the basic sharepoint page.
• Edit file
• Check out the file.
2. Look for this tag: <SharePoint:SPRibbon runat="server" PlaceholderElementId="RibbonContainer" CssFile="">
3. I like to label mine things like <!-- === THE RIBBON STARTS HERE == --> for future reference, but all that should be in your minimal master page.
4. The next thing to do is decide what permissions people should have before they can see your ribbon. I like "edit list items." 
1. <Sharepoint:SPSecurityTrimmedControl ID="SPSecurityTrimmedControl2" runat="server" PermissionsString="EditListItems">
2. every other piece of ribbon content goes in here.
3. </Sharepoint:SPSecurityTrimmedControl>

So how does this work?

Permissioning is still your only job. You now have two groups of users, Everyone, who have read permissions and can't touch anything on the site, and whatever group you assign to have other permissions. In theory, this will work to control the whole site - the ribbon will just not be there when they log in. 

Sometimes You Just Need To Trust People

However, this means that you need to grant pretty high permissions to anyone who wants to edit anything on the site, and that includes things like, say, a calendar. For some reason, presumably because the ribbon is set at the master page level, you can't just issue edit list permissions on a specific list (everything in sharepoint is a list) and have the ribbon load properly on that list alone.

In theory, there is a provision for this by "allowing" people to "hide" or "display" the ribbon.

In practice, for the group you want to be able to edit and access that calendar (or list generally), create a group, give that group Edit List permissions on your site, and trust in the panopticon to let you know who, exactly, fiddled with what. They probably won't, you can definitely see what they did if they do, and turn on version control for the site. Welcome to systems administration, which - much like the future generally - is slightly less than promised.

The Quicklaunch

The Quicklaunch is the portion of sharepoint popularly known as the Left Nav menu. There is no way to mince words: the left nav is badly written to automate tasks, such that the net result is that said tasks become manual always. Here is a short list of its auto-generated things:

• Automatically generating suckerfish pop-out menus for new lists (everything is a list)
• Automatically changing various links to headings and headings to links
• Automatically nesting things (see above, cockroaches, mice, new pages)

The thing is, you can see the outlines of where this may have been helpful once. Similar to <span> tags all over everything (including this post), it's easy to see where coding has gotten in the way of ideology.*

This Is How The Left Nav Thinks

In Sharepoint 2007, as you flicked back and forth using the quicklaunch, the "level" of the quicklaunch would be set explicitly. This means that if you were on Page A, and a given link was Level 3, and you clicked that link, the link would likely become Level 1 or Level 2 on the inherited site. Depending on how competent the Information Architect was, that level might now display its siblings and parent... or not.

They have slightly sorted this out in Sharepoint 2010, except now, the support for your class inheritances is specified by name in the back end. This is then one o' them "lateral" changes where, like shoving your peas around your plate, something has changed without actually being corrected.

Explicit styling of the various inheritances, laid out in Core.css, will be to blame here - but so too are site definitions and weird automatic navigation and, of course, poorly-managed software development teams that appear to privately hate each other. This is a common problem at Microsoft, and will turn up later when we try to navigate workflows.

The Quicklaunch functions, displays, and generates differently in different Sharepoint site "definitions." Site Definitions** are code that sits on the server to tell sharepoint what to include when you try to generate a new site. At their root, Site Definitions are why you can't have nice things in Team Sites; the definition includes the features list, and someone in Redmond decided Team Sites don't want Group Lists by default. If you were better with C# and cared about this problem at all, you might fix it at root. You are bad at C# and are angry about having to fix it at root at all, so the actual problem here is how to design your information architecture and jQuery to repair the thing without having to touch Sharepoint proper at all.
**Ominous capitalization returns! Any time anyone ominously capitalizes anything, you are In For It. It, here, is A Sloth Of Bears.

So, first things first. Each Subsite is a new level of code. In previous versions of Sharepoint, it would then generate a little tag, like .level1, and you would style that. It worked okay most of the time, although around level 3, it started to get weird. Deprecated! Now things are inheritance-named in a mockery of Web Standards and you need to find out what their names are.

Sharepoint still only supports so many levels of subsite before it begins to get strange, and that level is 3. Level 1 is your home site, http://[YOUR STUPID SERVER:PORT]/. Level 2 is the first // address after that - so http://[YOUR STUPID SERVER:PORT]/Departments or /Office Documents.

That first // can be either a subsite, or a list, or a page. They will all style differently in your side navigation, and will all be the very thorny devil to reproduce elsewhere.

Level 3 is then the next // after level 2. Most of your inheritances, named explicitly, are probably working up to this point, and you are probably safe. The difficulty will come in at Level 4 and below, so... http://[YOUR STUPID SERVER:PORT]/Level2/Level3/Level4/Page.html.

Whenever you load http://[YOUR STUPID SERVER:PORT]/Level2/Level3/Level4/Page.html, your side navigation will completely lose its shit, even if you have done everything correctly. This is a long bug, caused, as mentioned, by two likely sources. The first is bad initial architecture. You noticed that the calendar bugs can sometimes be solved by naming them one thing, then undoing it, then naming them something else - this is like that. The preferences set when you launch the particular subsite matter.

The trick here is to set all of them, explicitly, to manual management when you create the site. Then you set up each link manually as you go, in Site Settings: Navigation. You can link those things and set them as headers. It is best to not set them as below one another, because then you will be faced with CSS-styling them to not Suckerfish all over the place, and from a pragmatic point of view, it does not matter whether or not they are nested - the headers and key levels will display differently no matter what.

Breaking Down The Quicklaunch CSS

.s4-ql UL.root > LI > .menu-item << this is typically what awaits you.

So. The Quicklaunch styles are nested in class .s4-ql. Inside of that is an unordered list, which is class-named "root." There is a chevron, which affects the nesting level of the LI in question, and which is the subject of much Sturm unt Drang upon the internet WRT correctness in published definitions versus legibility. Mostly, what this means is you can identify particular nests of tags by chevron abuse.

That this almost certainly means your menu is badly written is beside the point. Skip it. It wasn't made by Web People anyway, which, obvs.

Another chevron, and then .menu-item.

The naming structure here is pulled straight out of the existing Microstuff in Core.css. The trick is not writing any of this yourself, because it is to be assumed that you know what you are doing wrt Legible, Semantic Code and never nest tags such that chevrons are required for styling. So! The trick is FINDING these classes and then altering them to begin with. You will probably not have to build your own structures. Even using a standard reset for CSS styling is somewhat questionable before Sharepoint 2013.

Just find the thing marked .s4-(whatever) and style that.

*Do you know about web design ideology? No? Not at all? Pity. You have a long and adventurously boring amount of reading to do, mostly at Happy Cog's source code and A List Apart. Pro Tip: Their source code is almost certainly generated by Rails now.

Begin Styling Sharepoint 2010 CSS

Cascades are the way the web runs right now. Good sites set some good styles up at the top, then they inherit them. This is a system that works because it means no-one has to duplicate work, or eradicate inline code in order to change the colour of a link. The ways to do this are well documented at respectable institutions like A List Apart. You probably have a library of handy CSS references around, which you use to remind yourself how to build kicky styles that are consistent across your content-style-format separated software.

1. Please gather those links, efficiently organized, into a pile.
2. Import them into Microsoft Word, where they will be filled with <span> tags.
3. Print them on the printer you have stolen from your client's network because you don't own a printer.
4. Take them outdoors.
5. Place them in a metal bin.
6. Light them on fire, they're of no use here and will only pain you as you attempt to fix the Microsoft tradition of styling <em>every single element by individual and inherited class name</em>.

Today we are building your root-level styling sheet.

Today's Assumptions:

• You already have an intranet, which you are trying to replace with Sharepoint.
• You have full ownership permissions on your local Sharepoint.
• CSS is already a known.
• Learn CSS: http://www.w3schools.com/css/default.asp
• You have loaded Randy Drisgill's stripped basic master pages into your site already.

Styling Basic Master Pages in Sharepoint 2010

1. Open Sharepoint Designer
2. Open Notepad++
1. Create a new file with whatever normal resets you use, and name it yourclient.css
2. Save it in your normal local working files.
3. Open Internet Explorer, and navigate to your sharepoint installation.
1. Click on "Site Actions"
2. View All Site Content
3. Halfway down, there will be a Style Library folder.
4. Open Style Library in Internet Explorer.
5. Upload your CSS to the Style Library.
6. In Sharepoint Designer, click on the All Files folder.
1. It may not load on your first try, so click something else - Subsites maybe - then click back.
2. Event handlers not passing is a common problem in everything to do with Sharepoint.
7. Skip almost every folder and browse down to Style Library.
8. Is your CSS showing up there? Good, you uploaded it correctly.
9. Open your master page, remember, the default one you made on Monday.

This is the string of code you're going to need:
<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/[YOURCSSSHEET].css %>" After="corev4.css" runat="server"/>

I like to put it in immediately after the <title> tag. Let's break down what's going on in this tag, because it might be the first and only hint you have as to what language Sharepoint is expecting in its inline code.

SharePoint:CssRegistrationSharepoint likes you to register things with it before calling them. On the server side, it appears to be running through a bucket of mixed languages, and this is how it sorts things out. You need to register all kinds of things, but Sharepoint specific things require Sharepoint specific tags.

<% $SPUrl:~sitecollection/Style Library/[YOURCSSSHEET].css %>This is some inline code (I know how much you lurve it). This code identifies itself as being part of the ASP family by its use of the percentage sign to open tags. This might be relevant to you if you have never read ASP code before, as I had not done before someone gave me ill-advisedly high permissions on their underdeveloped extranet site.
Side Tip: Learning on the job is expected, because you are an underemployed and broke contractor. Find someone lazy and steal their permissions.

Pro Tip: Sharepoint pages can be written in any of three or four languages. You can figure out which language is expected at the very top of your master page, in the tag <%@Master language=""%>. Most Sharepoint 2010 builds are in C#.

After="corev4.css" runat="server"This is the money shot. Sharepoint 2010 does not cascade properly, and therefore, you must specify that your sheet comes after corev4.css, the default Sharepoint master sheet. You must. Or it will not load, it will not cascade, and it will be overwritten.

Do not bother separating your stylesheetsSharepoint 2010 specifically names inheritance structures, commonly using the !important tag to set your fonts and things permanently, which is a huge pain in the ass even before you try to get everything to import in order after corev4.css. Here is a sample inheritance structure, designed to make the Quicklaunch (left navigation panel) turn orange:

.s4-ql UL.root UL > LI > A.

This is the sort of language you are dealing with. Abandon all standards, ye who enter here.

Legible Master Pages in Sharepoint 2010

Sharepoint 2010 Default Look. 

People pay money to work with this.

Bright thought: they may pay you some money to
make it stop looking like this.

Default Sharepoint 2010 styling can best be described as Suits Laughing Alone With Salad, which is to say: it has been designed to appeal to a market that still thinks of  Pierce Brosnan in a power suit as the ideal of Western masculine power. This should not devalue what Sharepoint is actually good at, which is working in a sealed, all-Microsoft environment all the time.

The front-end Sharepoint server technologies are a non-satirical pastiche intended to support and extend existing corporate office software, in which many people have heavily invested. Specifically, they are designed to extend Microsoft Exchange Server.

Here is an interlude about Bill Gates killing the Courier tablet because he had an allergic reaction to an MS product that did not support Exchange.

You are probably only vaguely familiar with the Exchange software, or its design language, because I am assuming you spent the late 1990s and early 2000s down an internet K-hole seeking Highlander/Final Fantasy 7 fanfic* and reading the sort of webcomics Scott McCloud would later write many books about.**
*Pornography.
** Illegibly formatted.

The outdated design language is there on purpose. It is not for early or even middle-term adopters. It is for Late Or Not At All adopters, and they like it that way. One of them is mourning their Blackberry right now. That one is not a teenage protester in London. You probably use Scrivener, OpenOffice or Google Docs to get all your actual work done. You almost certainly do not print reports. You may not print anything ever.

Sharepoint 2010 was not designed for you.

It is now your job to make sp2010 appear beautiful, functional, unthreatening and contemporary but not too contemporary. Let's get started.

First things first: Randy Drisgill is a good place to start for a simple master page that rewards actual customization. He implies 2013 will be better, but you probably aren't going to get to work with 2013, because it is probably expensive, and 2010 works fine. Ideally, purchase a copy of his book, Sharepoint 2010 Branding. It has deep secrets and lends your desk credibility.

Left nav of Sharepoint Designer

1. Open Sharepoint Designer, heir of MS. Frontpage, get all your permissions in place, and log into your site.
2. From your main site, look at the left nav.
3. Go to the Master Pages entry.
4. This is your directory where the control page that loads all your other pages lives. It is the Frame Page that loads your Page Layouts.
• We still use frames as a metaphor here in 1999.
• Rawwrrr, red power tie.
5. You will notice that even the v4 master pages are full of weird callbacks.
6. Go to Codeplex and download the 2010 starter pages from Randy Drisgill. 
• Sixty three thousand downloads can't be wrong.
7. Unzip those into Notepad ++, set the language to ASP, and and have a look through. They are dead simple and clean.
8. Have you got a document reference for how your website should look, like a pre-existing intranet?
9. Open Chrome's browser tools and seek out where the current intranet's stylesheets have been hidden.
• Press F12 to open Developer Tools.
• In the tab marked "head" there will be a dropdown.
• Somewhere in there will be a linked file marked *.css
• Click it and open it up in a browser window.
• Copy and paste it into Notepad ++.
• You now have a guideline for how your intranet should look.
• You have not had to have a Consultation about this with any other department. Productivity win.
10. Take a copy of Default.Master.
11. Gut it and replace the contents with the Simple Masterpages code from Drisgill.
12. Save this master page as [yourOrgName].master.
13. You now have a fresh master page to work with which is in your hive, without you having had to touch the hive in any way.

This page will be what we work with going forward as we do things like customize page layouts and implement existing organizational CSS to make everything look familiar while running smoothly into a new corporate future.