How to Implement a “Folder-less” SharePoint Environment – Part 2

As promised, “Round 2” in my series where we discuss the advantages of using metadata over folders in SharePoint.   I found a good example of why metadata is valuable in document classification I would like to share:

Although a great deal of information (and opinions) is available on the web, most of them favoring the use of metadata instead of folders, I’d like to add some samples that I use in my daily work.  Please notice the quotes, intentionally put there to stress that using SharePoint instead of file shares is much more than just a migration: it’s a whole new way of work! However, that’s a bit out of scope for this article so let’s stick to metadata versus folders.

We love to structure our data…

… And that’s actually not a bad habit. A common scenario for customers is a file share for project teams that structure their data based on some properties of their projects, like the following example:

• Division A
• Department B
• Project C
• Stage D
• Document 1
• Document 2

People have worked like this for ages and seem generally satisfied with this solution.

Not so structured after all?

The sample above can work as long as:

• There is good governance on the structure
• There are not too many levels
• You do not have to share documents across projects

There might be more properties available than can be used without creating a ridiculously complex folder structure:

• Author of the document
• Create date of the document
• Customer
• Version of the document
• Project year
• Etc.

Often, extra data is stored in the title of the document, like “pid draft version 0.5 – modified by John – to review.doc”. From the title, you can get extra information: it’s a Project Initiation Document (pid), it’s not final, it’s been modified by John and should be reviewed. What if it had not been called pid but “prj. in. doc.doc”? It’s still a pid, but would you immediately recognize it as such?

Creating duplicates

Using folders for structuring files might work when these files stay within that one folder. However, some files belong to more than one folder. In the folder structure above, ‘Document 1′ might also belong to ‘Project F’. The general solution is creating a copy of the document, causing the following major problems:

• Not clear which version is the latest and greatest
• Not clear who is the document owner
• Need for extra storage

The route to finding information: vertical/horizontal navigation

A folder view is a vertical way of finding information: you’ll find the document via a vertical path that someone else has defined. That path might not be the one you want to follow. A great example is a second hand car site. On that site, there are thousands of cars available and you are looking for that one car. Suppose the site had been structured with a folder view, like:

• Brand (e.g. Mercedes)
• Model (e.g. 320)
• Fuel type (e.g. Petrol)
• Color (e.g. Silver Metallic)
• Mileage (e.g. 70k-80k)

That would work if you’d been looking for a Mercedes. But what if you’re looking for a car with the following criteria:

• Not more than 5 years old
• Petrol
• Mileage between 50k-80k
• Hatchback
• Price between $20k-$35k

The folder view above won’t work for you as you’ll have to browse each (sub) folder to find cars that match some (but not all) of your criteria. You don’t want a vertical view, you want a horizontal one!

To map this to information within your organization: you might be able to find the information you’re working with because you know the folder structure, but what about all the other employees that might be looking for that information? What about the manager looking for the latest project status reports for all projects?

Did I mention metadata?

We use metadata more often than we think. As Wikipedia describes it: Metadata (meta data, or sometimes metainformation) is “data about other data”. In the car example above, the properties of the car are its metadata: information about the car. So if you’re looking for a car (age, mileage, etc.), a partner (gender, hobbies, etc.) or house (type, price, etc.), you use metadata to filter. As you can see, each type of object I’m looking for (car, house, etc.) will have its own metadata; it wouldn’t make much sense to filter on fuel type for a house.

The folder view allows you to add metainformation implicitly, i.e. the location where the item is stored defines its metadata. Once the item is moved to another location, it loses that meta information. Using metadata on the item itself, means that metadata becomes explicit. No matter where you store the item, it keeps its metadata. There are some technical requirements to achieve this, but that will be explained next.

Metadata with SharePoint

Although it’s possible to create folders in SharePoint document libraries, I generally do not recommend it: see the sections above. SharePoint implements metadata as columns. End users sometimes find it hard to grasp this concept, but then I use the example of Excel. Almost everyone in an organization has used Excel so a spreadsheet like the following should look familiar:

Most people also know you can apply filtering in Excel:

And that’s also how SharePoint works! (Plus more)

SharePoint stores items in lists/libraries and uses columns to provide extra information about the items. SharePoint even allows you to store different types of items (remember the car, partner and house) in one list using so-called content types.

Using metadata, users can now apply filtering, sorting and grouping on the data, either directly or with views.

Flat view:

Grouped view:

Retaining metadata when moving items around

I’ve already mentioned that SharePoint has ways to keep the metadata with the item. Using Content Types is a great way of applying the same metadata structure to lists and libraries. When the item moves to another list that has the same columns, it will keep its metadata. Office files have an even better mechanism built in as metadata is contained within the document itself! Try it out yourself by adding metadata to, for example, a Word document in a library. Now copy the file to another library that does not have the same metadata columns yet. Once you have added the same metadata columns (use the same internal name for the columns!), they will automatically show the metadata. Beyond cool!

Conclusion

Metadata in SharePoint allows for a much more flexible way of structuring your data than using folders on a file share. When you want to implement SharePoint, leave the folder way of thinking behind and start thinking in more dimensions!