Soon To Be Hungover, Still Full Of Bears

What's this blog about, anyway? Menswear that remains flattering? Software giants having difficulty navigating the quick rate of change despite their massive cash reserves? The desire of said giants to maintain reserves of cash and walled gardens rather than simply making things better?

All of the above! Sharepoint 2010, new in 2013. There will be a new release of Sharepoint this year, and it has been said through the grapevine that Microsoft has caved. We are to be allowed Nice Things, like normal web-development administration privileges. Using text editors. Fewer of the Madd Haxx. This seems pleasant, in theory, although I could wish they'd released it five years past; it seems promising, on the surface.

Like cake. We all like cake, correct?

I am sure at this stage that it can be taken as understood that said cake is, in fact, a lie. You're still going to have to administer legacy systems. You're still going to have to use terrible haxx to do it, and you still have a pretty sweet gig breaking broken things and being angry for a living. But today, today is the day before New Year's Day, and therefore it is safe to assume that one of us is preparing for a hangover.

Because it is the slow patch, and because you will soon begin the painstaking work of repairing and styling an installation of Sharepoint 2007, take today to permission some things, then go read some of the Top Ten lists that were supposed to occupy your time over break. While you in reality slept and read and slept some more.

Here are some ever-adorable Pizzly Bears on Melting Ice by Masahiro Minami.

Perhaps you could review the Comprehensive List of Internet Emoticons, hosted by wikipedia. ಠ_ರೃ

Mykki Blanco is an awesome artist and this video is very good.
As is Ane Brun's Do You Remember
It fades nicely into Rae Spoon's Ocean Blue/Death In Venice.
Then you get to the Azealia.

It is New Years Eve, so the only conceivable reason you are working at all is for the money. At the same time, it is safe to assume there's shit-all to be done at your office, so here is some stuff from The Billfold, like my rental history as of last year - non-comprehensive - or bits on the best things people have done when they've quit their terrible jobs. Use that to kill some time. Poke around the neat corners of the web. Take a break already. You'll have more fighting to do soon enough.

Knock-offs and Colour Calendars

Know who does calendars really well? Google. They also do search really well, and document sharing, and really anything you need to get work done except possibly Gantt charts. Unfortunately, it's out-of-house and therefore less secure, whatever that means in a world where I store copies of everything to encrypted drives in the expectation that the police are willing to break my hands to get at what I have hidden.

You don't get to work with Google, because it is outside of the Microsoft environment. Oh, Microsoft. Your stores are lolariously ripped off of Apple's, your products are ripped from Google's, but the trick with iteration is that you are supposed to make things better, not worse. Unironically using Bing for a search engine is not the way to go. Just make your shitty office software marginally less shitty, bitches.

This is two storefronts down from the Apple Store in Yorkdale Mall.
No photos my left tit.

Since my ability to be coherently critical on the topic of MS is rapidly fading into an epileptic music video set to power-noise, let's move on.

Google does calendars really well, and your peers are mass-tunnelling out of the building to access their far superior services. Therefore, they have an idea of how to colour their calendars. They are asking you to make coloured calendars in Sharepoint, too.

Okay! Sharepoint supports this out of the box, but, per usual, ass-backwards. They support this by allowing you to include different calendar lists into one calendar view, with each calendar listed separately. Those calendar lists can live anywhere on your site and be rolled up by default, and - just like any other list - only people who have permissions to see their contents will be able to see the calendars. This works pretty well.

The available default colours alternate between boring and horrible, but that's so normal you probably don't notice. The trick is that your departments do not want multiple calendars, or to list their events across more than one list. They want one list, and they want it to be pretty.

Colouring A Calendar
You're going to need web parts for this. And jQuery. And a vague comprehension, however thin, of the term "event handler." Have you added jQuery to your masterpages yet? No? Go do that.

Here is your script:

1. Add as many Case Sensitive Sniffer Words and Colour Classes as you like to the above script.
2. Open your CSS and add those classes to your custom CSS for the site.
3. Save the above into a text file.
4. Upload the text file to your Style Library, under View All Site Contents, Style Library.
5. Get the link for where the thing lives. It is almost certainly
   http://[YOUR STUPID SERVER:PORT]/Style%20Library/yourScript.txt
6. Load up a page displaying a calendar that needs colours
1. This can be a Calendar Page, or any other page you've stuck a Calendar web part into.
7. Edit the page the calendar is on by dropping down Site Actions > Edit This Page.
8. Click the Add A Web Part button
9. Load, from Media and Content, a Content Editor.
10. On the Content Editor, click the dropdown arrow, and select "Edit Web Part"
11. Set the Content Link to where your script for that calendar lives.
12. Save it. 
13. Provided you've set your sniffer words correctly, your calendar is now coloured and displaying all events for a given day by default.

