Why Folders are the new "F" word

Current Rating:
(0 ratings)

Why are folders the new F word?  It’s not because I promote disorganization.  Quite the opposite.  Folders only give you the perception of organization.  Real organization happens with meta-data.  In the below video blog I talk about why folders are bad.  The key points are that folders are:

-        Very limiting

-        Poorly maintained

-        Setup on the fly

If you truly want to organize your content, meta-data allows you to slice and dice information in any way you need at any given time.  I reference specifically some implementations in SharePoint such as views, managed-meta data, and content types.  But the principles are true throughout the ECM world.

There are times when there does need to me additional high level containers be it a root folder, site collection, site, library, cabinet, database, whatever you want to call it.  But it’s not for the purpose of organization.  Creating additional new root containers should happen based on:

-        Size limiting factors

-        Security requirements

-        Back and Recovery SLA

-        Performance

Search will never be the 100% answer to finding content.  Organization of content is key in case search is not used, and to even improve search results and experience.  While folders may give you the perception you are organizing content, it’s really just a bad habit.

For the "R" rated (AKA no Beeps ) go here : http://www.youtube.com/watch?v=NKvY1um4cHk

Report

Rate Post

You need to log in to rate blog posts. Click here to login.

Add a Comment

You need to log in to post messages. Click here to login.

Comments

Kevin Neal

The 'No Folder' Zone

Old habits die hard.

Way, far too often I hear the phase "I'll just scan to a folder and import". Arrgghh!

This is fine with me as long as the reasoning is clear and understood. Is it simply to cut costs? Is it that capture technology is not understood? Is it pure laziness?

While scanning to a folder is certainly one option of 'capture', more often than not organizations suffer downstream inefficiencies and added labor costs by not carefully considering their 'capture strategy'. Chris, as you said, meta-data is king! It’s the key point. An image is an image. Good quality scanning hardware certainly enhance software’s ability to accurately extract meta-data from images but, in the end, the information contained on documents is typically more important than the picture itself.

Your scanning application software, whether it’s a desktop application, network scanner touch screen interface or even a mobile device should be, in my opinion, the users ‘window’ to see directly into the repository. In other words, once an image is created and meta-data extracted it should be put-away immediately into the system. For example, the users would pick a library or container to store the documents. Depending on the level of confidence and importance of accuracy based on an organizations business rules they might want to perform verification and validation. Point-is, put these documents away as soon as possible.

‘Folders’ are littered with potential pitfalls including just a few of the following considerations:

• Poor image quality
• Complex metadata field mapping
• Unknown document types
• Lack of image correction
• No validation
• Additional labor required

The bottom line is that although folders may be appropriate in some cases, cutting-corners by not carefully considering a taxonomy and meta-data for your documents might accomplish nothing more than taking a disorganized paper-based process and make it an useless, ineffective and costly electronic mess.
Report
Was this helpful? Yes No
Reply

Daniel O'Leary

Folder = Familiar

"My Documents" was the butterfly effect that started a huge majority of folder and information organization problems that we see now.

People are used to having folksonomies that they use aka My Documents, and they try to bridge that logic and experience into systems like SharePoint. The real failure is a lack of top down organization and training to help empower users to understand the basics of information organization. Given a proper setup and 30 min of training, most users could use folders the right way, as opposed to the bastardization that is so common.
Report
Was this helpful? Yes No
Reply
Chris Walker

F*****s Done Right

If configured correctly, folders can actually be quite helpful for checking content in. Of course, the front end work required to automatically categorize the content and apply the correct metadata is significant.

I've found that a folder construct helps for filing content, nit so much for finding content. The screen shots in my latest post (http://www.aiim.org/community/blogs/expert/Adoption-Issues-Make-it-Easy) are indicative of how I actually implement out solutions. Users dig it because they can simply drag their stuff into a folder, manually add a minimum amount of metadata and be done (retention rules are also embedded into the folders). Note that user profiles, content profiles, and security are also leveraged to limit the folder choices to which a user has access.
Report
Was this helpful? Yes No
Reply
Chris Riley, ECMp, IOAp

Same Construct

Chris,

Good points, but I really think folders are a crutch. In most ECM systems recreating the dial in to content concept is easy to do without folders, and simply creating a hierarchical file taxonomy.
Report
Was this helpful? Yes No
Reply
Patrick Lujan

Folders are taxonomy too as you yourself stated in your video

