Why We Don't Use Folders In Sharepoint

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

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

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

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

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

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

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

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

So, when SHOULD we support the vile Folder?

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

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

Lists, Libraries, Form Libraries

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

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

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

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

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

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

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

Form Library Management

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

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

Sharepoint, Silverlight, and Planned Obsolescence.

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

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

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

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

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

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

Begin Styling Sharepoint 2010 CSS

Cascades are the way the web runs right now. Good sites set some good styles up at the top, then they inherit them. This is a system that works because it means no-one has to duplicate work, or eradicate inline code in order to change the colour of a link. The ways to do this are well documented at respectable institutions like A List Apart. You probably have a library of handy CSS references around, which you use to remind yourself how to build kicky styles that are consistent across your content-style-format separated software.

1. Please gather those links, efficiently organized, into a pile.
2. Import them into Microsoft Word, where they will be filled with <span> tags.
3. Print them on the printer you have stolen from your client's network because you don't own a printer.
4. Take them outdoors.
5. Place them in a metal bin.
6. Light them on fire, they're of no use here and will only pain you as you attempt to fix the Microsoft tradition of styling <em>every single element by individual and inherited class name</em>.

Today we are building your root-level styling sheet.

Today's Assumptions:

• You already have an intranet, which you are trying to replace with Sharepoint.
• You have full ownership permissions on your local Sharepoint.
• CSS is already a known.
• Learn CSS: http://www.w3schools.com/css/default.asp
• You have loaded Randy Drisgill's stripped basic master pages into your site already.

Styling Basic Master Pages in Sharepoint 2010

1. Open Sharepoint Designer
2. Open Notepad++
1. Create a new file with whatever normal resets you use, and name it yourclient.css
2. Save it in your normal local working files.
3. Open Internet Explorer, and navigate to your sharepoint installation.
1. Click on "Site Actions"
2. View All Site Content
3. Halfway down, there will be a Style Library folder.
4. Open Style Library in Internet Explorer.
5. Upload your CSS to the Style Library.
6. In Sharepoint Designer, click on the All Files folder.
1. It may not load on your first try, so click something else - Subsites maybe - then click back.
2. Event handlers not passing is a common problem in everything to do with Sharepoint.
7. Skip almost every folder and browse down to Style Library.
8. Is your CSS showing up there? Good, you uploaded it correctly.
9. Open your master page, remember, the default one you made on Monday.

This is the string of code you're going to need:
<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/[YOURCSSSHEET].css %>" After="corev4.css" runat="server"/>

I like to put it in immediately after the <title> tag. Let's break down what's going on in this tag, because it might be the first and only hint you have as to what language Sharepoint is expecting in its inline code.

SharePoint:CssRegistrationSharepoint likes you to register things with it before calling them. On the server side, it appears to be running through a bucket of mixed languages, and this is how it sorts things out. You need to register all kinds of things, but Sharepoint specific things require Sharepoint specific tags.

<% $SPUrl:~sitecollection/Style Library/[YOURCSSSHEET].css %>This is some inline code (I know how much you lurve it). This code identifies itself as being part of the ASP family by its use of the percentage sign to open tags. This might be relevant to you if you have never read ASP code before, as I had not done before someone gave me ill-advisedly high permissions on their underdeveloped extranet site.
Side Tip: Learning on the job is expected, because you are an underemployed and broke contractor. Find someone lazy and steal their permissions.

Pro Tip: Sharepoint pages can be written in any of three or four languages. You can figure out which language is expected at the very top of your master page, in the tag <%@Master language=""%>. Most Sharepoint 2010 builds are in C#.

After="corev4.css" runat="server"This is the money shot. Sharepoint 2010 does not cascade properly, and therefore, you must specify that your sheet comes after corev4.css, the default Sharepoint master sheet. You must. Or it will not load, it will not cascade, and it will be overwritten.

Do not bother separating your stylesheetsSharepoint 2010 specifically names inheritance structures, commonly using the !important tag to set your fonts and things permanently, which is a huge pain in the ass even before you try to get everything to import in order after corev4.css. Here is a sample inheritance structure, designed to make the Quicklaunch (left navigation panel) turn orange:

.s4-ql UL.root UL > LI > A.

This is the sort of language you are dealing with. Abandon all standards, ye who enter here.

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

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

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

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

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

From EtymologyOnline.  

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

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

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

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

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

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

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

Sorry, sorry, terribly sorry.