- Don’t create sub-folders (folders within folders). This creates long URLs which will break SharePoint’s in built maximum URL length and cause errors
- Whilst you can drag and drop items into folders it is then not easy to move items between folders
- Moving an item will change its URL, breaking any direct links to it that you may have created and shared
- Once contained within a folder it is harder to incorporate the individual items within any Document Library-level retrieval or sorting by metadata
- SharePoint will not prevent the same item being uploaded into multiple folders, increasing the risk of duplicate information existing within the system.
Wednesday, 24 September 2014
Finding the SharePoint sweet spot
I have written in the past about the importance of information professionals placing a higher priority on user needs, and even perhaps preferences, than has traditionally been the case. Citing the failure of many an EDRMS implementation as primarily being down to these having been a technology designed around meeting the needs of the information manager rather than (and arguably even at the expense of) the end user.
At the same time there are, of course, limits as to how far any system designed to serve the needs of the many – perhaps even an entire organisation – can be successful in meeting the needs of each and every user. Creating a hundred different systems, all based on individual user whim and with no sense of underlying unity or consistency will obviously and inevitably just create its own set of problems: not least the failure to create something which can in any way be classed as an ‘enterprise wide’ solution.
One of the reasons I like SharePoint is that it does give you the potential to try to span these competing demands. The concept of Team Sites allows you to create solutions that can be bespoke to each function or team: upping the structure and controls where they are required, but easing them off where they are not; whilst doing so within the context of a shared enterprise wide ‘tenancy’ and within a general underlying framework that is yours to define. This ability to customise and to push hard or to ease off the information management controls as local circumstances dictate seems to me to be one of the main distinguishing features between SharePoint and some of the EDRMS of old.
Of course the challenge for the information manager is still in achieving the correct balance between local freedom and required central management: wherever on the spectrum the particular function in question may exist. To be able to find the ‘sweet spot’ that makes your system at least as attractive as the personal solutions they have devised for themselves, whilst not compromising further than you know is wise in terms of corporate information governance and management. Push too far in one direction and you risk creating an elegant and robust corporate solution on paper but which no one actually uses; push too far in the other and you risk just replicating existing problems in a new environment.
I’ve had cause to consider these issues in recent weeks as we have made the decision to reverse our previous system governance rule that did not allow the use of folders within SharePoint Document Libraries. There is plenty of literature out there confirming that our original ban is the sound way to go. Some of the reasons cited have a logical technical basis (the risk of creating lengthy URL’s that break in built system limits, for example). But beyond this one of the main reasons repeatedly cited is that use of folders for resource discovery and content organisation purposes is not as good, as flexible and as sophisticated as using metadata, columns and views to achieve the same results. This may well be true. Use of metadata etc does open up a host of possibilities that folders do not and for those prepared to take the leap of faith and immerse themselves in this way of working it is undoubtedly beneficial. The problem is that (in my experience at least) only a small minority of users are prepared to abandon the folders based approach to working that they have spent the past decade or so working perfectly happy with. If I had a pound for every time a potential or new user has asked me how they create a folder in their team site I would be a happy man. The same would also be true if applied to every user who was left looking disappointed and (to varying degrees, sceptical) when told that the combination of metadata and views make folders redundant.
The actual catalyst for us making the decision to allow folders (with caveats) within Team Sites was not, actually, just the weight of user opinion, but a growing requirement for site owners to be able to restrict permissions to certain content within their site. Yes, there are other ways this can be done and we do prefer this to be done at a Document Library level but this does seem like overkill for what is often just a handful of 'restricted' items. But we eventually came to the conclusion that in most cases the use of folders with unique permissions within a document library was the most straight forward and proportionate approach. It also had the effect of giving us the opportunity to re-evaluate our previous position.
Here's a list of the caveats and cautions we have communicated to our Site Owners:
Is there a risk that users will forget our caveats, abandon metadata wholesale and replicate entire filing systems within SharePoint? Possibly, though (we think) unlikely. It is certainly something we shall keep an eye on and work with Site owners in the months ahead to nip in the bud if it looks a risk. Will it help increase the general usability of SharePoint to the end user and its attractiveness as an information management environment? Definitely. And, for now at least, that makes it a sweet spot worth seizing.