Web Parts, Why-eeee

Web Parts are things people have written that plug into the more front-end portions of the Sharepoint infrastructure. They are used to control and display your back-end information. Although there are a plethora of them, in practice you will be using only one or two. These are the Content Query Webpart, in Sharepoint 2007, and Are All Of These Actually The Same Thing? in Sharepoint 2010.

Sharepoint 2010: Drop A Block In the Page and Call It A Day
All lists (everything is a list in sharepoint) can be displayed as webparts, which are functionally tiny windows within windows with their own display settings. Each list you have on a subsite automatically generates its own page, with a webpart in it, which displays the content of the list according to settings you choose in the toolbar, hopefully while sober and lacking the flu.

Document libraries, calendars, everything - you set what to display on their page, and then all future views of the list will just load those settings, correct?

False.

Those settings are not centralized, they are page-specific. That means that every time you need to load a given view of a list into a page, you're gonna be setting how you see that list. Even if it is an extremely specific set of preferences about, say, group selection and display.
JOB SECURITY.

There are ways around this - for example, setting everything on the one calendar page and then exporting the webpart with all its settings, and loading it to whatever page you end up with - but in practice, this will lead to you storing hundreds of XML files with various almost indistinguishable webpart settings, which you use in two places on your site; the first where you made it, the second on the landing page for the subsite. Not particularly efficient in real terms.

So in practice,  you get to hand-edit every homepage, and prepare to answer a lot of questions about where the documents are actually living. This is marginally better than managing check-ins, and slightly worse than sorting out version control.

Performance Management Easy Achievement High Score
Do you need to game a performance management system in advance of Spring Review? Oh shit you might. Great. Customize twenty of the damn things and stuff 'em in a folder and then you suddenly have quantifiable job metrics for data-driven review. Well done you. Your horrific cynicism will carry the day yet.

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.