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.

Hiding The Toolbar in Sharepoint 2010

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

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

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

So how does this work?

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

Sometimes You Just Need To Trust People

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

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

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

How To Remove Drop-Off Libraries

As previously discussed, Sharepoint automatically creates a tin-eared list of nonsense whenever you turn on or change any aspect of its development. Some of this stuff looks useful when it arrives, and my favourite of these is the drop-off library.

Why Remove The Drop-Off Library
Drop-off libraries are supposed to be document routing catchment basins. People upload a document and fill out some metadata, Sharepoint routes the docs according to rules set up by the admin who runs the thing. The documents go to somewhere retrievable, possibly for long-term storage. It relies on computers doing things automatically, which sounds fantastic and should work really well.

Sadly, should you set up a drop library to accept a document in an anonymous way, then someone uploads the document without metadata, the upload won't fail.

No. It will upload a doc without metadata, kick the event handler, and leave the doc in the library, issuing No-Metadata warnings periodically. Should someone then fill in the metadata, the event handler then does not re-kick. No. The document simply becomes public to whomever can see the thing. Approving it also does not kick the handler. The handler is asleep. The content router is therefore of only moderate use; you will be writing your own event handlers and your own Byzantine submission guidelines, or you will be hand-picking your permissions settings.

In cases where you've been asked to do both of these things, you will want to get rid of the drop-off library.

The Drop-Off Library is protected and comes sans the Delete This Library link. Which you need.

There are a number of blog posts on the internet about how this is very straightforward, as you can use the Client Object Model, PowerShell, or Sharepoint Manager 201x to do this chore, which must be clear to people who have been administering MS products for more than three years, but I assure you is not to the rest of us.

What is the Client Object Model?
As far as I am aware, an object model is what you use to describe the construction plans and dependencies for your software. There are twenty links under Microsoft's USING THE CLIENT OBJECT MODEL page, one of which is "Creating Windows Console Managed Client Object Model Applications," none of which are "Open a CMD browser (on relevant machine/on local machine) (screencap) and type "sudo drop (relevant-path)
ARE YOU SURE -p
YES"

Good luck learning things of use on a deadline there.

What is PowerShell?
Microsoft appears to have re-written the command line to include... cmdlets. Also a vast portal on the greatness of PowerShell. Possibly, if you already know PowerShell, or any shell, this will be useful to you. But I have twenty minutes to get rid of a load of drop libraries. This is not useful either.

Sharepoint Manager 201x Looks Dodgy
Doesn't it just! But it's from CodePlex, so it's probably okay. Probably. Be fair, your network is full of zombienets already, and you REALLY need to get rid of those libraries. There are four ditched documents in Education already. They keep e-mailing you. Fail.

Sharepoint Manager is findable in all three flavours, 2007, 2010 and 2013, at http://spm.codeplex.com/.

1. Download Sharepoint Manager.
2. Install it on the computer running the instance of Sharepoint you wish to Manage.
3. Profit! You can find the lists you're looking to edit in the folder browser, and their relevant properties in the right-hand window.
4. Navigate to the relevant site, with the relevant Drop Library.
5. Set the "AllowDeletion" to True
6. Save all changes
7. Return to your local computer from your remote browse window
8. Open your local instance of IE and delete the libraries as normal
9. Feel smug* about the world and knock off for lunch.

*Quietly, beautifully confident that you have just installed a back-end hack full of malware to a sensitive location due to your own incompetence at the field of Developing jack-squat, but even more confident that there are no drop libraries left. Decide this flavour of paranoia counts as a victory. Still knock off for lunch.

The Quicklaunch

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

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

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

This Is How The Left Nav Thinks

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

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

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

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

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

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

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

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

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

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

Breaking Down The Quicklaunch CSS

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

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

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

Another chevron, and then .menu-item.

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

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

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

Subsites Nest. Use As Few As Possible.

Subsites nest. They are like cockroaches or mice in that regard, because if you do not keep a tight eye on them, they can nest limitlessly.

This is handy, because they inherit their permissions from the main site. In theory, you need only permission the main site correctly and away you go; you can let the subsites inherit their permissions, and each one can be used to organize different material. Broadly correct use means you really can do this - finance can have a different sub-site than IT, and they can each be permissioned as separately as necessary. The trouble comes in later, when you meet your clients and become aware of their commitment wholly to bad permission structures. 

Anyone who works with Windows systems is already aware that MS sets permissions funny. Here is the speculation: because MS works with old, well-established teams, each team manages their permissions settings for their software a little differently, and they probably have no core permissioning squad with overreach for all things. So! MS stuff Sets Permissions Funny, and that seems normal until you begin working in a UNIX environment. Sharepoint subsites inherit this tendency, to break permissioning.

The other thing is that subsites under the main site inherit different permissions and different "levels" based on a variety of non-specified variables. The site itself will be fine, but the "level" it is at under the main site will affect how the subsite displays on the quick-launch. The Main site is generally counted as Level 1 (except when it is not, such as while you are in a subsite....) and the created sites are then Level 2+.

The trick here is that the quicklaunch automagically sets whether it is displaying sub-sites or pages or both, and then it gets confusing fast. Folders, in the URL, are sometimes at the same level as subsites, but they are not subsites, so they get tagged differently in front-end navigation. Or at least, they used to do; in Sharepoint 2010, the navigation is on generally shaky ground.

Because of the dodgy navigation issues, and how difficult it is to prevent Folder and Permission Nesting, it is for the best to limit the depth of subsites you support to one or two at most. At level 3, the quicklaunch becomes deeply strange, and at level 4 you basically have to rewrite everything because it ceases to inherit properly. 

Best Practices So Far:

