Update: I’ve made a couple of updates related to new SharePoint 2010 capabilities.
There are many posts out there extolling the virtues of using metadata over folders for organizing information in SharePoint 2007. I certainly believe that metadata is a great tool for for classifying information, but it is incorrect to ask whether to use folders or metadata to organize information. Rather, it is more appropriate to ask when to use folders and when to use metadata. This post is not intended to be an in-depth discussion of information architecture. Instead, I wanted to provide a few pointers on when to use folders and when to use metadata. The following is a brief comparison between folder and metadata capabilities in the SharePoint platform. The context of the comparison is only out-of-the-box (OOTB) capabilities. With enough custom code, folders and metadata could be made equivalent.
| Folders | Metadata | |
| Security | Folders can be used to propagate permissions and control the access to the resources the folders contain. | None. |
| Content Type Order | Folders can control which content types users can create using the New menu on the list toolbar. Folders can also control the order in which the content types appear in the menu. | None. |
| Navigation | Folders are intrinsically part of the navigational infrastructure in the SharePoint platform. | Metadata can be used to control navigation, but this requires creative approaches. List View web parts showing filtered list views can provide metadata-based navigational capabilities. While this requires no custom code, it can be labor intensive to add the web parts to a large number of pages. Additional metadata-based navigation can be accomplished through custom code.
SharePoint 2010 Update: SharePoint Server 2010 supports the use of metadata-based navigation for files in document libraries and list items. |
| Url | Folder names form portions of the Urls of the SharePoint resources the folders contain. | None. |
| Tools Support | Most Microsoft and 3rd party tools inherently know how to work with folders in the SharePoint platform. | Metadata support in 3rd party tools is spotty. While a tool from one vendor will generally understand how to handle its own metadata, the tool will generally not understand how to handle the metadata from another vendor’s tool. This can make it challenging to incorporate metadata from multiple vendors’ tools into a single SharePoint information architecture. |
| Search | None. | Metadata is indexed by SharePoint search and will return results based on keyword searches. SharePoint Server also supports promoting selected metadata to searchable properties.
SharePoint 2010 Update: SharePoint Server 2010 and FAST Search for SharePoint supports using metadata to refine search results. |
| Sort | None. | Metadata can be used to control the order in which items are displayed in list views. |
| Filter | List views can be configured to show only the list items contained within a folder and its sub folders. | Metadata can be used to control the which items are displayed in list views. |
| Group | None. | Metadata can be used to group list items together in list views. List views limit grouping to two hierarchical levels. |
As you can see, folders and metadata each have their own capabilities and affects on a SharePoint information architecture. A proper SharePoint information architecture will contain the judicious use of both folders and metadata.
Excellent comparison. We use both here, for many of the reasons you describe. On Internet facing sites, where we don't have the opportunity to train the end users, folders are also universally understood (just as you point out with software).
Thanks
Dan
Very nice job. An elegant and useful summary. In practice I usually find that both approaches; metadata and folders; are best used together by considering these different strengths and weaknesses. This is usually the right approach I find, not trying to choose one exclusively over the other.
The funny thing is that the folder paradigm is really just another form of metadata. The underlying data store is flat with the URL path used as a piece of metadata to describe the hierarchy. The same is true if you try to instantiate a ListInstance with default data: the XML Row elements are flat, with the FileDirRef being a hierarchical string that represents the hierarchy. The last three items in the table are probably incorrect. Search against folders is actually very simple with CONTAINS CAML operator using the parent root to search for "/PARENT/". Likewise, any of the URL or path fields, exposed as calculated fields can be used for sorting/grouping.
Charlie, yes you can do all sorts of things with code / CAML, however, as I wrote in the beginning of this article, "the context of the comparison is only out-of-the-box (OOTB) capabilities." For example, searching on a sub-folder name does indeed return it in search results, but does not return any of it's child items. The sorting, filtering, and grouping comparisons are written in the same thought process, i.e. how is SharePoint's behavior different if you assign a piece of metadata to an item vs place the item in a folder whose name is the metadata (which is what many people who are new to SharePoint do).
The URL row is a bit misstated.
– URLs for multiple sub-folders become too long and truncated, therefore unusable for linking.
– Metadata Views have unique URLs which are effective linking tools.
Thanks for the comment. Yes, I've seen a lot of people get in trouble with long or nested folder names. I like your perspective on View Urls.
I know this is an older post but wanted to add another comparison. When using folders, you can populate them directly using Explorer view. When using metadata, you can upload the documents, then use datasheet view to update the metadata values.
Douglas, that's a great point. Thanks!
I know this is an old post, but adoption of 'One Drive for business is new'. What is the incentive for a business user to use metadata if most of the document he/she accesses is through OneDrive client in the windows explorer.
I have not able to convince myself and hence none of my users too.
thoughts?
That's a great point, and it fits directly into the "Tools Support" row of the table. As you say, most tools really only understand one piece of metadata about a document, namely the document's folder path. If a tool that your organization standardizes on doesn't know how to work with metadata, then there really isn't much incentive to use metadata.
That said though, without metadata all you're really getting out of your Office 365 subscription or SharePoint 2013 implementation is a web-based network file share. There is a way to integrate some custom metadata with OneDrive for business. Take a look at this Url: https://technet.microsoft.com/en-us/library/dn948289.aspx
Maybe you can use that info to convince your colleagues that metadata is useful even when using OneDrive.