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.

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.

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.