CM007 | Content Management - BUT MUH FOLDIZZZ!!!

“Folder is an F word and we don’t talk like that here”

These timeless words spoken by one of my favourite SharePoint professionals of all time have travelled with me through every project I have tackled since. For some, this would be a controversial statement, but from where I sit it’s not only best practice, it’s good old fashioned common sense.

Why do folders make my blood run cold, you ask? Good grief, child, where shall we start?

One-Dimensional View

Here’s a screen shot of a set of folders in a SharePoint library:

We all know there are more folders and sub-folders and sub-sub-folders beneath this, but unless we actually go through the pain of clicking through who-knows-how-many levels of folders, we will never know what we have and what we don’t. Pretty much the polar opposite of user friendly.

But if we drop the folders and take the metadata route instead, we can view the library content in any number of ways. For instance, I might choose to view my library contents by document type:

Or by department:

Or both:

All on the same library. In fact, I can build literally dozens of different views on the same library, each viewing the same data from a different perspective.

Also: NO EMPTY FOLDERS. If a particular metadata grouping value doesn’t have any documents assigned to it, it doesn’t show in the breakdown.

Much cleaner.

Sorting and Filtering

You know what else you can’t do with folders?

You can’t filter or sort or group with folders.

In a metadata-based library, any metadata field in your view can be used to filter or sort or group by:

Change and Adaptability

Folder structures are by definition rigid, inflexible, and resistant to change. In a business environment where the only constant is change, this simply doesn’t fly. No-one has the luxury of hours, days, or weeks to dedicate to re-organizing content into new folder structures. And don’t even get me started on all the broken links on shared documents.

Metadata-based libraries allow you to create or update views in a matter of minutes – and none of your shared links break when you create a new view.

Broad-based Information Retrieval

This one’s pretty nasty.

Imagine Joe Soap is injured on duty and his family decides to sue the company for unsafe labour practice. How does the legal team manage discovery?

In a folder-based system, the legal team would need to approach each responsible document control team at each site separately (e.g. at the branch and at head office), and request all:

• Safety training records;
• Workplace inspection and audit records;
• Injury on duty records;
• Safety-related disciplinary records;
• Workmen’s compensation records; and
• Records of previous court proceedings, if any

that may be related, however tentatively, to Joe Soap’s injury incident. And since there’s no method to double-check the team’s work, the legal team has to trust that the document controllers have given them ALL the relevant records. I remember one particular client that had depended on this method in years gone by and it ended up costing them months in litigation and millions in claims, just because they couldn’t find the documentation that would have proven their case.

A properly architected metadata-driven environment would have allowed the legal team to find precisely what they needed within hours, if not minutes, using this wonderful thing called Search and Search Refiners. More on this in a later instalment.

Information Integrity and Content Duplication

In one of the earlier instalments in this series, I discussed how allowing users to create whatever folders they choose increases data integrity shenanigans. Well, this past month I did a content analysis on a network shared drive for a client where I found, I kid you not, ELEVEN different spellings of the word “appointment” in a single departmental folder structure.

It gets better.

Individual team members had backed up their entire C drives onto the departmental network share – as in, not just the documents. The ENTIRE C drive, including Windows setup files, application install files – even their personal picture libraries. 

Whole departmental structures were duplicated or recreated from scratch in multiple places, because users couldn’t find the original folder (or couldn’t be bothered to look).

Short version: of the 1.1 million files listed in the initial data set, only about 100,00 were actual documents. I easily lost 5 years off my life wading through all that.

While I’m a tad militant about all that wasted storage, the bigger issue was that with all those duplicated structures, no-one could tell which version of a particular file was the original.

File Links and URLs

Files saved to a network shared drive are accessed by a file path. Files stored on SharePoint are accessed by a URL. Pretty much the same thing, except that URLs use encoding characters. What does this have to do with folders in my library, you ask?

Let’s imagine you have a library called “Contracts” on a site called “Legal”. That library’s URL would look like this:

https://organizationx.sharepoint.com/sites/legal/contracts

Happy so far? Good.

Then you set up a folder structure in your library:

• Folder 1
• Folder 1a
• Folder 2
• Folder 3
• Folder 3a

And you save a document to the “1a” folder.

So now the document URL looks like this:

