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).
ReplyDeleteThanks
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.
ReplyDeleteThe 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.
ReplyDeleteCharlie, 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).
Delete