Event Handler Issues, This Is Important

SP.UI.ApplicationPages.CalendarNotify.$4b  is your event handler, by default. The name of this event handler tends to change unexpectedly! It is a surprise every time. If your calendar colour isn't working at all, and jQuery is loaded, it is time to find out if it's changed to SP.UI.ApplicationPages.CalendarNotify.$5c or some shit. It did that on me once and took eight hours to find the problem.
In earlier variants, the appropriate handler name is SP.UI.ApplicationPages.CalendarNotify.$3a.

Calendar Expansion

Google can hide it because Google's calendars work right and work easily and weren't designed backwards.   You will have people requesting this instantly. Don't want it? Take out function expandCalendar(){(miscellaneous code)}. 

Colouring and How It Works

It would be super nice to have this script be case-insensitive, but for now, you load one line of sniffer for every variant you're looking for. The jQuery then searches the loaded events for the sniffer words. So:

$('div[title*="THING"]').addClass('calendarColor1');
$('div[title*="Thing"]').addClass('calendarColor1');
$('div[title*="thing"]').addClass('calendarColor1');
$('div[title*="thInG"]').addClass('calendarColor1');

All set the CSS class calendarColor1 to things with the word Thing somewhere in the visible event information. 

Why yes, this is slow and inefficient, thanks for asking, but please recall that Sharepoint gives exactly no fucks about bandwidth already, so it doesn't noticeably damage performance at all. 

Add as many spelling variants and colours as you like. One of mine, with a particularly ham-handed intern, has six variants. It eventually got easier than actually managing the calendar. 

Other Calendar Fun

I've also added a sniffer for the word "Deleted" which sets a class of "hidden" to that event, because the people who actually use these calendars are legend. The sort of legend that involves a hook stuck on a car door. Tell you what, we can go camping some time and trade the stories by the light of burning IT support requests.

Resource Calendar Infestations

Resource Calendars are, in theory, a default supported out of the box solution. They are in practice probably the buggiest part of Sharepoint. They simply don't work out of the box. At all. Possibly the engineers were told to make them happen two weeks out from ship and then decided to deprecate support - no-one really knows.

Have you turned on Site Features: Anything With This Icon?

The icon for "make my site functional already."

 
No?
Go turn that on, I'll wait.

You now have access to two main sorts of Calendar. The basic one, which works pretty well but needs colouring to be made actually useful, and the Resource Calendar. Resource Calendars can be useful, but they have bugs worse than your old apartment tower. Let's go through creating a functional one.

Most of this content is available with sufficient googling.
Steps are now numbered, due to my own morbid curiosity.

1. Create a Resource Calendar.
1. Go to Site Actions: More Options and select Calendar.
2. Click More Options.
3. Tickybox that this calendar will be used for Resource Reservation.
   Reflect that nothing good ever comes from MS's randomized proper nouns.
2. Try to add a thing to it.
1. There are no resources in your Resource List.
2. Site Actions: View All Site Content: Lists: Resource List
3. Populate that sumbitch with individual resources
4. Click the "Items" tab
5. Just for giggles, click New Item until you get New Resource Group
6. Populate that with your created resources, IE: conference rooms.
3. Already frustrated and perhaps tiddly, return to your calendar and add some resources. Maybe a group, so you can compare double bookings. 
1. Click "Add Resources"
2. Select from the menu that appears
3. Click Add
4. Click "okay"
4. Book one of them.
1. Double click "Tuesday"
2. A popup will appear
3. Note that, having added a resource group to the calendar, all of the available resources are already selected for your event. 
4. Reflect on the peculiarity of their pre-selection as you de-select a few and book your event.
5. Hooray! You appear to have had a success in booking a resource!
6. Navigate away from the calendar.
7. Navigate to your calendar
8. Where is your resource. It is not there. Where did it go. WHY did it go. WHY. Why-ee.
1. If you have a thing for breaking in case of stress, break it.
9. Re-add resources to your calendar. At least your booking is, in fact, still there.
10. Try to repair this with jQuery, using Thomas Zedepa MacMillan's technique and Fiddler.
1. Learn to use Fiddler.
2. Rejoice in learning Fiddler.
3. This method takes hours, but does eventually work.
4. Don't forget to specify the individual resource list that should be pulled in.
11. Oh hey, it loads! Now your calendar loads its resources list by default.
1. A resource list. The one you listed after following those painstaking steps.
2. Because Sharepoint's permissioning is weird, that resource list will always load if you save that code as a web-part.
3. So you have to re-do the code and the hack for every resource list you want to load by default in your entire site.
12. Look at the toolbar and notice that it offers day and week but no month views for resources.
13. Load the month view of the calendar.
14. Notice it loads but a single resource at a time in Month View.
15. Notice that it does this no matter how you hack it.
16. Accio paper sack.
17. Take a deep, deep breath. 
18. Scream into your pet sack until the weird robot sounds happen and you get the chequered vision problem.
1. Optional: Begin loading your resume to Dice.com, never mentioning you have even heard of Sharepoint.
2. Post in several locations that you are a patient human with soft human skin who would like a rewarding career, rather than this one.
19. This is the actual answer, via - improbably! - MSDN themselves.
1. Create a new Group Calendar. In the More Options select "Use this calendar for resource reservations"
2. Once the calendar is created, go into the Calendar list settings. Click Title Description and Navigation. Set "Use this calendar for resource reservation" to no.
3. While in the calendar list settings, Click Change new button order and default content type. Check "Reservations" and set it to the default content type.
   
   When you go back to the calendar it will just have the normal calendar ribbon without the buggy resource selection options. When you add a new list item, the calendar will be associated to the resource list and let you select the resources and detect their availability.

