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.
2 thoughts on “Alternatives to folders in SharePoint 2010”
It really is about understanding your business needs and retention requirements. We have only just upgraded to SP2010 so document sets were not available to us. So we used folders in libraries where perhaps we should have used document sets.
So for some transactions the folders in libraries have worked extremely well. We are having difficulties with one transaction. These documents have permanent retention but we can’t move them from the folders to the Record Centre without losing the metadata so that means we leave them as is until we convert to document sets or SP 20xx develops a way of archiving the documents with the folder metadata.
In the mean time the lesson we learnt was don’t use folders in libraries for long term retention documents.
I found this article very interesting. There are a few more content management systems out there that could be added onto the list. I have tried most of these SharePoint alternatives in the list. Just to state a few facts Google Apps is no longer free and free isnít always better. Google Apps support is mostly third parties. SharePoint Foundation 2010 couldnít be a real alternative to SharePoint. It shares a lot of the same headaches that SharePoint has like you have to be a Microsoft expert to configure all the Microsoft products that come with it. When the idea of SharePoint Foundation first came to my team and I thought it must be much easier than SharePoint but after spending countless hours of configuring Server, SQL, Foundation, and our network it really wasnít worth the time. The real problem came along setting permission for our users. The network access protocols we had to issue were a nightmare. We got to a point where it was time for a new and better system. I did a Google search for an alternative for SharePoint and came across content management systems like WordPress and Joomla. After doing some research on these two it was clear it wasnít what we were looking for.
We were looking for one platform for our users to manage their web projects from, something along the lines of a CMS and portal. We found Centralpoint by Oxcyon. At first we had our doubts because we thought the software was for the healthcare industry. Security was one of our biggest concerns but we knew if Centralpoint was used in the healthcare field that it would have a way to create roles and permission securely. Centralpoint made the transfer of data easy. It was nothing like the base model of other systems. It included things like taxonomy, rights management, Data Warehousing, Single Sign On, and Email Broadcasting. We found that Centralpoint was the right alternative for us.