1. No folders, ever, unless you REALLY need them for permissioning a document set with shared metadata.
2. Depth of no more than 3 subsites. Here is how your quicklaunch will come to look otherwise:
1. Main Site
1. Departments
1. Finance
2. IT
3. Collectables
1. This is all good
2. Hey no problem
3. Wait hang on something's dodgy here
4. Hey what's this door
5. AAUAUAUAGUGH GIVE ME BACK MY LEG
1. *smear of blood, something about minotaurs*
2. Projects
1. This needs collaboration
2. Everything is totally chill!
3. Man, this is such a convenient document sharing technology
4. I wonder where Rachel McPropellerGallery got to?
5. She was always so cool.

Why Is Sharepoint So Broken, Anyway? A History Lesson.

So why is it that nothing in Sharepoint quite works, even when you undo it later, or fix it, or it should be fixed but is not? Simple: there are handshakes missing all over the place. Parts of Sharepoint just do not talk to other parts. This is not part of the planned functionality of the thing, I mean, probably someone at MS really cares about the technology. It does work well in some very small, key ways.

The overall terribleness, though, is an extended part of what we call a Corporate Culture Problem. The problem is that, really, Microsoft is a risk-averse company with a risk-averse history working in an incredibly risk-forward industry, and it has not learned to hedge its bets in any sort of correct fashion. Microsoft has been late to the party while simultaneously refusing the party's best lessons for years now, then trying to make up its homework by copying the substantially better work of its peers.

The reason for this is simple: Microsoft lost all its corporate caché in the late 1990s, just as the first run of the webkids was leaving school. We'd land in the teeth of both the web crash and the recession, later, and in the meantime, although MS attracted Coupland - and therefore Gen X - it lost out on the much larger boom of the baby boomer's kids. It did this by developing a corporate strategy based entirely on disconnected systems and computer security, rather than openness, sharing, and peer review. The much larger generation of Web Kids learn by doing, mostly, because MS made its systems locked and university seemed expensive but the web itself has always been accessible. We are mostly self-taught - and likely to become moreso, as enrolment in CS programs drops.

They jumped too soon, and Sharepoint sucks because it is sharing software manufactured by a company that does not like to share at all, in any way, at any level. You can see this in the DNA of the software: there are errors, frequent ones, caused by what appears to be nothing more than bad team management. Everything is driven from the back end, in ways that once might have been good, but are no longer good, because they are not actually well-organized; organization is a function of sharing. They are dependent on assumptions and libraries that have to do with basic Windows architecture... which stops working the moment you recognize that the internet is an inherently unstable system.

But how can this BE, you ask, you who has paid good money for this system, and trusted the corporation selling it to you?

1. Sharepoint is built on seven separate base technologies, all of them huge, most of them legacy spare parts that have been dolled up like a late-run K-car and re-sold.
2. The dolling of these parts has not been well-managed, due to Sharepoint being, in large part, nothing but a weird profit centre for a long time. 
3. This has long historic roots. Microsoft fucked up at the internet way, way back - back when they were first getting into it - and have been engaged in playing catch-up as the fat kid ever since. 
4. They chased Dreamweaver with Frontpage, which became Sharepoint Designer after a rebranding.
5. Dreamweaver was terrible to begin with.
6. They missed Search and tried stealing Google's results for a while
7. Now they're stealing Apple's store design, and tablet design.
8. This is because Microsoft is a relatively old company, with a long legacy, working in an industry that is moving incredibly quickly. Their history is one of business software and risk-aversion, but they cannot make money without selling a new thing. 
9. Additionally, they are controlled by people who are uncomfortable with risk, presently unsure of  their core business, and worried about shareholder value rather than product quality.
1. This has to do with their age, which has to do with Nuclear War and The Boomers Have All The Money being a thing they were actually threatened with, where our age is still arriving, and is - see also Fiscal Cliff - likely to be more janitorial in its disasters. Cleanup in Aisle Twelve.
10. Their decisions are therefore being driven by marketing, rather than by actual use.
11. Because the company is not, even now, quite sure what the fuck the internet is for.
12. Which means that they are dedicated to selling their products to people who are afraid of the cloud
13. Want something shiny for their cash if they are going to hand it over
14. Who believe in Security
15. But are not able to grasp what in practice that means
16. And they are saddled with the buggiest, most hackable operating system and most difficult consumer-grade software because that used to be how you made money. 
17. No-one is sure how you make money now, but Brushed Aluminum and Shit Doing What It Says On The Packet is working out pretty well for most of them.
18. This scares Microsoft because, having missed out on the web, and utterly lacking any interesting technology except perhaps the xBox, where they continue to haul defeat from the jaws of victory, they are failing. Very, very slowly. You can fail for a long time before your company dies. You can make a lot of money failing, and take a lot of people with you.
19. Welcome to the life cycle of the American corporation, where, as we all know, money for shareholders is more important than people.

Unfortunately, unlike candy [Hershey's] , or beer [AB InBev], both of which are luxuries that can be put aside, the Microsoft problem has a direct consequence on the architecture of business operations in pretty well every English-speaking country. The maintenance of this software is boring, but necessary, as driven as it is by selling rather than making something worth using, and as important as it is to major corporations with a great deal of money running through them.

This is really pretty stupid, all of it, because it is like having two filing cabinet companies, and one of them simply has broken locks on everything. There is no end in sight, but the first filing cabinet company to do it better - thus far, Google - will have a mighty prize. It is already turning up in Android phones, alongside the new malware marketplace.

Unfortunately, twice, is that Google is now publicly traded, and is interested in documenting every last bleeding thing you do. It is very probably not long before this style of problem expands; how should a company be?

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.

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.