When someone first shows me how they’re using SharePoint I look for a sure sign whether they understand and have implemented the SharePoint paradigm to document management—I look for a folder. Granted using an occasional folder here and there is not the end of the world and doesn’t prove someone doesn’t know how to use SharePoint effectively. But if folders are used in a similar fashion to one’s hard drive it is indicative in a lack of understanding.
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.
Great outline of the metadata for files.
We are at a transition within our company to take our existing files off our our local domain drives(Drives and folder heirarchy which does not make any sense to anyone). We have been given SharePoint repository’s for specific product subteams.
When over-hearing the “plan” the director was going to copy the folders over to sharepoint.…JOY!
I totally understand the point behind the basics of sharepoint and file properties to manage content retrieval. What I am trying to understand is how to preapre our product development teams for putting data into the library and having them leave the appropriate trail of attachment to the related documents without having to make too much of a chore of it.
Example…We receive a product complaint(web-portal workflow manager for compliance with our business policy). We then take the information and get photo’s, descriptions from related sales and product engineers etc…and then the folders begin to be created. One for photo’s one for an anlysis of a product freeze effect on current inventory and mitigation to get the production up and running again, RAIL document, etc.…
We would have a project property such as ComplaintNumber assigned to the document…Good start. Potentially the phase of the investigation (DMAIIC possibly), but the discipline needed rom people is just nonexistent.
One tool we use that is very helpful is a requirement management system that is also for compliance to business process. We understand that because we have tracelinks and connections from one document object to another. Is this kind of linking etc supported in some way by sharepoint?
Another example could be a component I need to make will require three quotes from three suppliers and they must be archived for retrieval as well as data around price and delivery needs to be extracted and entered in for calculation into lead time and product cost. Again, attaching it to the process of “Go out and get three quotes for component (1…N)” Is there some way to effectively attach (and store) related documents to say a CAD file?
I have been trying to get this going within our IT department, but they are a little too understaffed to get it going. They give me blank stares and “why would you do that” kind of looks.
Sorry for the rant…Any suggestions to a mechanical engineer who knows just enough about applciations to really muck it up quickly?
Regards,
Dave
@Dave,
I’ve a feeling you’re still thinking in folders.. hope I can help you a bit.
“but the discipline needed from people is just nonexistent.”
First thing that comes to mind is: How is this discipline managed today?
In SharePoint you have the possibility to make columns required. That way you can “force” product development team to fill in the required information. If it is not filled in the document can’t be added to the library/list.
On with these columns ’cause that is what it’s all about with SharePoint… As you state you can add a property such as ComplaintNumber to a document. So why not add some more properties like document category (photo, analysis, complaint, email, etc).
The linking from the req. management system you are revering to can achieved with grouping in a library/list, two levels deep. You can group for instance on Complaint Number and will find all documents grouped, that belong to one number.
Requiring quotes from suppliers can be done via (Nintex) workflow, send out emails and store their replies , related documents AND the CAD file in on library or list, grouped by their common divider.
The lesson here is, don’t use the CAD file as a starting point, use it’s meta data to structure your content.
In this case I think you will need the library and not a custom list since attachments in lists won’t be searchable.
HTH,
Mike
1) More items may be stored in lists when folders are used.
2) They are more intuitive to use for simple business users.
3) They can be manipulated VIA Explorer view not some less than spectacular Microsoft web interface.
4) They may be controlled using Event Receivers.
This so called “discipline” is brought about by crappy application design: EX// SharePoint … Folders could work perfectly if Microsoft made them work … infact, I’ve built a massive folder based list with meta data stored in a different list … My lookups are much faster because I only traverse files in one folder and have not a need to search them (image data) .. plus I can save as many images as I want in one list without any hastle.
Grouping makes the UI slow and ruins the user experience because column data is now hierarchical.
@Matt: Thanks for stopping by! I don’t know where you base that you can store more data with folders since the same best practice limits still exist. Custom views give high amounts of control over how many items are returned in a view before going to pagination.
While it might be more “intuitive” in the short term doesn’t mean it’s a “better” paradigm. Case in point, my wife continues to tell me how much she hates the Ribbon in Office 2K7, but when she sees the advantage to the workflow she will be glad for it just like I am. Going back to 2003 seems dated.
The explorer view is an abomination, and I hope it gets removed from 2010 (although I know it won’t). It continues to push a “file share” mentality into SharePoint and not a enterprise class document management and knowledge management tool. Plus it allows you to circumvent setting custom metadata/content types by circumventing the UI.
While not a SharePoint developer I can’t speak to the event receiver comment.
About grouping: yes it has it’s drawbacks, and I hope dearly it is improved in 2010. However, getting to know the paradigm will be instrumental in moving forward especially if your organization has chosen SharePoint as their document management platform.
Stumbled across your site while researching a problem I am having with … guess what? Folders and views.
One point, just to follow on @Matt’s post bullet #1, is that we were told by Microsoft that one way to address the impact of a large number of list items was to organize them into folders, which we are in the process of doing now.
I would assume that was the reason for Matt’s first point, but I would certainly be interested in your comments on this tactic. Thanks!
@Jim: So MS told you to add folders eh? Interesting. Did you adjust the pagination on the library, or creating views with filters?
I have also found your blog while trying to develop a simple document storage solution. A tree of folders seems to be the only valid approach.
We want users to be able to checkin and checkout multiple documents associated with a single project. We’ve created a project list with appropriate columns: customer, description, date, etc. When a user creates a new document, we want them to select the appropriate project and upload it.
But because SP lists are not relational, there’s no way to link the fields! A user could upload a document, selecting one customer, then selecting a description for *another* project. I’d end up with a row in the library, with the appropriate document, but mismatched data in the customer and description columns.
I know there are ways to code around this, but a custom application is not an option.
@Tom: Thanks for stopping by! In 2007 the only way to enforce any kind of relation between list/libraries without code is using a lookup list, but that only works on single line of text fields which kind of sucks. In 2010 this has been greatly improved, but you’re right about your current situation. The only thing you can do is apply the same column to multiple lists/libraries through a content type.
I found an interesting way around this which allows a little more content for lookup purposes.
I use it for a part number and description field combination all of the time. I have a list that has the part number and description and a lot of the specifics for a part. I create a formula(calculation field) using the typical excel alpha combination scheme using “&” symbol. To create a “PartNum_Name” field. I then use this combined field as a lookup within the other lists or doc.library you may want to reference.
This is especially helpful for issues, taasks, etc, so people know where the problem is attached.
IS this what you were trying to address?
–Dave
I found this useful, since some people know something by name, some know it by number, etc.
Its the composite fielddifferent lists.
Regarding Folders.…I found an interesting way to break people of this habit by inserting the external lookup field lists, as well as showing how the documents could look via the document library views that disable the folders, but group or filter the web part vies.
Let them make it in folders, but you also have to force them to assign the meta data to the document by requiring a field for example.
You can get what you want, you have to meet them half way. What really helps is when you show them how useful the field properties are.
Also to avoid confusion, have the property fields you wish to track as a separate lists that is hidden or leave it exposed if it is something usful.
–Dave
@Dave: You can also create a view that removes folders from it as I mention in this post.
Folders will never ever go away. The sooner we all except this and stop the folder vs meta-data debate, the better.
In my opinion we as an IT professional community has failed to not recognise the potential merger of both. It is not a one or the other debate. Current attempts at making them co-exsist range from desperate to hopefull.
We seem to think users do not understand meta-data and then go on about their dicipline (or lack of).
I have also done this untill I realised that users love meta-data, they just have difficulty agreeing on it. The legacy of folders…
…User created folders imply meta-data. The user does not realise it, but he/she is is creating implicit meta data for the documents. The typical file-based collaboration problem then becomes to create alignment on the folder structure. Point is… users have been fighting over meta-data for as long as file servers have been available to them. Pre-dating formal document management etc. They just called it something else.
Tools such as Sharepoint has largely failed to understand the huge resistance to change they will have to overcome when introdicung meta-data driven systems.
Here is my attempt at a solution:
If e.g. Sharepoint could present its meta-data as folders the problem will go away. Lets introduce a conceptuall view called: Folder View (as opposed to Grid View, Normal View, etc.)
The setup for this view would be essentially ordering the metadata in a specific order rendering a view which can be presented as folders. Done deal, everone is happy. Ofcourse they would not be able to create ad-hoc folders anymore, but they will not care if all the meta-data is there. Adding meta-data is easy and the problem is well solved in Sharepoint.
The following advantages now become evident:
1) Meta Data (real) is seemlessly used to facilitate traditional click through searching. Your user is completely unaware of the difference.
2) When a user creates a file in a specific folder, all the meta-data for the new document is implied by the parent structure of the folder. This meta-data could automatically be attached to the document, thereby removing the need to populate it. Only the difference will be presented for capture. This is a good thing because meta-data can become very laborius to capture.
3) Obviously, multiple folder views can be created, thereby bringing home the advantage of meta-data to the user. Yah!
The current sharepoint (up to 2007, since I do not know the 2010 spec) comes kinda close with the option of a Group by view. But no cigar and here is why (in order of severity):
1) For reasons beyond my understanding you may only have two levels. Epic Fail.
2) It does not look like folders so users feel uncomfortable. Fail.
3) If you add a documents the advantage as per 2 above is obviously not present. Minor Fail.
All my searches on this topic leads me to threads similar to the one, which is essentially a folder vs meta-data only standoff.
The reality is that the folder paradaigm can never be removed. It is well and truly entrenched. It can however be hijacked by meta-data (as described above).
I would be interested to here this groups thoughts on this?
regards,
CHM
@Carl: I wouldn’t say “never” to folders going away. To many pundits have said “never” in the technology space and been proved wrong. It’s just a cultural thing that takes time to unravel.
SharePoint 2010 allows metadata inheritance through folders as you mentioned in a dream state. SharePoint views also allow you to remove folders from the view to retain a metadata driven view. Metadata navigation in 2010 also improves upon this.
The “group by” option was never meant to be a folder replacement just another option in a view. It doesn’t meet your criteria for folders, because it was never meant to do so. Also, the problem with (main) problems of folders are inconsistent labels and deep hierarchies. I’m glad the group by view doesn’t go more than 2 levels.