06-13-2011 – Updated based on post comments.
I am asked on a regular basis how I feel about the use of Document Library folders. To be honest, I always tell people “avoid them”. This response always stirs up controversy so I though I would write this article to help you
better understand my thinking.
Before I dive too deep in to this article, I need to first say; there is no right or wrong way of implementing your document management solution. There are simply better ways of surfacing information and improving the user experience. If you are concerned about findability and user adoption, then read-on! Another prerequisite to reading this article is to say, this is not a black and white topic; meaning, its not an all or nothing issue. I believe document library folders have a place and can be used when done so in the correct ways. Do I use them in my implementations? Absolutely… However, I do so in a very limited manner and very specific ways. With all that said, lets move on…
First, lets take a look at why you would use document library folders. The only reason that immediately comes to mind is; because that is what we are used to doing! I personally don’t think this is a great reason, but it does hold truth.
Now lets take a look at why we shouldn’t use document library folders; or ways of improving the users experience.
Navigating document library folders is not the same as what users experienced when storing/managing files on file shares and other drives. The tree view, with +/- to expand/collapse branches, doesn’t exist in the out-of-box Document Library Web Part. Navigating down a folder branch requires the simple click of a link. However, navigating back up the branch requires the user to click the browser back button. This is a cumbersome user experience at best.
Just so you are aware, there are options to help solve some of the navigation issues described above. You could write a custom Web Part, find publically available code or purchase a 3rd party product (a couple of examples are below). There is code and products available. However, I would first recommend you continue reading because these products won’t solve all of the problems you will have.
In addition to the navigation issues described above, folders hide the content contained; especially when you use sub-folders. For example, when a user arrives at a site and they see a library named Shared Documents (which I also don’t recommend), first off the name of that library doesn’t tell them anything about what it contains. Also, if the user clicks on the library, all they see is the first layer of folders. This may begin to indicate what files are contained within those folders but doesn’t suggest anything about what might be contained within sub-folders. Again, hiding content and detail from users; forcing them to traverse folders until they find what they are looking for. Not very efficient at all.
Remember, if it takes a long time for a user to find an important document, quite often they will make a local copy for future reference; so they don’t have to go through the pains of finding it again on your Intranet. Findability is extremely important.
I also have to make a comment about folder-level security; avoid it at all costs! The use of it can and will become confusing for your user-base. I have seen structures become so complex, contributors loose comfort knowing where to store and manage their content. And what happens when contributors loose comfort and security with the solutions we implement? They stop using them and go back to what they feel secure and comfortable with… Something else to remember, security is one of the most complex features to teach a non-technical user. If you are expecting your non-technical user-base to manage item and folder-level security, it will eventually be done so incorrectly; this brings up a while different set of issues (good topic for another article). And, if you aren’t expecting the general non-technical user to manage their own security (which is good, I don’t recommend it) then you are placing the burden of that management on Site Collection Administrators, IT or whomever you have it assigned to.
Lastly, lets talk about content duplication. Content duplication occurs in an organization in many different ways; so many that we don’t want to add to the problem. Folders hide content. As such, if it takes a long time for a user to find an important document, they are more likely to make a local copy of that document so they don’t have to find it again in the future. Another way duplication occurs by using folders, is by simply needing a document to be present in multiple folders. For example, lets say you have a document that is related to 2 of 3 areas of Human Resources Benefits; related to Medical and Dental Benefits but not Vision Benefits. If you have benefit documents broken down in folders by benefit type (which is common), you may have to duplicate this common document in 2 places. Again, we have to avoid the duplication of content on our document management system at all costs. It’s called single source of truth!
So… what can be done to solve these problems, improving the user experience and overall findability?
First and foremost, consider using metadata! Whether you choose to continue using a Document Library named Shared Documents or not, I would recommend you start applying Content Types and metadata to your documents. As a simplified example, move all of your documents in a library to the root folder and apply metadata that can be used to filter the view. Still not the greatest user experience; however, a user will at least be able to see all of the files contained within a library simply by clicking the library link. They can then filter the view down using the metadata column filtering abilities built in to SharePoint.
Using more Document Libraries is an even better approach to solving the overuse of folders issue. Let me demonstrate; a user arrives at a Human Resources site and is presented with a Document Library named Shared Documents, with folders and sub-folders. Well, you already know how I feel about this user experience. Now improve the experience for the user by creating multiple Document Libraries; one named Medical Benefit Documents, another named Dental Benefit Documents and another named Vision Benefit Documents. Using this approach alone will significantly improve the user experience from a findability perspective. The Medical Benefit Documents library has a Content Type associated with it named Medical Benefit Document; which forces the contributor to store and manage only documents of type Medical Benefit. This also helps with your overall IA too; but that’s a whole different article series! Just be certain to not have your Document Libraries so generic that you have to manage too many Content Types with it; this can also be confusing for contributors.
Another approach, and one I use all the time, is to build your hierarchy with sub-sites. Take Human Resources Benefits for example. You may be better suited having a Benefits sub-site then sub-sites below that, one for each specific type of benefit (Medical, Dental and Vision). There are many, many advantages to using sub-sites in this manner. Sub-sites, used in this manner are really nothing more than what is called “a point of aggregation and association”. Let me provide you with another example. On a Medical Benefits sub-site you can store and manage related announcements, policies, procedures, forms, FAQ’s, glossary terms, links to external references and so on. You are basically bringing the user to a new level of experience when you aggregate all information associated with Medical Benefits on a single sub-site.
Another advantage to using sub-sites as a point of aggregation and association, is realized when you begin to aggregate content to a higher level on your Intranet. For example, if you choose to aggregate all Policy Document (documents of type Policy) to an aggregate view using the Content Query Web Part, those policies can be grouped by site/sub-site. This is a very useful view and cannot be produced automatically using folders.
So how do you handle the folder-level security confusion issue described above Bob? Great question, and I’m glad you asked! Remember, my implementations utilize sub-sites and multiple document libraries. I simply place a Content Editor Web Part above the Document Library Web Part and use it to describe the libraries intended use and security. I target this Web Part to the contributor audience so it is only displayed for those who are contributors on that specific site or page.
The document management/Intranet solutions I have implemented, contain a wide rage of the techniques described above. The actual implementation techniques used all depends on the size of organization, amount of content, contributors, consumers, security and a myriad of other requirements. It is my hope that some of these techniques help with your next implementation or give you ideas of how to improve your current implementation.
If you have any questions or comments about this article, please leave them below!
Until next time…
06-13-2011 – UPDATE
A few great comments on this post prompted me to make the following updates to this post.
As Paul indicated in his comment, there are situations where folders can be used to manage content; just because of the sheer amount of content being managed. I don’t necessarily feel that thousands of clients and contacts should drive this, but I am not completely familiar with his requirements. I am going to write an article about how this type of situation may be better solved using sub-sites instead of folders.
None the less, there are some situations where folders may help. In the past there have been limited occasions where using folders made sense. In these situations, the implemented used was driven by workflow. This was done to manage the security and consistency of that implementation. As I look back at those implementations, I would most likely do them differently today and use sub-sites.
I also want to note that Chris Poteet also has a nice video on this topic. It can be found on his site here.
Information Architecture Institute
FeedBurner