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.