Once in a while, I get asked what I call a "Flat Earth" question: "Prove to me the earth isn't flat." Then, I stumble to find good answers. We all know the earth is a sphere, but such unexpected questions can rob you of quick, persuasive replies. So it was in a recent taxonomy modeling session, when a line-of-business participant asked me: "Why do we need folders anyway? If I need to find anything, I just search based on attributes such as author, created date, and so on."
I replied with a litany of justifications. Navigating folders is a common way to find information. "Do you use folders in your iPod or Outlook email client, or do you just put everything in one place?" Electronic content management systems use folders to apply security to their contents. Systems do not deal well with single folders containing millions of files. Besides, if you are looking for one file out of thousands, you're very unlikely to find exactly what you want at the top of the search results list. Google's uncanny ability to return relevant search results didn't help my folder defense.
In fact, the more I justified the need for folder taxonomies, the less persuasive I became. The taxonomy-folder conundrum gained traction. Add to this the fact that records managers were on the team, and, although they seemed to support the need for a single taxonomy, in truth, they preferred their overriding taxonomy, not specific ones for lines of business. Records managers think of the folder system in terms of a file storage plan-familiar to them but often not to others, and this can generate tension between the rival business views in modeling sessions.
Although everyone can find shortcomings with any taxonomy, we all want to be able to find the files we are looking for. Given the left and right sides to our brain, one side-and, therefore, one approach-usually predominates. Findability usually comes down to two approaches, depending on our favored brain hemisphere. Some of us look where we think things should be, typically navigating a hierarchy of folders. Only if we fail do we then punt and run a full-text search.
Alternatively, some searchers do the reverse: search first and then navigate. The disadvantage of traditional folder hierarchies is that there is usually only one folder structure for all files. If you created the structure, you understand it. However, if it is a shared folder structure (and you didn't create it), others may find it confusing. I have begun to suspect that the best justification for taxonomies isn't to defend the traditional view but to suggest instead that, rather than a one-size-fits-all taxonomy, we should let individuals develop their own custom view of the content hierarchy. That is, the question shouldn't be, "Why do we need folders?" but rather, "Why can't everyone view folders their way?" How could a system achieve this flexible view? One possibility is by leveraging the rich file metadata already available in every content management system. This approach could reduce the need to achieve unanimity on taxonomy design. Moreover, business users often request more metadata than they probably need, and that practice could end up producing better, more-detailed virtual folders.
I posed the question of multiple repository views to several major ECM vendors, and I received some encouraging replies. First, Lou Jordano, EMC's marketing manager for content management and archiving, explained how Documentum resolves the problem of different folder views by lines of business and records managers. "Documentum usually presents two folder structures with informal records creation linking from the line of business to the record classification structure." While both structures are available, records managers use their record taxonomy, and others use the primary business taxonomy.
I was also impressed by the response from Troy Deck, principle of Wingspan Technologies, whose DocWay Virtual Folders product is available as a "web part" for SharePoint and which allows Documentum users to create virtual folder views. Based on content attributes, DocWay "enables users to define their own faceted navigation path" based on content attributes. DocWay lets both Documentum system administrators and individual users create their own views of the folder hierarchy. The product also allows focused search in these virtual folder branches. Security, usually inherited from folders containing that content, is not affected. Deck cautioned that there are constraints in searching virtual folders. "Wingspan recommends you always monitor your database and tune queries" that are taking too long. Still, providing repository users custom views of folder structures resolves a basic problem of one folder structure being a forced fit for everybody.