And they may or may not be linear. Depends upon how a given user wants and chooses to interact with their content. You also invoked the word "taxonomy." I'm also a proponent of taxonomy, but how many users do you know that know what that means or care and, more importantly, understand its value and buy in to the concept? Further, though we can all do a taxonomy behind the scenes and, hopefully (for the most part), do it to some degree of automation for them, that's an ideal, but not reality. It's the UI on the front end for them and the database implementation on the back end for us that decides whether or not people can find what they're looking for and different people look for things different ways, even differently at different points in time. Also, let's distinguish between physical and virtual foldering. The former is a database construct depending upon the underlying platform's schema, the latter a construct of the presentation layer and/or the taxonomy, however formally or informally it's implemented. A piece of content may be cross-filed in many different folders depending upon users' usage and security requirements both, that's just a tail-head relationship in the underlying tables' relationships, but it has consequences for, again, security and performance as you've also stated.

Depending upon functional application requirements for targeted and navigational search, security requirements (the "Share a Document" use case is critical) and technical constraints associated with performance, folders may or may not be applicable and the onus on is on us as implementers to define their usage within the overall context of the app. As always, it's about execution, but users just want to find their stuff - whether it be a search interface, full-text indexing, a folder paradigm, or some combination of all of the above.

In all of my implementations there have and most likely will continue to be a folder element, to what degree depends upon what the needs are for that particular solution.

BTW, all that metadata associated with a taxonomy, how is that captured? When? How? By who? We all know how much users love inputting metadata and know capture process w/recognition technologies in a large implementation is never going to do it all.

BTW, was there a bug on the ceiling that day? ;)

Regards, Pat
Report
Was this helpful? Yes No
Reply
Chris Riley, ECMp, IOAp

Always bugs on my ceiling

Users are king, and finding a way to let them be king, but educating them at the same time is a challenge. I feel this is the job of consultants, and the industry. While Taxonomy and Folders behave very similar, technically they are different. In a file system a folder is the first portion of the file name. To the OS it’s just part of the file name. Taxonomy is not part of the file name. It’s part of the “properties” of the file. I use the term lightly, but properties are meta-data and they propagate themselves in many forms. In windows their apart of the properties stream, and in SharePoint they are Content Types. Because they are not part of the file name, it means they can be changed without distributing the file, and it also means they can be used in conjunction with each other. And when I say disrupting the file, it could be as minimal as moving from one folder to another which is just a name change. Or could be as serious as a name change literally creating a copy in a new spot, and deleting the original. This is still found in poorly designed ECM and old systems. This challenges the concept of record, and introduces issues of corruption.

What you reference above is specifically a hierarchical file taxonomy. But file taxonomies are only one type. There are regional taxonomies, organizational taxonomies, transient taxonomies, etc. A single file might have a term from all of these, but usually not more than one from a single taxonomy.

So while file taxonomies tend to relate very nicely to folders, the other taxonomies do not. Bottom line is, they are not folders, technically nor architecturally. It’s an easy trick to convince end-users that taxonomies are folders instead of teaching them what Taxonomy is, but this is just supporting the ignorance of a market.
You have inspired the next post “Designing Taxonomies”!

Thank you for your comments.
Report
Was this helpful? Yes No
Reply

Marc Solomon

Nested too deep

Nice post, Chris. There's going to be a cognitive disconnect so long as users think of ECM as an extension of their C drives. Document sets are the gateway drug to user adoption. Also advancing a broad catalog of term sets through Managed Metadata Services breeds a healthy respect for metadata (in a way that Views and Content Types never could).
Report
Was this helpful? Yes No
Reply
Chris Riley, ECMp, IOAp

Love it

"Document Sets" as a gateway drug. Love it. For whatever reason explaining a document set is not as easy as it should be. Initial they get it, until you start saying things like meta-data, compound document etc. Red flag.
Report
Was this helpful? Yes No
Reply

David Houlston, ECMp

Users are creatures of habit

While user initiated folders are truly a disaster waiting to happen, folders that are created from metadata without the user having any opinion on the folder heirarchy is a win/win. When metadata drives folders, the controls are in place to ensure a safe haven for documents.
Not every business application can work with foldering but in the main, folders work. Users are repetative animals - once they see that a folder hierarchy works, they will use it when the situation requires.
A folder heirarchy should be the last step in filing a document. Using 'scan to folder' or user folder creation is a path to certain document oblivion.
Report
Was this helpful? Yes No
Reply
Chris Riley, ECMp, IOAp

Pesky creatures, those users

absolutely. That is why we need to work on giving users something else that works. This is why I promote demoing value before talking about what it is. Change will happen eventually, either forced or welcomed. I strive to get adoption in a friendly way.
Report
Was this helpful? Yes No
Reply

Todd Roat

Exisiting Demos?

You mention the importance of Demo's to help end users understand the benfits of meta data verses Fold#%$s. Are they any exisiting demos out there so the wheel doesnt have to be reinvented. Existing demos would actually help me as well wrap my head around this....
Report
Was this helpful? Yes No
Reply

This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International