https://organizationx.sharepoint.com/sites/legal/contracts/Folder%201/Folder%201a/document.docx (95 characters)

There are 2 problems with this approach:

• Every folder level you add to the structure makes the URL longer; and
• If you ever need to move the file to a different folder, all shared links to that file will break.

Metadata-based libraries have completely flattened structures, so once uploaded, the document URL never changes and shared links will never break.

Truncated file paths

A document URL will always consist of:

• The tenant URL (e.g. https://organizationx.sharepoint.com);
• The site path (e.g. /sites/sitename);
• The library path (e.g. /Shared Documents);
• The nested folder path inside the library (e.g. /Deceased Estate Management/Deceased Estates/Joe Soap/Trust Documents); and finally
• The document name (e.g. /Beneficiary Nomination Form -Jenny Soap.docx)

So for this document example, the complete file path would be: https://organizationx.sharepoint.com/sites/sitename/Shared Documents/ Deceased Estate Management/Deceased Estates/Joe Soap/Trust Documents/ Beneficiary Nomination Form -Jenny Soap.docx (184 characters)

The browser then URL-encodes this path to https://organizationx.sharepoint.com/sites/sitename/Shared%20Documents/%20Deceased%20Estate%20Management/Deceased%20Estates/Joe%20Soap/Trust%20Documents/%20Beneficiary%20Nomination%20Form%20-Jenny%20Soap.docx (208 characters).

Even at only 4 folder levels deep, the URL for this example document is 208 characters long, and document URLs will increase in length for every folder further nested into the structure.

While most browsers are able to manage longer URLs without incident, the second you try to open a file with a too-long URL in something like Excel, you open yourself to a world of fun and games. A perfect example of this would be an Excel file that references data from other Excel files: the main Excel file would open without issue, but the URLs for the referenced Excel files will truncate, break, and refuse to refresh. Not predictably, of course. Intermittently. Just to keep you on your toes.

Security Administration

SharePoint allows administrators to apply permissions on multiple levels of granularity, for example:

• Global access: everybody can see the organization’s landing page
• Site level: everyone in Legal can see the Legal landing page
• App level: only managers in the Legal department can see the Management library on the Legal site
• Folder level: this list of users can access this folder
• Item level: only Joe Soap can access Joe Soap’s personnel data

Users often make the mistake of thinking that storing content in folder structures affords them greater control over security, but the reality is that folder-based security management is an administrative nightmare. Its inherent complexity also poses a significant risk for security violations with real material consequences.

A well-thought-out site structure based on a solid metadata design negates the need for highly granular security levels, e.g. on folder and item level, simplifies overall security administration, and mitigates the associated risks.

User Experience

A common principle in User Experience design is to not subject the user to more hierarchical levels, clicks, swipes, etc than is absolutely necessary. Folder structures violate this principle by default, requiring users to trawl through an indeterminate number of levels to reach the content they need and then still potentially ending in an empty folder.

Deep folder structures also have a massive impact on screen load time. I once did an exercise with a client where we compared the load time on a folder-based library to the load time on a metadata-based library containing the exact same documents. The metadata-based library loaded in fractions of a second. The folder-based library loaded in 12 seconds. Let’s not frustrate users any more than is absolutely necessary.

Cost

SharePoint is a powerful business platform, hosting an army of tools and services to allow an enterprise improved productivity at lower expenditure, but if users insist on downgrading all the available functionality on SharePoint into a very expensive shared drive, the company will be left with exactly that: a very expensive shared drive. Robbed of all the intrinsic benefits the platform provides, one has to wonder why the organization made the investment in the first place.

Conclusion

I think we’ve all been around long enough to realize that a true Law of the Medes and Persians is a rare thing indeed. I’d go as far as to say that I’ve never met a rule that didn’t warrant breaking on the odd occasion. But I would have to add that content management rules and best practices were created by people who have shed buckets of blood, sweat, and tears learning these lessons the hard way so that we don’t have to. So before you start ignoring this particular piece of guidance, take a moment to consider how many buckets of blood, sweat, and tears you’re willing to donate to the cause.

In our next instalment, we will start on the real meat and potatoes: using all the information and Lego pieces we’ve collected in the first 6 instalments to start creating an enterprise-level Content Framework. Until then, take care, and remember to floss.