Metataxis are pleased to announce that public sector organisations can now access our services through the latest G-Cloud 9 framework.
Cloud services, such as O365/SharePoint Online, require careful planning, design and governance to be successful; however all too often this is just seen from a technical perspective rather than one based on the information and the user.
Metataxis can help organisations meet these information management and information architecture challenges that make the difference in being able to support long term adoption and deliver real value.
Metataxis offer a number of services on the G-Cloud:
If you would like any further information then please contact us.
My article ‘Getting SharePoint right: Thinking about the ‘big picture’’ in the Journal of Digital Media Management is now available online. See Volume 4, number 1 at www.henrystewartpublications.com/jdmm/v4.
The blogosphere is full of SharePoint consultants proclaiming how folders are a terrible thing. Many of the articles are from, I suspect, SharePoint consultants who have just realized that information architecture (specifically metadata in this context) is something useful, and aren’t sufficiently concerned about bringing round change-averse users.
Before I explain why some folders may be a good thing, let’s look at the standard “why folders are bad” list…
- Nested folder structures are usually specific to an individual user or team. True, but so can metadata be. This is isn’t an argument against folders, it’s an argument for naming things consistently and governing what they are named. i.e. have a well managed taxonomy. Also, as with metadata, it can sometimes be useful to have a truly local name for something, either because it really is a local thing, or you want to build buy-in from your users by letting them sometimes give things their own names (I am not saying there should be a free for all, just some concessions, sometimes).
- Folders tend to make content hidden. Yes they can, again if poorly named (like metadata). But this assumes hiding content is a bad thing, when in fact it can be a good thing. Namely, it’s useful to just show users the things that they care about in that moment, with nothing to distract them. This exact argument is the reason SharePoint views are so useful and powerful.
- Folders eat up the fixed portion of the SharePoint URL. Yes. Agreed. But only if you go crazy with folders. See my rule of thumb below.
- Moving files from one folder to another changes the URL if you link to it. Yes. Agreed. Especially if you don’t have an information architecture. But luckily there is a way round this – have an information architecture. If you have a good information architecture, content tends not to need to move around much if at all. Of course if you move documents into a different library the URL will break. The real answer to link rot is use document identifiers, that don’t contain their location. SharePoint provides such functionality (more or less).
- Maintaining security by folders in SharePoint is an administrative nightmare. Yes. Agreed. But something you often have no choice about, even with a good information architecture. Also, what’s the alternative? Rather than creating a folder to delimit the security, create a new library, or a new site. That’s just as bad (possibly worse) at fragmenting content.
- Finding documents is difficult. Yes. Agreed. It can be (see the need for an information architecture, ad nauseum..). But less so if you use folders and metadata. Check out standard SharePoint view functionality on how to do this. Sometimes the folder structure makes it easier to find what you want. We know that search doesn’t always work, whether you’ve got metadata or not, because you don’t know what you don’t know. Folders allow you to browse, which is frequently very helpful.
- File duplication. With folders you can store multiple copies of the same file in different folders. Yes. Agreed. But you can do this without folders also – across libraries and sites. Folders can make it worse, but file duplication across sites is far more common (many teams copy documents to their team site to ensure they can always be found). If this argument is simply extended, why not put all 30 million documents in one mega-library!?
- With folders there is only fixed one view. Yes. Agreed. But only if you only use folders: why not use metadata as well and get both the options? Why deliberately remove a useful way of organising and finding content?
- Sorting and filtering isn’t possible. Yes. Agreed. But only if you only use folders: why not use metadata as well and get all the options?
- Changing folders is harder. Well, sometimes. But change should be not so common with a good information architecture. Also, changing lots of metadata isn’t always easy either. Cut and paste between folders can be much easier.
- You lose context when navigating. Not really. There many ways of showing the folder context in SharePoint. Also, just using metadata can be worse, especially if you use multiple columns and filters simultaneously.
- Using nested folders is just like having a file share, why even both with SharePoint? Yes. Agreed. But only if you only use folders: why not use metadata as well and get all the options? Can you spot a trend here…?
- You can’t see how many documents are in a folder. Yes. Agreed. But only if you only use folders: why not use metadata as well…
- When you allow users to create folders, you are prone to misspellings and so on. Yes. Agreed. That’s why you need active governance, and templates (i.e. an information architecture). Metadata can be much more easily made consistent, but that requires upfront effort and ongoing management. All this is good, but you haven’t improved the situation by disallowing folders, you’ve just moved the problem somewhere else.
And now for the reasons why folders are OK in moderation.
- Usability. Users like them, a lot. You will have many other battles to fight with users when you ask them to use SharePoint. It’s very useful to give them something familiar while you simultaneously introduce them to the benefits of metadata, search, views etc.
- Grouping. Sometimes users need to have a loose grouping of content. Looser than a document set, and looser than can be easily defined using one or more metadata tags.
- Permissions. Folders can be used to group user permissions. See above. Not ideal, but much better than file level permissions.
- Default metadata. Folders can be used to auto-populate default metadata. This is one of my favourites. Ask a user to fill in a metadata field and they will baulk. Ask them to add a file into a specific folder (with default metadata) and they won’t blink an eye. Agreed that there are many issues with doing this, but with a stable information architecture it is achievable and results in good metadata with minimal user effort.
- Retention and disposal. Folders can be used to hang retention and disposal rules on. Of course content types can also be used for this, but sometimes that doesn’t fit your content so well.
- Hiding. Folders can be used to hide content. See above. It’s useful to just show users the things that they care about in that moment, with nothing to distract them.
And to round off, my rules of thumb for SharePoint folder use are:
- Many document libraries will not need folders. How many depends on your information architecture, which in turn depends on the content, context and users in your organisation.
- One level of folder is acceptable, but you have to convince me. I’d say I’m convinced 50% of the time.
- Two levels of folder are acceptable, but you really have to convince me. I’d say only 10% of libraries can justify two folders deep.
- Three levels of folder are not acceptable. If you need them, your information architecture is wrong. It needs shifting up a level, so that your one deep folder becomes a library, your two deep folder becomes a level one folder etc. (on some very rare occasions I have felt three levels of folder are permissible, but this is only in cases of very structured content).
To wrap-up, SharePoint folders have their place, and can be used in moderation. But don’t go crazy.
Managing your information, and implementing a system to do it, is a complex task with many knots that need to be unravelled and it takes time to get it right.
All too often the focus of a project implementing such a solution is on getting it done rather than doing it right. Too much effort is spent moving the projects through various gateways rather than spending time on actually thinking through what needs to be done.
Information management systems such as SharePoint too often founder and ultimately fail to deliver the desired benefits because of this. Typically a system is rolled out successfully (i.e. on time) but it quickly degrades and information chaos ensues leaving users frustrated, information difficult to find and impossible to manage. In all likelihood you’ll end up with another project to put it right in a couple of years.
This situation can been avoided.
Proper thought must be given to understanding where you are and what you information landscape looks like. How can you build a system to manage your information if you don’t know what you’re intending to manage?
You must develop an information strategy so you know what you want to achieve and how you are going to go about it.
You must take time to design an information architecture that meets the needs of your users. This is vital to enable you to organise, describe and link information and the key to the efficient and effective use and management of your information.
And don’t forget about putting in place governance – without support, oversight and nurturing your nice new system will quickly end up a chaotic mess.
Remember that rolling out a system that meets a deadline doesn’t mean that you have a successful solution.
Think, plan, design – don’t just ‘do’.
Many SharePoint implementations are unsuccessful. They do not deliver business benefit, are too expensive to build, too expensive to manage and are difficult to use by the stakeholders they are seeking to help.
SharePoint is a large, pervasive and complex system and as such is subject to the usual reasons for failure of all similar sized systems; but SharePoint in particular frequently fails because it has no information architecture underpinning the content, users and context of the organisation’s information environment. In most cases this lack of an information architecture is due to the implementation being IT driven. SharePoint in all but the most trivial of implementations is not an out‐of‐the‐box system – despite what many people believe and the Microsoft marketing machine suggests.
An Information Architecture within SharePoint is crucial because there are many design and configuration decisions that need to be taken before the implementation starts. In addition, many of the fundamental information structures within SharePoint are not easily changed once the implementation starts.
Information Architecture Phases
The information architecture activities for implementing SharePoint can be broken down into four phases:
- Analysis: Discovery of content and structures that already exist within the organisation
- Design: Creating the information architecture itself (see below)
- Configuration: Implementing the information architecture as determined by the design
- Testing: Validating the information architecture and reworking in light of user feedback
Key Aspects to Consider
The design of a SharePoint information architecture must consider a number of aspects of SharePoint functionality.
- Site Plan: Information to be stored and accessed within SharePoint must adhere to some overall structure. Whilst SharePoint does not implement a classical “fileplan”, one must be created never the less.
- Interface Structure (Usability): Once the site plan has been created this must be mapped to appropriate SharePoint interface structures.
- Content Types: Content Types are one of foundations on which much of SharePoint’s functionality builds. Therefore, getting the Content Types correct is of prime importance to any SharePoint development.
- Metadata: The metadata schemas to be used within SharePoint must be defined. This metadata is primarily related to the Content Types, but also in other key SharePoint structures.
- Taxonomies: Any controlled vocabularies required to populate metadata fields or define navigation structures must be defined.
- Search: Defining the parameters of the search and attendant user experience.
- Permissions Model: A SharePoint implementation must define the permission model that applies to it – namely who can do what to any given item of content.
- Workflow and Versioning: Any organizational document workflows that are needed must be defined.
- Policies and Governance: Whilst SharePoint allows significant codification of the information architecture and its usage, there will always be a need for policies and governance guidelines.
SharePoint lends itself well to having its configuration performed by information architects rather than software developers. The reasons for this are two‐fold: the detailed and comprehensive set of configuration options that are exposed via the administration user interface; and the pervasiveness of these options throughout the many SharePoint information structures.