The content of this post is my take on an issue that has been discussed before. The question is really to (a) use folders and deal with the potential confusion and difficulty of using them, or (b) use metadata and deal with the potential confusion from users who don’t ‘get’ it.
Personally I like the idea of metadata instead of folders, but (a) using metadata that is similar to what users use already to describe their folders, and (b) making use of site hierarchies, document libraries, and documents to replicate 80% of what users want.
Two great blog articles on this subject are:
The problem: Folders are deeply embedded in user culture
Folders to store digital objects like documents and photographs (and emails) have existed since computers were introduced. Folders are technically known as directories in most operating systems.
Given the history of folders on drives, users have a natural inclination to want to have something similar when they are first exposed to SharePoint. However, Windows folders and SharePoint folders are not the same thing.
To quote one Microsoft blogger, folders are ‘a byproduct of a file-based metaphor that users are familiar with’ (Pisaraek, Michael. 21 April 2011. ‘Document Sets vs Folders in SharePoint 2010’. http://sharepoint.microsoft.com/Blogs/GetThePoint/Lists/Posts/Post.aspx?ID=462)
What are Windows Folders, then?
A Windows NTFS file system stores information about the directory, not about the files stored within the directory. Information about each directory is recorded as an entry in the Master File Table (MFT), which is the main repository of information for the directory or file. Each directory and file entry in the MFT includes specific attributes, including things like date/time stamps, name and security permissions.
(See http://www.pcguide.com/ref/hdd/file/ntfs/filesDir-c.html for more information).
What is different about a SharePoint Folder?
A SharePoint folder is not the same thing as a Windows folder, despite its similar appearance. The following neatly explains how SharePoint stores information:
‘SharePoint is physically implemented as an ISAPI filter in IIS. It intercepts all HTTP requests to the web site and maps them to a SharePoint virtual site. All of the myriad sites and sub-sites in a SharePoint implementation do not exist in the file system of the server. Everything, including the files in a document library, is stored in a Microsoft SQL Server database. The SharePoint ISAPI filter interprets the URL path, then creates and returns the correct pages to the web browser.’
(Source: Felknor, Chris. 2006. ‘SharePoint PREP Technical Documentation’, MIT iCampus. Page 5)
SharePoint stores information in sites in ‘Lists’, usually known as Libraries when used to store documents. Document Libraries are a type of ‘folder’ construct that store binary objects (usually documents). These Libraries may contain a range of metadata and controls that can be inherited by objects stored within them.
By default, document libraries have folder creation enabled. Folders are a visual representation allowing information to be grouped together. However, unlike Windows Explorer, SharePoint does not display a hierarchical representation of the folder structure by default, making it difficult to navigate and maintain. A common user reaction is ‘where is the +?’
Folders in document libraries are not recommended and should be disabled for end users.
So what are the alternatives?
The three main alternatives to folders are:
- Site collection/site/sub-site hierarchy
- Document sets
Generally, users create or seek folder structures in network drives to create a hierarchical view of their information. Commonly, the higher level of folders in drives are based on the organisational hierarchy, while lower levels are a combination of business and user ways of defining or classifying information.
Site Collections, sites, and sub-sites used for collaboration purposes (based on Team Sites) can and probably should mimic the organisational hierarchy and be no more than three sites ‘deep’. Sub-sites (or the lowest level sites, usually for a team of less than 50 people, or even less than 20) should have document libraries that ‘map’ to the business activities the team undertakes. Documents may be stored in these sites.
If there is a requirement to break down a document libraries into more categories, Document Sets are a way to aggregation information and in many ways replicate the paradigm of a physical file with a range of pre-defined metadata properties that can be inherited by the objects stored within it.
This combination of sites/sub-sites/document libraries and document sets will generally meet the requirements of most business users to store aggregations of information that were previously stored in network folders.
From a recordkeeping perspective, the most common use cases for using document sets will be for where there is a requirement to maintain a relatively ‘static’ or unchanging collection or set of documents about a given subject, where the collection (or ‘aggregation’) has a specific retention/disposal class or policy. Policy documents, or documents about a specific project, would be examples.
Metadata instead of folders
Metadata in SharePoint provides a very powerful alternative to hierarchical categorisation described above, particularly where there is less of a requirement to maintain a static collection.
The downside is that users don’t understand, or take a long time to understand, this paradigm.
Metadata can be created for a site collection or site within a collection and applied to Content Types, or it can be set centrally in the Term Store and applied to Content Types stored in the Content Type Hub, which are then made available in document libraries.
In either case, users can then apply metadata to the objects; this metadata can then be used to sort and categorise the objects in any way that is permitted. Additionally, a view of the hierarchical metadata ‘set’ can be displayed in the left hand side navigation for the site, mimicing (in a way) the hierarchical view previously achieved by using network folders.
- A common scenario on network drives is to store records of meetings or committees by year and month, with folders used to separate ‘agendas/related documents’ and ‘minutes’. Using a combination of system-generated and user-defined metadata, all the information can be stored in a single document library; customised views can then be created to display related information by year, month, and by document type (and any other metadata that has been applied).
- An organisation may receive and need to manage thousands of documents per year for a service they licence or run. There may only be a few documents, per year, for each licence. Instead of trying to categorise each licence into document libraries or document sets by licence number (for example), the organisation can include the licence number in the metadata for the document Content Type and store all documents for a single year in a single document library. By using search or views, all documents with the given licence number will be displayed.
In these two examples, the retention/disposal policy would be placed on the individual document Content Type.
Organisations thinking of using SharePoint 2010 to manage documents as records need to understand carefully the implications of using folders in document libraries. As noted earlier, there is a natural (and not surprising) inclination to user ‘folders’; they are available by default. However, there is more negative than positive in using and maintaining them and they should be disabled.
But folders aren’t completely bad (or evil!)
One effective use of folders is in the Records Centre, a type of long-term, inactive document archive. In the Records Centre, folders can be mapped to the organisation’s file plan or business classification scheme. Information Management Policies in the Records Centre document libraries can be changed to ‘Libraries and folders’ which overrides IM policies set on Content Types.