Ta-dah! You really only have to do three incredibly counter-intuitive steps to get a functional calendar, after all.

Last step: Please replace your pet screaming bag. It is no use to you all blown out like that. How will you get through the holidays with a destroyed stress containment unit. Silly.

Cavorting With Calendars

First things first: someone wants a calendar from you, and you go to "More Options" on your subsite of choice, but despite it being a Team Work Site for Working In Teams, there are no calendars available.

Whoops.

1. Go to your Site Settings.
2. Go to SITE ACTIONS > Manage Site Features.
3. Hammer any button with the  icon until it breaks.
4. You now have access to Calendars and other Fucking Default Shit People Will Want for Working Together
1. Drink, because your left navigation now has a phone memo list in it for no fucking reason, yet A Motherfucking Calendar has not been activated by default
2. And your left nav also says "Lists."
3. Go to Site Settings, Look and Feel > navigation
4. Delete that shit and re-link it.
5. Notice that the left nav has decided all your links are headings.
6. Drink. You have calendars to update and your phone just started going because the left nav says "lists" and someone upstairs is bored enough to have noticed.
7. Check your broken analytics and decide it doesn't matter because you already memorized the four people who look at this site ever.
8. Go back to correcting your calendars.

There are several types of Calendar in Sharepoint 2010, and this does not matter a whit because nothing but your basic Calendar will work properly for you out of the box.

This is a logical place to split out Calendars, Basic from Calendars, Colouring and Resource Calendars. It is also a short post, because I have a lot of rum to neck.

What, still bored? Required to be in the office over break? We already know you have an open, largely unmonitored internet connection, so why not go to Tom and Lorenzo and check out the 2012 Miss Universe competition. Kill your afternoon. It's Friday.  My analytics say y'all are all Canadian. Go home. Get gone.

Come back in January with your hangover and a desperate need to fix calendars, since that is all we're doing next month.

Appropriate Browsers in Sharepoint. And Apples.

There are none.

Oh, kidding. KIDDING. Not kidding. Kidding. The only browser you can use with Sharepoint, any Sharepoint at all, is Internet Explorer 7+.

If you do not have IE 7+, your browser likely does not support the Active X. The Active X is necessary for batch document management, so you need it. Also, random bits of Sharepoint break when exposed to other browsers. Do not support anything that is not IE 7+. I have no better advice for you, because everywhere will tell you oh, Sharepoint is great on this or that or that other thing.

Sharepoint requires software that is not supported by non-Microsoft companies. This is entirely fair, and good business for them, but your response to anyone calling you up to say X link is broken or Y thing won't load in Chrome is to put down your phone, breathe calmly into your paper bag, take two Xanax and reply that you can't support Sharepoint in a non-MS environment.

This is going to be a problem, because half your company now runs Apple computers. The other half uses only Chrome, for any reason.

Apple Fix
The solution to this is one of two things. The first is, as mentioned, Boot Camp. Boot Camp, however, will force your team to work with Windows. For this they will despise you.

