I can still count to five. 1. 2. 3. 4. 5.

I know my own name: Bjørn Furuknap (technically, it’s Bjørn Christoffer Aulie Thorsmæhlum Furuknap).

I am currently sitting in my home office in Oslo, Norway, and it’s Monday afternoon (5ish p.m.).

So, I am not mad, at least not more than usual, but I’ll still argue that lists and libraries make no sense in SharePoint.

SharePoint Lists and Libraries as Taxonomy Features Considered Harmful!

Before we become further acquainted, let me clarify the title slightly. Lists and libraries are mandatory in SharePoint, but you should never use them to classify content. Let me elaborate on what that means.

Before the days of content management, we had file shares, with the idea of storage location as the taxonomy option of choice. After all, beyond filenames, storage location was the only option.

The idea was as simple as it was a bad idea. You created hierarchies of drives, shares, and folders to structure the content you wanted to store. Put your content inside said folders, and poof, you had an archive of sorts.

However, when you stop to think about it, this is an incredibly stupid idea. Consider the following folder structure, epitomizing the idea of location as taxonomy:

Essentially, you start at the root with a Clients folder, containing in turn one folder per client, which in turn contains folders for the various types of documents.

This isn’t a bad idea, but the implementation is horrible.

First, this structure makes it very difficult to find all the invoices for all the clients, except if you were to use filenames as an additional taxonomy element (in itself a rather ludicrous idea, but I’ll get to that in a moment). The problem is that you can only ever store a file in one location, so if a file needs two taxonomy definitions, for example being classified both by type (invoice) and by year (2010), you’re out of luck.

Granted, there are ways around these issues. You could use the created date of the file to classify it by year, hoping that nobody ever copies the file to a different location. In Windows, you can also use shortcuts, or in Linux a symlink, but basically those options force you to retain a file in a specific location forever, lest the links break loose, along with all hell.

Second, and this is the important bit, you say that “Inside this folder are invoices,” but frankly, it’s only the discipline of users that makes this true. Were I or anyone to put images of my pets inside those folders, those pictures wouldn’t turn into invoices, would they? Of course not, that’s a silly idea! Everything remains what it is, regardless of where you store it.

A Coffee Cup Is a Coffee Cup

Let me explain with another example. On my desk I usually have at least two glasses of water, and I mostly keep them together on the left side of my desk. The glasses contain water, which glasses of water usually do. Nothing magical or earth-shattering, really.

I also drink at times insane amounts of coffee, even for a Norwegian. When I’m working actively, I often drink 15 to 20 cups per day. I keep my cup of coffee on the right side of my desk, simply because drinking coffee is more of a ceremony and requires more attention than drinking water, and thus I want to interrupt whatever it is I am doing while drinking coffee. When I need to use my right hand, that means I can’t use the mouse while drinking coffee, creating a natural break, albeit only for a few seconds.

However, if I were to change this scheme, and to be honest I often do, it would not create chaos. My coffee wouldn’t suddenly turn into water simply because I put the coffee container where the water container usually resides. The break I need to take to avoid burning my lips off is still required of the coffee but not of the water. The coffee doesn’t change simply by putting it in another location. It is what it is.

That’s Why We Have Filenames!

In the previous folder example, we can assume that something is not an invoice if it was named something like “Pet Picture 0001.jpg,” even if it was stored inside the invoices folder. Similarly, we can assume that something is an invoice if it was called something like “Invoice 0001.pdf.” We’ve been doing this for decades, identifying file contents based on the names.

The use of filenames and our incredibly naïve trust of filenames as indications of content is a problem, though, because the filename isn’t at all a decisive factor in the content of the file. If I were to put a Post-it note on my coffee cup with the words “Glass of Water,” the coffee cup would still remain a coffee cup. If you name your pet pictures “Invoice 000N.jpg,” they are still pet pictures.

However, most of us would still blindly believe that the content was an invoice and happily open the file. This has been used successfully by malware authors also for decades, for example in the Anna Kournikova virus, where recipients were tricked to believe that a file with a certain name contained certain content. It did not.

Filenames, in fact, are also rather ancient and should not be necessary.

Fine, They’re Documents!

Hold your horses a bit. In SharePoint, with a team site, we get a Shared Documents library. We can create additional document libraries extremely easily. However, this is actually just as silly, once you start thinking about it.

Most organizations work to a much greater extent with logical entities than they work with documents. An employee isn’t a document nor are the lunchroom chairs or the CEO’s parking space. Our clients aren’t documents nor are the invoices we send.

“Hold on!” I hear you say, with my superhuman hearing, knowing full well that you likely didn’t even think that. “An invoice is exactly a document, and it’s what I send!”

Well, you may think you send invoices as documents, but in fact, those documents are really just manifestations of the entity that is the invoice. The invoice itself is actually defined as several metadata properties, such as the invoice number, the line items, the sum, and the due date. Those pieces of metadata are the actual invoice; the paper on which you print the invoice is simply a carrier of that metadata information.

In fact, prior to printing specific metadata information on it, the paper is simply pulp. Without the specific pieces of metadata required to make the paper an invoice, the only way you can categorize the paper is by “Paper.” Imagine the archiving nightmare if everything was simply categorized as that.

Calling something paper is about as useful as calling something a document. It adds absolutely nothing of value, no more than calling something “an item.” That’s why I hate the idea of having “Shared Documents” in a team site.

Consider this: replace the word Document from use in SharePoint with the word Paper. Both are equally meaningless in a taxonomy sense. Doing so leaves you with “Shared Paper,” a “Paper Library,” “Paper Sets,” and “Paper Information Panel.” See how silly it sounds?

Granted, there is a slight different between paper and document, but the point remains; neither says anything about the contents and describes only the form or carrier.

So, What’s So Perfect Then?

The purpose of this article is primarily to show you how ridiculous the idea of location as a taxonomy feature really is and additionally show you how the default mind-set of many SharePoint installations really serves more to confuse than to clarify. We shouldn’t work with “documents” anymore; we should work with “Invoices,” “Contracts,” “Clients,” and “Employees.”

For this purpose, SharePoint has the coolest little invention called content types. In essence, content types are, you guessed it, types of content, such as “Invoices,” “Contracts,” “Clients,” and “Employees.” In fact, if you’re curious about what these weird little creatures really are, there’s already an article on SharePoint Magazine titled “SharePoint Content Types:  Why Should I Care?”

In closing, however, I would like to mention this: in most of the projects in which I am involved, I end up creating custom lists and document libraries far more than any of the other types of lists and libraries. I’ll talk more about that in a future article.

.b