The Controversy

SharePoint 2007 brought us great improvements to how we think about storing and viewing information. With powerful options such as extensive metadata options, content types, and countless numbers of lists and libraries there were many options available to us. The folder paradigm to storing information was still present in SharePoint mostly to ease the transition from a file share to a web-based application, and it led to a debate amongst information architects on whether folders were a best practice for storing information in SharePoint.

There were people on different sides such as Paul Culmsee who see the issue differently than myself, but the good news is that SharePoint 2010 adds functionality to alleviate some of my concerns in using folders.

Setting Metadata with Folders

One of the things I was concerned about was that folders would remove the desire to create custom content types and metadata and instead use the folder paradigm that they were used to from the file share. In SharePoint 2010 we can specify metadata for a folder (which has always been a content type), and it will be propagated to the documents contained within the folders.

Setting metadata with folders

Views Without Folders

In SharePoint 2007 was an explicit option to not include folders within a view. This seems to me to be the best balance between those who prefer a folder view to those, like myself, who prefer views that are grouped. I always disliked folders (inside or outside of SharePoint), because I felt it an impediment to optimal findability (have you ever tried to navigate someone else’s document folder?). This strikes the balance between those who like folder views and those like myself who prefer grouped views.

Folder settings for views.

Metadata Navigation

Now navigation can be modified out-of-the-box in SharePoint to allow navigation by metadata and content types. Now I don’t have to mess with the terrible tree view, but now instead I can focus on utilizing metadata to optimize the navigation experience. This adds quite a bit of versatility in constructing the user experience for your end users.

Metadata navigation in 2010

Conclusion

The SharePoint team has improved the use of folders in SharePoint 2010, and they’ve also improved the experience to not use folders if you so choose such as large list throttling so folders don’t become a necessity. I hope you get a chance to play with the next version of this exciting platform.

Unlike the author’s recommendation in this post I would venture on the side of over-architecting then under architecting. Let me justify it by the following reasons.

Necessary Granularity

Creating content types that are generic work very well as parent content types that you can leverage the power of metadata inheritance on the children, but it doesn’t do justice to the variety of content most SharePoint instances contain. For instance, associating a content type entitled “News Story” to all sub-sites where a department can have their own content greatly increases content query complexity. You could add a metadata column specifying the department or query the library, but what if HR decides they want a custom expiration policy that the other departments don’t need? A new content type is necessary to support this.

Content Types for Each List/Library

Stephanie questions Shawn Shell in the article on a few points one of which being limiting a list/library to a single content type to avoid confusion to the user. First, it needs to be established that every list comes OOTB with at least two content types which are a folder content type and the generic content type for the content (document, item, etc). While you want to not associate a lot of content types to a library I see no reason a single content type to a library is a bad solution. I would be careful about creating 20 content types and then by apparent necessity creating 20 document libraries, because SharePoint provides us the ability to attach multiple content types. Shawn warns against this by being aware that the content types then guide classification. While it’s true that content type architecture has a direct relationship on classification you can’t make a blanket decision such as every content type deserves its own list/library.

Maintenance Complexity

Shawn makes a good point that content types are site collection bound and having to mirror content types between site collections can be an administrative nightmare. I attempt to mitigate this by ensuring that as much as possible that a certain type of content is bound to a single site collection. While this isn’t always the best solution, often a content type such as “HR Policy” will be bound to a single instance to store these content items to reduce content management overhead.

Choosing the Right Designation

I also believe that a lot of the confusion around where content goes in SharePoint can be greatly reduced when you take the time to correctly name both the list/library and the corresponding content types. Nothing makes me cringe more than a generic “Documents” library with nothing other than the default content types. The user is then forced into the same folder structure they had on a file share. While this might be an easy transition for an end user it’s not the optimal solution in the new SharePoint paradigm.

Conclusion

All of the people in this conversation wish to optimize the user experience of SharePoint as well as utilizing all the great capabilities inside of the platform. While each SharePoint IA is unique I would favor more content type granularity for the reasons stated above.

Presentation Resources

• ASP.NET CSS Friendly Adapters (Examples)
• xhtmlConformance Setting
• W3C Markup Validation Service
• Presentation Slides

If you don’t have Quicktime you can view the presentation on Vimeo in Flash, and my slides are available on SlideShare.

This isn’t entirely the fault of the end users mind you. Often they are simply thrown SharePoint without a thorough understanding of how to leverage it effectively. The end user simply starts uploading and managing documents they way they’ve known on the file share and/or their local hard drives. The solution to the problem is found in proper and complete training.

Let’s take a look at the major reasons to avoid folders in document libraries.

Improved Findability

If you’ve ever tried to traverse someone else’s folder structure looking for a document you know what a terrible experience it is. We often end up frustrated and still without what we set out to find. Often folder titles take on something meaningful to the original user, but even when using a standard template to folders it still becomes difficult to find documents.

Using a single Documents library that comes out of a new SharePoint site does little to explain the information contained therein. Users then look at this single document folder as the root to an endless array of folders. The better approach would be to separate out your documents into multiple document libraries with titles more indicative of their contents. It also provides a better solution for your quick launch navigation in finding the information.

Content Type Effectiveness

Content Types are the backbone of categorizing and rolling up data in SharePoint. Content Types are limited to applying only to an entire document library so if you wanted to limit a content type to appear or not appear on a folder level isn’t easy nor is in intended to do so. Content Types are made for the document library and should be a representation of the data within the library. Remember that a folder is also a SharePoint content type, and putting documents within folders limits their ability to be surface through methods such as the Content Query Web Part (as you wouldn’t query all documents inside of the folder Content Type).

The Reasons for Views

Views in SharePoint provide the alternative to viewing data within a library without the use of folders. They are based largely on metadata set on the documents from (usually) the Content Types. When adding folders it renders views in SharePoint ineffective. Views provide powerful ways to view data and switch them quickly and easily. I wish more and more I had views and metadata instead of folders in my local computer.

Security

Another big reason to not use folders is the way SharePoint handles security. You’ll notice that security is done on the list level. You can set permissions on a folder which seems like a good solution, but it’s only temporary. As your sites grow it turns into an administrative nightmare to manage all your disparate security settings. The best way is to use the groups for security on the list which inherit on up the site collection, and when you need to aberate you can do so in a cleaner fashion.

Conclusion

This is a small sampling of why folders aren’t the best method in SharePoint document libraries. While not exhaustive it provides a basis for using the powerful paradigm presented in SharePoint to collaborate and share documents inside of SharePoint.