Folders vs metadata in SharePoint
There’s been plenty of debate over the years about whether metadata (columns) or folders are better for organising files in SharePoint libraries. And to be honest, I’m still not 100% convinced either way.
With my information architecture hat on, it seems obvious that metadata should be the way to go. Enhancing a library with extra fields, for categorising and grouping files, allows for a lot more flexibility in display and search. But I can understand why some people are still so wedded to their beloved folders. Here I explore my experiences and observations in working with SharePoint libraries.
The shared drive rabbit warren
The obvious issue with the traditional Windows folder structures, is that the user can name the files and folders anything they want. This becomes a nightmare for teams and organisations who allow staff to save files and create folders in an uncontrolled manner (i.e. every place I’ve ever worked). Files are duplicated, named 50 different incomprehensible things and the folder hierarchy is seemingly unending.
The great thing about using metadata in SharePoint libraries is that this allows for the use of controlled vocabularies. You can chose to be as controlling or flexible as you like. A choice field can be set to allow a user to enter their own terms, or restricted to the predetermined list of terms. This ensures a high level of consistency with the organisation of files (file naming conventions are a whole other kettle of fish, though).
Using metadata also allows a file to be placed in multiple categories. For example, a document could be categorised as relevant to the topics of ‘health and safety’ and ‘human resources’, giving users two possible ways of finding the document. This is not really possible using folders in SharePoint.
Sorting and filtering
A library with extra columns can be sorted and filtered on – this is a great, basic functionality that has always been available in SharePoint. However, in my experience many people still don’t understand that a library can be treated much like a spreadsheet. They’re surprised when they realise that they can click on a column title to filter or sort their files. The feature doesn’t seem to be intuitive to the average user.
And of course, there are good old Views. There’s no point using metadata without setting up some views to make viewing groups of files easier and neater.
I use views a lot, but I’ve always found them to be quite clunky to set up and use, particularly in SharePoint 2010. I never used SharePoint 2007 – my workplace jumped from SharePoint 2003 directly to 2010 (it was a slow moving place), so it was a bit jarring. The difference in the way views were displayed were quite different – I much preferred how views were listed in the left-hand column in 2003. In 2010 they are difficult to find – and confused a lot of our users – as shown below:
I’m glad that Microsoft have improved things in SharePoint 2013 libraries, with view links displayed like breadcrumbs just above the file list. Although there’s only room for about 2-3 views and one has to click on the 3 small dots to the right of the view ‘breadcrumbs’ to see the rest.
Some scalability issues
Even within a sophisticated document library, with extensive metadata for each file, it can be difficult to locate a single item. The larger the library, the more difficult this becomes. Too many metadata options can over-complicate things and too many files can increase load times.
For a previous project, using SharePoint 2010, I created a library for the organisation’s internal corporate documents.
I began by organising all the documents (2000+) into explicit ‘document type’ groupings (I used content types, inherited from the Content Type Hub): policies, procedures, plans, schedules, templates and so on. I then created a generic ‘corporate document’ metadata schema, and added specific metadata fields for each document type. This resulted in a comprehensive, and complex, set of metadata schemas, tailored for each document type.
In the previous iteration of the intranet (SharePoint 2003), corporate documents were spread across many libraries, folders and sites. My vision was use the content types and library metadata functionality to their full potential. However, over time, I came to realise that maybe the library was too fancy for its own good.
Users, and even members of the intranet support team, sometimes struggled to find what they wanted. I created views based on each team, document type, category and so on, but even when choosing a view, it would often contain more than 100 documents, meaning the user had to click through multiple screens (using the tiny, not obvious arrows!). Even though libraries allow you to set the number of files to be displayed per page, we had to be careful with this, as the higher the number the longer the page took to load. The sheer amount of documents meant browsing was a slow and tedious task. Even when filtering or sorting, it took too long and became quite frustrating for staff. Yes, search solved some of these problems – but some users still preferred to browse, particularly if they weren’t exactly sure of the file name.
Despite this, the new corporate document library did have some benefits. For one, we knew where every document was and could trust the library as an authoritative source. Ultimately, I’m still undecided on the best way to deal with such a large amount of documents.
Folders and the fear of change
The main benefit of folders, as far as I can tell, is that everyone knows how to create them. Combined with this is a fear of change, which has been an important factor in their longevity.
Yes, it’s frustrating seeing people stuck in the same, inefficient ways of working, but how far should we go to force people to work in a way that they don’t like?
Want vs need
I believe there has to be some balance, especially if you want to get user buy-in. Users will resist and become cynical very quickly if they feel like we’re making their lives harder (even if we know what’s best for them). Without user support and buy-in a project will likely fail.
In a large organisation where de-centralised content management is essential (due to budget and resourcing issues), metadata can’t be forced. If we allow groups to manage their own team sites and libraries, isn’t it their problem if they want to mess up their own files?
These are questions that I don’t necessarily know the answer to. There are so many variables. A lot of it comes down to the culture of an organisation – its openness to change.
Based on my experiences, I think a little bit of control and a little bit of freedom are both required. In some cases, as with important documents like policies and guidelines, control is necessary to ensure everyone is working from a single point of truth. But with ‘less important’ documents maybe it doesn’t matter so much.
I should note that if you’re using SharePoint as a records management system it’s certainly very important to control documents and libraries, but this has not been the case for the places I have worked.
So, after all this I’ve come to the conclusion that metadata should be used where possible, but I’ll still need to use folders on occasion. Ultimately the decision has to be made based on the size, existing work practices and culture of the organisation you’re working in. There is no one-size-fits all solution for file management in SharePoint.