- 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
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.
Friday, 5 September 2014
So, for the past year or so I have been heading up a SharePoint implementation project within Jisc. It has proved a very interesting task and has got me thinking in all sorts of directions. It has also been an extremely useful opportunity to refresh whatever professional skills and knowledge I may have and to reacquaint myself with life at the sharp end of records and information management.
As some of you will know, a recurring area of interest of mine for some time has been the shifting foci of power that we have witnessed in recent years when it comes to information creation and control: away from the organisation and towards the user and what, if anything, our professional response should be.
SharePoint, it appears to me, sits at an interesting point along this continuum. Or, more interestingly still, can potentially be made to sit at pretty much any point along it from ‘bolted down corporate repository’ (mandatory metadata, records declaration and retention management etc) to ‘free and easy user-focused solution’ (create a Team site, store content, share it with who you like). It is this range of potential management, control and usage options that interests me as I suspect it is pretty unique within this landscape. After all, if you let all your users loose with Dropbox or Googledocs, you are always going to be limited in the range of centrally defined management controls that you can put in place across it. Alternatively it would be difficult to try to turn a full blown EDRMS into a collaborative tool which is entirely at the user’s discretion when it comes to information creation and management.
So the benefit, in theory at least, of SharePoint is that it does at least give you as the information manager the potential to find your own ‘sweet spot’ on this ‘continuum of control’: to decide which elements you want to enforce and which you wish to leave to the user’s discretion; to determine how much information management policy and rigour you wish to implement, and how much you want to leave to individual whim. Finding exactly where this sweet spot is for your organisation is, it seems to me, half the key to success when it comes to implementing SharePoint: enforce too much control and you may find it a near impossible feat to convince your users that they should abandon their GoogleDocs accounts for it; but include too little and you may find you are simply replacing one unmanaged and ungoverned mess of information with another.
And, of course, if our experience is anything to go by, you are likely to discover different sweet spots exist from department and department and function and function within your organisation with some users demanding a level of rigour and governance that others would find totally off putting. Trying to be ‘all things to all men’ may seem like a tall order, and perhaps it is from a practical perspective but at least it is theoretically possible within SharePoint.
Yesterday I took part in a UCISA Webinar that explored some of these themes and which explained a little about the decisions that we have taken here at Jisc with regards to managing information and records within SharePoint. I started with a brief(ish)overview of some of the history that has shaped the interplay between user andorganisation with regards to the management of information and a copy of the script for this is available. I also gave a presentation which explored how we have approached SharePoint withinJisc, and in particular how we have implemented the types of records management controls that we consider appropriate for our needs. The whole Webinar is also available for downloading (1.5 hours) if interested and which not only includes the above with narration, but also a presentation on University of Highlands and Island’s experience of using SharePoint and all the questions and discussions surrounding the presentations.
Now that I have got the blogging bit between my teeth again I’ll perhaps elaborate a little more on the approach we have taken in future posts in the near future but think this is probably enough to be getting on with for now…