SharePoint folders are NOT intrinsically bad

Posted by Marc Stephenson in Information Architecture, Information Governance, Metadata, SharePoint, Taxonomy

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…

  1. 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).
  2. 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.
  3. 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.
  4. 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).
  5. 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.
  6. 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.
  7. 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!?
  8. 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?
  9. 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?
  10. 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.
  11. 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.
  12. 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…?
  13. 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…
  14. 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.

  1. 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.
  2. 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.
  3. Permissions. Folders can be used to group user permissions. See above. Not ideal, but much better than file level permissions.
  4. 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.
  5. 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.
  6. 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:

  1. 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.
  2. One level of folder is acceptable, but you have to convince me. I’d say I’m convinced 50% of the time.
  3. 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.
  4. 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.

Can real world entities have metadata?

Posted by Marc Stephenson in Metadata

I seem to be getting increasingly unhappy at the use of the term ‘metadata’ to mean the attributes of real world entities, as opposed to information objects. Here’s a response to an exchange on the LinkedIn Metadata Management pages. Am I just getting too purist (i.e. old and grumpy)?

Traditionally metadata has been information about information objects (I can’t bear that phrase ‘data about data’ which is very unhelpful). When a painting is digitised, as you suggest, for me it then becomes an information object, and accordingly would get metadata. Until that point, any information stored about the actual painting in the real world is cataloguing or description or …

I remember a meeting of the UK e-Government Metadata Working Group which produced the UK government metadata standard, where one member of the group suggested that information about events or buildings or people would qualify as metadata. Another member of the group exclaimed in a horrified voice ‘So a swimming pool can have metadata!?’ In fact of course a swimming pool can have a name, a location, opening hours, etc but that is surely data, not metadata. The webpage that contains the information about the swimming pool may very well – and should – have metadata, but that’s because it’s an information object.

I think the reason this bothers me is that when developing a metadata standard, which I often do for clients, I need to focus on the attributes of information, not the attributes of anything that might be mentioned on a webpage (for example). Otherwise I have to start including attributes for events, people, products etc etc, and thus my metadata schema becomes huge and unmanageable.

The taxonomy, on the other hand, needs to provide values for metadata and data, but that’s another discussion….

Why SharePoint needs an information architecture

Posted by Marc Stephenson in Information Architecture, Metadata, SharePoint, Taxonomy

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:

  1. Analysis: Discovery of content and structures that already exist within the organisation
  2. Design: Creating the information architecture itself (see below)
  3. Configuration: Implementing the information architecture as determined by the design
  4. 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.

PDFIcon Download this article.