Parallels is your answer here (http://www.parallels.com/products/desktop/). It runs in-window and will let you load a proper* variant of IE, which will then allow everyone to work as normal with your toolchain. Your toolchain is already a hideous nest of interlinked technologies, one more can't hurt.
*hollow laugh.

Chrome Fix
This is only a problem because they have set it to their default browser, and now the links from Corporate Mailouts will open in Chrome and not IE, and break your shit.

Many* Sharepoint development books are insistent the software works properly cross-browser, which is a fat lie caused by MS <span>-naming every line of their code. They are incorrect. The solve for this is to get the person who has called you to set IE to be their default browser again, and to refuse to help with problems in browsers not from Microsoft.
*the one I read four pages of before laughing myself near-incontinent at its froth of lies

Froth of lies and icing sugar. I am off to make gingerbread houses threatened by bears, as is appropriate for the season.

Audience Settings Hide Things In Plain Sight

In some institutions, the intranet is controlled by a panoply of people. They all have equal permission to ask you to do something, and they all can see what appears to be the full intranet. They do not, however, all do the same work. They do all run out of things to do at about the same time each week. About that time, they start looking for things to do, rather than bunking off work or reading a book under their desk.

Although, as previously established, you don't like your job or anyone who tells you you're lucky to have it, you are proud of your work, and you like letting other people do theirs, too. Mostly the people who control some levels of content are not so tight with the analytics, which routinely fail in Sharepoint 2010 installations anyway.*

*Really, there's no information on the internet as to why they simply crap out, but as a front end administrator you're powerless to fix the problem. Batch start as many jobs as you like, adjust all the timers you want, you're still boned.

 So how can Sharepoint help with office busybodies?

Just as you can set permissions so that people can access a thing, you can set audiences so that their group is the only one to see that thing. Or to not see it. This is usually set in the navigation.

• Open Site Settings, People And Groups.
• No, wait. Open Site Permissions.
• Notice that unless a permission has been explicitly set to a piece of content as a permission within your site, the group you want doesn't show up even if it does exist already.
• Great now People And Groups.
• By default it will open your default Members Group for whatever Site you happen to be on. Misleading!
• Look on the left nav. There will be a thing called Groups. There will be a More link. You want the More link.
• The More link will lead you to People And Groups: All Groups. 
• Due to weird convulsions in Sharepoint's site settings, expectations, team site settings, and pre-loaded "site features," it is entirely possible none of this is real or will work for you.
• All Groups has a list, for editing, of every single group in the entire site and all of its subsites. You can actually see what is going on here, which is why it is incredibly well hidden. It is a feature of use.

In All Groups you can set up new groups and see groups that are not necessarily relevant to specific permissioning, and here is where you will set up your new group, seeHiddenThings.

• Click New at the top of the page. There's also a settings link where you can make the left nav of people and groups more useful.
• Name your new group.
• Populate your new group with people you want to be able to see whatever link to whatever thing.
• Leave people and groups and go to Site Settings, Site Navigation.
• Set up your new link to whatever. 
• Note that, although Sharepoint nominally inherits things from one stage to the next, it has trouble tracing where you actually are within its file structure. Have an ominous sinking feeling about that, which you will not address for some time to come.
• On your New Link, set your Audience to your new group. Note that you can set the Audience for this link to be whomever you like - anyone in Active Directory, any pre-existing group.
• It is, however, much easier to just remember that Group Linkname can see and access Link In Question.

Boom. People not in that group cannot see that link. Unless you named yourself to that new group, you can't see that new link. No-one can see it but the people in the group.

If you were extra smart, it is a link to a private list or library, too.

Permissioning Is Your Only Real Job

Permissioning is keeping things private while waving them about in public. Once you've branded your Sharepizzle installation and gotten the hang of hitting the "create subsite" and "activate site feature that really should already be active" buttons, your entire world will compress to permissioning. It is best to get it right from the start.

Permissioning is really, really handy in Sharepoint. I will go so far as to say it is one of perhaps two things they have mainly gotten right. It applies to everything in a sharepoint install, at every level, and you can control it for real. You can always tell what parts of the enterprise software are actually valuable and which are colossal wastes of time and funding by what's fixed from install to install. Permissions have been tightly controlled from the start, yet managed to improve in 2010. Surprise. I am actually surprised.

Your ability to control permissions, and break them horribly to do things they were never intended to support, is one of your great powers. If you were a good IT Person,* you might plan for their inheritance and carefully sort through the benefits and disadvantages of a coherent permission approach.

*You aren't a good IT person. If life were a Choose Your Own Adventure novel, you would be one bad move away from being eaten by Ant People. The bad move was choosing this book to begin with.

Permissions have a bunch of levels. Here's some key theory:

• You can use permissions to hide things, both in inline code/layouts and with the various Audience Settings.
• This includes the hateful Ribbon metaphor.
• Initial Sharepoint access and accounts are set, usually, through your institution's Active Directory.
• As addressed previously, this makes individual user accounts mostly not your issue.
• Sharepoint groups by default tend to have one of three permission levels, Full Ownership, Contribute, or Read. These are mostly what you need. People can Contribute, or Read.
• Individuals can have individual permissions set per site or list
• Groups hold individual accounts and are strongly preferred for setting permissions.
• Groups cannot contain other groups, ever, for any reason.

Group Permissioning Is Preferred. But Why?

Ideally, all permissions for all subsites and lists on your Sharepoint site are inherited. That is to say, you set them at the top, and like Republican wealth, they trickle down. In reality, as in reality, they do no such thing: you will be breaking permission inheritance for people from Day One, because people do not actually want to share on these sites, but that is the theory.

When you set individual account permissions, they get written to somewhere other than the Active Directory. The account lives on regardless of whether the individual still works in the building, and sometimes regardless of whether their AD account still exists in the system.

Ghosts in the machine will therefore lard your site like fat in bacon. You will not be able to get them out without an overview of every employee in the company. It is therefore best to keep them inside of groups, where the general group has the permissions, rather than trying to keep tabs on who's been hired or fired this week.

Why Can't Groups Contain Other Groups?

This prevents permissioning recusion and inheritance attacks, in theory, where a group set to full control in one place is nested in a Contribute somewhere else. That was a guess. I have no idea, because sometimes groups which explicitly have one level of permission (Full Control) still don't have Full Control over sites or objects they nominally Control The Fullness Thereof.

This sort of weird inheritance problem happens a lot with this software. It is normal. It makes the line of the Bourbon Kings look clean and straightforward.
The Bourbon Kings have nothing to do with alcohol per se, and don't we wish we could say that about you once you're done sorting this garbage out.

How many levels of permission can I set?

You can set specific permission levels on anything in Sharepoint. Each subsite, each list, each folder and item can have independent permissions set. This is valuable because those permissions are largely effective. You set them explicitly and name the accounts with permission, and those accounts can see pretty much exactly that thing you shared with them, and nothing else.

Problematic in that sometimes this means they can't see the inheritance breadcrumb or suckerfish menu to get to that site, useful because they are going to just check their Outlook for the link every time anyway.

Why We Don't Use Folders In Sharepoint

Folders are the most common convention of document management and storage in the PC world. The convenient metaphor of a filing cabinet, comforting and familiar, is how we trained Gen-Xers in storing and retrieving their files.

Sharepoint includes folder functionality within its document libraries. If you've been reading this blog for two weeks, you have already got that dripping water down your neck feeling at seeing any topic considered fit for discussion. Here is why such an apparently innocuous metaphor, The Folder, is up for its lashing.

Sharepoint effing hates it when you move files. No lie. It is one of the hardest things to do in the server, for reasons which are utterly opaque on the front end. You can upload and delete things with relative ease, but try shoving around where they "live" and you are in for a fight. 

Files will fail to move. They will flunk out for no reason, with unclear error messages, which are themselves larded with chevrons from poor server processing. This is handy when you are first learning. The chevrons contain secret, valuable information on how to reverse-engineer the default processes, and handy search strings for Google, but no lie, you cannot move files with any ease or grace.

The permission required is, at the very least, Manage Hierarchy. Contributors can't do it, neither can readers, and even people with Full Control will be sitting there watching paint dry as the Move Documents process grinds along. 

This becomes a problem because you will frequently have clients who want to have, say, a Document Library called Acquisitions, and within that library, folders for each document related to a specific Acquisition. Say, one called MCGRAW Klein, another with its own nest called STERLING Forebears. 

You are now in Document Hell. None of those items are stored in a way where even valuable tools like the List Item Editor can see them - each folder becomes the List Item, the documents themselves are hidden from view. You will need to figure out where each of them lives. You may suddenly need to edit and support the Enterprise Search Tool, itself an entirely separate circle of Hell. 

Rather than use folders, you should really just tag a fresh column on the side, called "metadata" or "category" or "pleaseNoMoreFolders" and enter the relevant document identifier in there. From there, you can generate library views that will sort and group information by that column, which basically is what your folder-loving people want, anyway. It will label them clearly and leave them findable, without ever triggering a move job that lasts six hours and drops 25% of the documents involved for unwritten reasons.

So, when SHOULD we support the vile Folder?

Easy. When we have something that is identical to the above but requires more privacy. Folders are functionally only useful for batch-sized permission control on individual items. So if you have ACQUISITIONS and want the ones that are not approved for main release to be private, wait, no, you really should just make a new document library and set its permissions.

Folders. They are a vestigial limb of document management and have no place here.

Lists, Libraries, Form Libraries

Lists are how Sharepoint thinks about its contents. Everything inside of Sharepoint is in a list. Some lists have different properties assigned to them, such as "being a subsite" or "being a calendar" or "being a document library," but all of them are, for real, lists. You can act on lists with webparts to display different information, or use "Manage Content" to see them stripped bare of their browser-based display features and actually edit each item's metadata.

• Lists are 2-axis matrices of information, one axis being the item, and the other axis being the metadata about that item
• Calendars are Lists With Dates and sometimes files.
• Libraries are lists that have documents and files associated with them. 
• Form Libraries have weird automation, and their form for submissions can be customized in Infopath.
• That means you need Infopath. Eventually, someone will ask you for a form.

When you are doing Sharepoint development, you are typically styling an information pull from a list into the browser view. There are a number of ways to do this - usually the Content Query Webpart is the main one - but that is what you are doing.

Sharepoint was sold initially as a document server to help cut down on papers named "Final Final Final 6," but Microsoft keeps tacking on functions, all of which derive from Sharepoint's basically list-oriented self. Everything on the site is a list. If you want a dropdown menu, that is another list.

List Management
Everything in Sharepoint is a list. Everything. You don't need to Manage A List, you need to sort out what you want your list to do. There is probably an out-of-the-box one you have access to that will do what you need, IE: post announcements.

Library Management
Sharepoint likes to populate new Team Sites with a library called Documents, which is as much use as a fart in a high wind. When you create new sites for your users, name your document libraries something coherent and suggestive. I like "Minutes and Agendas," and "Fruit Menu" and "Budget Spreadsheets" and "Common Hibernation Zone Development Documents" Each library should store all documents of a type that shares coherent metadata, IE: Minutes, and the metadata should be used to group that content appropriately, so that it can be found later.

• A Note on Folders: If at all possible, do not use folders to organize your content. Their sole purpose is to permit a group of a given kind of document to be kept separate and private from the main body of the document library. This is so your manager can hide their minutes effectively from everyone else.
• Folders Are For Permission Management.
• It is Not Trivial to move documents out of a folder structure once they are in there.
• Use coherently named document libraries instead, add more when you need them.

Form Library Management

Form Libraries can have their information really easily exported to Excel and similar for maintenance and data-mining purposes. I use them for things like ticket orders. You will need Infopath to customize them, and they are their own entire post, relating to permissions and form customization.

So, that's lists. Everything is a list. Whee.

Sharepoint, Silverlight, and Planned Obsolescence.

Sharepoint, somewhat famously, does not give a fuck about bandwidth. It loads slow. Do you already understand about why that might be? Say, you already work in a corporate development environment? This post is perhaps not for you, because you understand: people have paid to make this bad on purpose.

Those of us from a different background may still have this tiny, feckless reserve of non-cynicism in place, however. So! For those of us not in the environment wherein resources are understood to be infinite: Sharepoint famously does not give a fuck about bandwidth.  You can do some things to help, but you can't fix it. Sharepoint is intended for internal corporate use, not external hog-wild link parties, and thus has been engineered to efficiently share documents. Indoors, out of the cold, and specifically overlarge Microsoft documents from the same Office suite as your current Sharepoint build.

This is a challenge, because your company never updates its information tech, and Sharepoint is Microsoft's sherry trifle* of planned obsolescence in web-flavoured software development. So you aren't running the same Office suite across your entire company. You may not be running compatible builds through your whole department. This makes things rather more difficult than MS planning documents will have you believe.
*complex, layered, better with alcohol.

Planned obsolescence is weird. It is designed to force clients to pay a tax to continue running their business, upgrading every two to five years regardless of actual utility improvement. In MajorDevLand, this means your clients are Locked In to Pay You Money every few years. In reality, this is a strong argument for not updating your fleet. Ever. When you update your fleet, you break your ability to do work into people in your company that have resources, and people who do not have resources. When the resources are documents that need to be collaborated on, everyone fails to the lowest common denominator... and it's handy to have that denominator be truly common.

Aside: People are trying to solve this tricky "no-one will give me money all the time" problem with subscription services. They've seen how the famously beloved* phone companies did it and are out for theirs. We shall see how this goes. I imagine well for some, piss-poorly for others.
*not beloved in the slightest.

So: Although Sharepoint theoretically loads Silverlight and can serve photography, videos, and rich media assets, the Sharepoint you're using never will. Although you can brand it, and indeed must brand it, to match your company and avoid Suits Laughing Alone With Salad, you don't need to worry about bandwidth consumption. Shove that shit in an average Sharepoint page and watch your ability to efficiently share and collaborate on documents across your organization squeal to a halt. It will just stop working. Don't support it.

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.

My Title Is Wrong In People Search: Active Directory and MySite

Here is the first of many common problems you will encounter while administering front-end sharepoint 2010 on an enterprise level.

Your title is wrong, and Lindsay Koffler-McMichael has not worked here for six months, yet when you search the Staff Directory, there they are. They are right there. With the wrong phone extension.

Someone has noticed this, perhaps someone with the title that Lindsay Koffler-McMichael used to hold. Perhaps it is a high title, with much prestige. This mostly means a lot of work for the new person, Rebecca Holmes-Angell, and since what she gets in return for the work is the title, she is now very unhappy with someone. Probably you.

prestige (n.)1650s, "trick," from Fr. prestige (16c.) "deceit, imposture, illusion" (in Modern French, "illusion, magic, glamor"), from L. praestigium "delusion, illusion" (see prestigious). Derogatory until 19c.; sense of "dazzling influence" first applied 1815, to Napoleon.

From EtymologyOnline.  

The phone calls will come, but you cannot fix this. Cue existential dismay.

Sharepoint draws its permissioning, groups, and account system from Active Directory. AD is a great system, which, well-maintained, is a major selling point for having a Microsoft ecosystem. One login! Fantastic! Except....

The Active Directory is maintained outside of Sharepoint. Presumably, it is maintained by someone else, someone in HR or in IT who sets use permissions and grouping and inheritance for the entire organization. That someone else is likely not you. You are okay with this, because it would mean having to do really intense data-entry maybe all the time, and you would also have to be keeping track of the e-mail system and whatever else is calling Active Directory. You do not want maintenance of Active Directory to be your job. You would then have to know who is being hired, fired, and retitled on a constant basis. In firms where titling is a matter of life-and-death prestige*, this is very close to being a definition of actual Hell.
*Derogatory until 19c. Still a trick.

Therefore, you cannot change the results handed back by the Staff Search. You can merely style them. If you are REALLY into this, what you will need to do is build a jQuery scrape and hide it in the search page, at which point it can be used to disguise key, name-based results, and possibly correct titles.

Do you really want to have your own, hacked, slow-loading, front-end return system that uses "$(.hide())" and "$(.replace())" to painstakingly re-do data entry work?

You do not want to do that. You have websites to read.

Direct your contact to HR, with an apology note, and perhaps some sad kitten clipart.

Sorry, sorry, terribly sorry.

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.

Why Sharepizzlybears?

Pizzlybears are the horrifying offspring of the two largest land predators, the polar bear and the grizzly bear. They will eat you. Fact.

Fact #1: Bears will eat you.

Fact #2: As a Sharepoint front-end developer and administrator, you need to have a stupefying combination of skills and cussedness to succeed at your job.

Effective Sharepoint administrator-developers are presently rare, but getting less so as the environment for your original self - Freelance Front End HTML5 On The Ice Floes or Paid Software Development In The Forest - gets compressed into one field, Underpaid Contractor With No Health Benefits Asked To Do Everything At Once. Sharepoint, like you, tries to do everything at once. To middling results.

 Sharepoint is a browser-based document server. It is good at version control, and telling you who last touched a given file or document. It is acceptable at backing up things that should not be deleted. It is a-okay at forms, provided you are accomplished at Infopath form development already. It has mostly useful workflows out of the box, although actually using them is counterintuitive and involves a great deal of permissioning work.*
*Most of your work will be permissioning work.

To do well with this software, you will need to be able to learn. The learning resources for it are as wide as the internet; it's broadly supported through MSDN, yet Google will be your finest resource for working out what has gone wrong today. Freelance Sharepoint developers are a bit screwed, because Microsoft's learning environment is an Ivy League college, refusing to post actual course summaries or reviews anywhere easy to find. The majority of learning resources are left to bloggers like me, or to Stack Overflow.

Because Sharepoint has been sold as doing everything for everyone, and because it has been sold to a large number of Old Guard who have never collaborated on a document before, it also has a number of very wealthy people who are also keen on Microsoft technologies. It is unwise to make them cross by suggesting that Sharepoint is over-engineered and less useful than lightweight competitors.

There is, in short, even less negotiation to be had with Sharepoint than with the offspring of the largest land predators. Good luck. You're going to need it.

Set Yourself Up for Sharepoint 2010 Development with Very Little Money

First things first! Let's get you set up for Sharepoint 2010 front end development and administration, with very little money, and almost no support from IT. We are assuming here that there is one of you, that you have administrator permissions on your computer, and that you are from a F/LOSS and or freelance* web developer position. Therefore, much of this software is free. Practically everything for Microsoft development is Expensive, because of the expectation that everyone who pays for Sharepoint has Enterprise Software Dollars**
* unsupported, underpaid, busy fighting with or for clients and now Sharepoint, too.
**A lot of dollars - which you will never personally see - dedicated to having a phone number you can call when things go wrong.***
*** Not quite enough dollars to fix the wrong thing entirely.

1. Sharepoint Designer 2010 64-bit
• Make sure you are using Office technologies on all either 32 or 64 bit. There is no mix'n'match, and if you install the wrong variant, you will be reinstalling everything so it matches.
2. Notepad++
• You will need a good text editor to do your work.
• You will not be doing this work on a mac.
• Are you trying to do this on a mac.
• Oh god. You're trying to do this on a mac. You're an idiot, you know that?
3. Boot Camp.
• Happily for you, I am also an idiot.
4. Windows 7
• Sharepoint is specifically designed to die on anything but a sealed Microsoft-only environment
• Which is why it will be one of those technologies that is a litmus for workplace quality in future
• Because proper houses that actually develop things use BaseCamp.
• Sharepoint is stored in-house and is therefore nominally more secure than Cloud Things.
• Clown Computing. Keep an eye out for Azure, even this tiny thread of happiness will soon be denied.
• I bet they named it that because it kind of sounds like "Assure."
• Which sounds like Ensure.
• Which I am certain they would prefer we "ate."
5. Chrome
• Their Developer tools are better at some things than others.
6. Fiddler Web Debugger
• Quite a lot of what you will need to do is encoded, and tough to find without it.
7. Cisco used to make a pretty okay VPN tunneller.
8. Reactivate Internet Explorer on your computer.
9. Grab Inkscape for vector graphics edits and Gimp for raster work.
10. Sweet-talk someone into giving you unlocked Visual Studio 2010 Unlocked Mega Developer Remix Edition With Passwords.
• Express has weird timeouts that mean you'll have to pay for it eventually anyway.
• pre-2010 flavours lack "make a thing for Sharepoint" project options, which means you will only be able to make a thing for sharepoint after puking levels of effort and research.
11. Inform your client base that you will not support any browser but Internet Explorer for Sharepoint purposes.
• Sharepoint relies on Active-X for multiple document upload because MS does not favour Java.
• See above Re: Sealed, Microsoft-only, high-profit-centre environment.
• Without multiple document upload, everything is madness for your clients.
12. If you are responsible for Security as well, encourage your client base to treat IE as a portal to Sharepoint and nothing else.
• Give them Firefox or Chrome.
• Try for Firefox 3 and Flash 10, which allows you to mess about with downloading YouTube videos out of cache.
13. Get your remote desktop client working, with permission to get to the server where Sharepoint 2010 lives.
14. Get all your permissions, account names, server names and etc. in place.

Got all that? Good. You're good to get started as a Sharepizzlybear.

This is going to be a character-building experience.

Getting Started

So! You have acquired a job with everyone's favourite document server, Sharepoint 20xx. 2010 is the best one to date, and one lives in hope that the future brings bright things, but it is still a miserable, shiftless experience in high memory usage and bugs that will not quit.

Sharepoint is, put mildly, no bloody fun to work with. There are approximately four people in the world who are any good at it, and they work for Microsoft.

The documentation you can find (good luck) will be full of back end solutions, hive hacking, and no answers.

None of the posts here will touch on C# or back-end development, as most of what you can do back end can be done front-end faster, easier, and without having to know what a "sandbox solution" is. People will constantly tell you this is "not supported," but as it is very challenging to find out what is supported, this may be the best you, the administrator with web development experience, can manage.

Here, then, is a blog that collates the best of the best.

Projects That Require Posting:

1. Designing custom stylesheets and master pages to make Sharepoint appear to be "fun," without crashing everything.
2. How to use the Content Query Webpart to get useful information into your page, via Heather Solomon.
3. How to structure a sharepoint 2010 information architecture
• Permissioning the architecture
• Sorting out where to put the subsites
• Customizing a useful frontpage for teams
4. Document Libraries best practices
• Naming conventions
• When to use folders (when you need folder permissions)
• What is version control
• How to make a library semi-private
5. Calendars and their uses
• Make coloured calendars in jQuery.
• Debugging the resource calendar so that it works to reserve spaces and devices.
6. Semi-private form libraries
7. Form customizations
• Getting forms to open in browser, always, rather than in Infopath
• Workflow customization
• Clayton Cobb/Itay Shakury's GetProfileByName technique
8. Customizing announcements lists such that they look nice.
9. Using RSS readers and styling them in sharepoint.