Comments on: Create SharePoint Document Taxonomies with MindManager – Part 1

By: Ruven

Ruven — Wed, 27 Apr 2011 04:25:16 +0000

Wow, 2.5 years later, this post is getting a bunch of new activity. I am working on an update (and the never-completed part-2 [oops, sorry]) for this post. For the most-part, I still use these tools in these ways, but I have developed some better ways of explaining the concepts.

Bil, when I work with clients, I don’t look at the old folder structures – I ask them to classify the types of documents that they work with. Once they bring that info back, we work on building out structures (including metadata) that will work best.

Pat: I’m still loving MindManager for this and many other tasks.

By: Pat Kennedy

Pat Kennedy — Tue, 26 Apr 2011 20:26:08 +0000

By the way I love MindManager for this type of requirements gathering. Building structure and laying it out so a client can see is easier and modifiable as things change and the requirements become tighter and tighter.

By: Pat Kennedy

Pat Kennedy — Tue, 26 Apr 2011 20:24:08 +0000

Bil, I agree with you, but at this point I think Ruven is just getting started gathering the requirements. Part of the requirements process is getting a confirmation and buy-in from the client. Of course the taxonomy is part of the structure that supports the document management and since as you point out that most of the management is done organically now without regard to duplication or version control mechanisms, this is just a place to start that the client inherently knows. Then will come the explanation of why the suggested taxonomy structure and eventually to support of the business processes.

By: Bil Simser

Bil Simser — Tue, 26 Apr 2011 13:41:59 +0000

One thing to avoid falling into is the trap of using a folder structure to reverse engineer requirements. Remember that any folder structure was created (probably) organically and was created within the restrictions of what you can’t do in folders (documents in multiple locations for example). It’s a starting point for a discussion but I wouldn’t use it as a blueprint to map into SharePoint. Doing that leads you down the path of replicating one technology for another. There needs to be some thought and discussion behind what makes sense to the business unit and the documents along with where they’re going. It’s far easier to fix metadata than folders so it’s great you get it into that form but be wary of using folders as your blueprint. It can be used as a roadmap or reference but think twice about using to build the foundation. That foundation should have some pseudo-science behind it and that requires some thought around what the user needs out of the taxonomy. What was valid in folder land 2 years ago might not be valid in metadata land today or going forward.

By: Izzat Sabbagh

Izzat Sabbagh — Fri, 19 Mar 2010 14:32:46 +0000

Hi Ruven,

I was reading your article and, believe me, you were just describing what is happening to us in our Institute. Using Sharepoint as an online Files Structure of folder is always the main problem. I was wondering if you were thinking about publishing the second part of this article as we sure will find it very useful.

Regards,

By: Barry

Barry — Tue, 04 Aug 2009 09:18:28 +0000

“Research has shown that about six metadata fields is about the maximum that you can ask people to fill-out on a regular basis.”

I’d be interested in reading this research. Have you got a reference for that please? Thanks!

By: Pez

Pez — Fri, 24 Apr 2009 18:15:21 +0000

Where is part 2? I’ve been waiting for weeks.

By: Joan

Joan — Fri, 20 Feb 2009 17:01:23 +0000

Ruven, Thank you — I so have the File Share 2.0 problem at the company I work for even though I have continuously preached no, no, no… use metadata instead. I am in process of structuring some 1-hour training sessions I volunteered to do (OMG what was I thinking) and the one on metadata gets a front-and-center link to this article.

By: Ruven Gotz

Ruven Gotz — Fri, 20 Feb 2009 14:16:04 +0000

Kanwal, Thanks for your comment. You are correct, I have simplified the issue a bit here, talking only about one document library. In next week’s post I’ll talk a little bit about the work of building the structure of the site based on the number of document types that the user lists in the “homework” spreadsheet.

The goal is to find a reasonable grouping of content types into multiple (but not too many) document libraries while keeping performance issues in mind.

Mark, your approach is correct, but there can be wrinkles which makes this one-to-one mapping difficult. I have seen situations where the client has forty folders and under some of those folders, there are dozens of sub-folders.

Along with keeping the number metadata fields from growing out of control, you have to worry about a metadata field that has a drop-down with forty items in it (this is probably unusable for the average user, resulting in irrelevant/useless metadata).

Thanks for the feedback: I’d love to see more comments from people with their experiences about what has worked (or not worked) for them.

-Ruven

By: EndUserSharePoint

EndUserSharePoint — Thu, 19 Feb 2009 18:57:32 +0000

Ruven,

Another approach I use in workshops is to identify replicated folder structures, such as those in your example. As we look at the folder structure, we name a column after each of the folders in the hierarchy; sales, year, region, industry. Many times, it is a direct one-to-one correlation.

By using the existing folder structure as a blueprint, we can then show immediate results for flattening out the hierarchy of large document sets by dynamic filtering using column headers and then setting up static views.

An additional benefit is that everyone is already familiar with the names being used for each column because that is what they have been using in their folder structure.

Nice article. I hope it gets people thinking.