A long time ago folders where invented to organize computer files. Computer geeks thought up the idea which mimicked physical file folders, hey, works for office geeks why not for us. The idea was good for a while but it was not great. Let’s examine a scenario. You go on a business trip, go out to dinner, and have a receipt. You have two folders, one for the client you took out for dinner, the other for the project you are working on with that client. You need both folders because of different papers you need to organize. So where do you file the dinner receipt?
If you are like an executive assistant I recently met, you copy the receipt and put it in each folder. Solves the problem, correct? NOT! We just duplicated data. What happens when we get audited? What if the files get combined? Let take a look are what folders are doing for us.
People think folders are about organizing information, but they are not just organizing they are telling us ABOUT the contents of the folder. If we put a receipt in a folder for client X then then we know this receipt is for client X, if we put a receipt in client Y then the receipt is for client Y. The folder, indirectly, tells us about the client because the receipt is in the client’s folder. Moving the receipt from folder X to folder Y changes the implied (client) information about the receipt. In a physical file system copying the physical receipt may make sense if duplicates are okay, but in a computer system, duplicate files are bad.
Bad! Why?
Let’s look at SharePoint. In a document library people create folders to organize files, but if the file belongs in two folders what do you do? Copy the file? Which do you edit then?
The solution in SharePoint is to tag the file with all the information relevant to the receipt. So a single receipt will be tagged with client X and project Y. In document libraries tags are columns that you add. So when adding a file you have columns identifying the project, the client, and so on. In fancy terms we call this meta data (data about the content)
In document libraries you have the ability to build a filter (called a view) to view documents based on the tags in a Document library which allow you to say: “show the files for client X” or “show me the files for client Y” and the same file will show up for both scenarios without the need for a copy!
Let views, and meta data help manage your information and you will not get into trouble with folders.
Later I’ll tell you that file names should be random character. Stay tuned.
Gord
Your comments about folders in SharePoint are valid only if a SharePoint document library is being used as a “bucket” for holding documents in an uncontrolled way.
Indeed, the folder concept can lead to duplicate copies of a document, if the documents are able to be copied into SharePoint by end users.
However, SharePoint now offers the ability to have documents inherit metadata from a folder. In a controlled environment, a user should not have to worry about where a document resides. By using a drop-box approach in SharePoint (a web part that is available in 2010), rules can be set up so that the user just drags their document onto the drop box, and then the document is moved to the correct document library & folder based on rules. (This can also be done using workflows.)
Once the document is in the correct folder, it inherits the correct metadata from the folder.
So – in short I disagree that “folders are bad”. Their is no metadata inheritance at the doc library level. Take away the folders and where do the documents inherit their metadata from?
Hi Mark,
I agree with your comments and do think folders have a place in SharePoint if used properly and with SharePoint knowledge and functionality. Unfortunately, from my observation folders are used in SharePoint the same way there are used in network drives. A way of trying to organize a big bucket.
A wonderful job. Super helpful irnfomatoin.
How bad an idea is it to create a primary categorization in folders, and then to apply tags after that to create the necessary linkages?
The problem with SharePoint (in my opinion) is still that the browser interface is limited for document browsing (SP 2010 is a great deal better than MOSS 2007, but stil has limitations). If everything is in one library, using tags, then browsing does not have the Explorer option.
I find our clients are using the folders in the “old fashioned” way. This is how they have been trained to visualize data storage. It will be up to us to perform “change management” and retrain our clients in a way they can understand and see the whats in it for me” factor. Tags are good, but we must find a visual/kinesthetic way to teach our clients why they are so good.
Good point!
The only problem is how to convert the existing millions of files in network folders to files in SharePoint with tags, and how to let users get used to tags……
But how about permissions? If the file is inside of folder, it inherits permissions from folder. So if i have folders for different user groups i am not forced to explicitly define rights to each file.
The ugly situation comes also with use of Sharepoint Workspace, where you have all files in one hump – if no folders.
Hi Pavel,
I think Document set is much better than sub folder in that case.
Security is one place that folders do make sense. However, I question if a different document library, or even a new site makes more sense. Setting security at the very granular level in a site can get messy.
Gord: I agree re: your comment on security. I think that while folders for security purposes may be ok, a separate library might be better. Unless we are talking about only a few fairly stagnent documents, teaching the content owner about loading to the sub-folder could be challenging (at least in the environments I work in. So, if multiple current and future documents need to be secured, it might just be better to have a separate libary based on the same content type.