SharePoint Folders vs. Metadata
Guest Author: Eugene Rosenfeld
Things that Should be Easy
There are many posts out there extolling the virtues of using metadata over folders for organizing information in SharePoint 2007. I certainly believe that metadata is a great tool for for classifying information, but it is incorrect to ask whether to use folders or metadata to organize information. Rather, it is more appropriate to ask when to use folders and when to use metadata. This post is not intended to be an in-depth discussion of information architecture. Instead, I wanted to provide a few pointers on when to use folders and when to use metadata. The following is a brief comparison between folder and metadata capabilities in the SharePoint platform. The context of the comparison is only out-of-the-box (OOTB) capabilities. With enough custom code, folders and metadata could be made equivalent.
|
Folders
|
Metadata
|
|
|
Security
|
Folders can be used to propagate permissions and control the access to the resources the folders contain.
|
None.
|
|
Content Type Order
|
Folders can control which content types users can create using the New menu on the list toolbar. Folders can also control the order in which the content types appear in the menu.
|
None.
|
|
Navigation
|
Folders are intrinsically part of the navigational infrastructure in the SharePoint platform.
|
Metadata can be used to control navigation, but this requires creative approaches. List View web parts showing filtered list views can provide metadata-based navigational capabilities. While this requires no custom code, it can be labor intensive to add the web parts to a large number of pages. Additional metadata-based navigation can be accomplished through custom code.
|
|
Url
|
Folder names form portions of the Urls of the SharePoint resources the folders contain.
|
None.
|
|
Tools Support
|
Most Microsoft and 3rd party tools inherently know how to work with folders in the SharePoint platform.
|
Metadata support in 3rd party tools is spotty. While a tool from one vendor will generally understand how to handle its own metadata, the tool will generally not understand how to handle the metadata from another vendor’s tool. This can make it challenging to incorporate metadata from multiple vendors’ tools into a single SharePoint information architecture.
|
|
Search
|
None.
|
Metadata is indexed by SharePoint search and will return results based on keyword searches. MOSS 2007 also supports promoting selected metadata to searchable properties.
|
|
Sort
|
None.
|
Metadata can be used to control the order in which items are displayed in list views.
|
|
Filter
|
List views can be configured to show only the list items contained within a folder and its sub folders.
|
Metadata can be used to control the which items are displayed in list views.
|
|
Group
|
None.
|
Metadata can be used to group list items together in list views. List views limit grouping to two hierarchical levels.
|
As you can see, folders and metadata each have their own capabilities and affects on a SharePoint information architecture. A proper SharePoint information architecture will contain the judicious use of both folders and metadata.
You can find Eugene’s orignal post here
Guest Author: Eugene Rosenfeld
Things that Should be Easy
Eugene Rosenfeld is the CTO of Black Blade Associates. He started his IT career as a database programmer and soon moved into enterprise application integration (EAI) and portal systems. Eugene holds a strong belief that all systems should have the innate ability to intelligently communicate with one another. Most recently he has been heavily involved with distributed systems architecture, Services Oriented Architected (SOA), peer-to-peer systems, and cloud computing.
Eugene has been recognized for his community involvement by Microsoft through their prestigious MVP program. His MVP profile is available at https://mvp.support.microsoft.com/profile/Eugene.Rosenfeld.
Excellent post ! I agree both has got its own capabiltieis and a good information architecture should make use of both to achieve best of both. Very nice summary.. good work and keep it up !
Thanks Eugene. Very nice table format for quick reference. Pick the right tool for the job, I agree. I’ve used both many times for various needs and it truly is a case by case basis with tradeoffs.
I’m excited to learn more about SP2010’s ability to more easily tag multiple items with metadata. That will help with our end user adoption.
I wish more articles did that – ask when instead of whether. I agree with Jeff, this is a nice, easy to read reference.
One point I don’t agree with, though: I’d say that folders do grouping, and this is actually their main function. The difference with metadata is that folder grouping is exclusive – an item cannot be referenced under two different folders.
Nice write-up and comparison chart / thanks for sharing!
One additional tidbit; SharePoint views can traverse items in folders… so it allows for the best of both worlds, items stored in folders can be presented using the power and flexibility of filtered and/or grouped views by activating the “Show all items without folders” in the view design.
Cheers,
Robin
Is the folder name metadata that can be referenced in a Document Library View?
How would you reference a folder name (column) in a View a Library/List containing email message items, for example:
Email Subject, Folder Name, Email Sender
Group By Email Subject, Folder Name
Since this is a site that focuses on end-users, and not programmers, I have a few problems with this comparison table. I’ve spent several days trying to build a simple document repository, only to learn that what I need requires extensive programming.
Say you want to create a collaborative library of project documents that will be shared by multiple participants. Each document is associated to one project, so it would be identified by appropriate project info. Presumably you’ll create a master list of projects that includes data like customer name, project date, project description, and probably some kind of ID number. Then when you want to upload a project doc, you simply pick a line from the master project list, and associate it to the document, right? Wrong.
1. When a user wants to upload a document, they *cannot* select which project. They could select a customer, then separately select the description, but there’s no way to make sure they’re connected!
2. You could use a list instead of a library, uploading the project docs as attachments. But then you lose all of the important features: checkout/checkin. versioning, etc.
3. You can’t send someone a link to the file, e.g. “Bob, here’s the URL to the project plan.”
I have, however, been told by a dozen people that “all of what you want can be done in code.” That’s certainly true, but we don’t have programmers available, nor are we prepared to invest all the time needed to design, then maintain, a custom application.
Folder trees may be archaic and inelegant, but they’re the only approach that allows Sharepoint to be used as a reliable structure for storing and sharing documents that are associated with a specific business construct, such as department, project, etc.
I’m not convinced this isn’t do-able with site columns at the site collection level. Create a custom list at the top of the site collection, Lookup-ProjectNames, with all the fields you want for defining a project: Project Name, Project Manager, Project Manager Email Address, etc. Create a site column, “Project Name”, using the “Lookup” data type, and point to the Lookup-ProjectName list, sucking in the names of the projects as the values.
This site column can now be used anywhere throughout the site collection. On your project document library, add the site column “Project Name” and every document will have a project name associated with it. When the document library is displayed, clicking on any name in the Project Name column will drill down to the project name item, giving all the information stored about that project.
Another BIG advantage of doing it this way is that now you can use a Content Query Web Part to roll up all information about a project, since CQWP searches against site column values.
Hope that helps,
Mark
Hi Tom,
Just a couple comments on your message:
- the ability to collect connected metadata is, as you point out, a limitation of SP 2007, and has been added in SP 2010.
- metadata are essential for cross-referencing content, and this is especially useful in matrix organizations. It is true that you won’t see much benefit in pure hierarchical organizations. Also, I often see situations where a document is associated to multiple projects, and in this case folders just don’t work. So I completely disagree with your last statement.
- “it can be done in code” and “it needs to be done by a programmer” are two different things, and one of the roles of blogs like Mark’s and mine is to make code accessible to non-programmers (agree, easier said than done).
Tom, I understand your frustration. In fact, I’m going to add to it a bit. Project management is more than just documents, it’s also maintaining tasks, issues, risks, etc. You also have to be able to easily archive and restore data for one project without losing other project data. And as you noted, you want to make it easy for users to know the context of the project in which they are working. Even better, if you could also make the Microsoft Office client applications automatically filter the data (documents, links, and tasks) they display to just the items for the current project.
Now the good news. The easy way to handle this is to have each project be its own SharePoint site. But, you still need your project list in order to maintain the project-based metadata. To that end, I wrote a tool called List Item Workspaces that allows regular users to create SharePoint workspace sites based on any list item, similar to the way that document and meeting workspaces behave.
With the List Item Workspaces tool, you can create your central project list with the metadata you need to track. When you add a new project, the List Item Workspaces tool will automatically create a team site for the project and maintain the linkage between the list item and the team site. All project documents, tasks, links, contact info, and other items go into the project site. This way users always know which project they are in and do not have to constantly worry about setting filters on the documents, tasks, contact info and other list items that they work with in SharePoint. Best of all, the Office client applications will show users only the content related to the current project. You can even use Mark’s suggestion of using the CQWP for aggregating data across multiple projects.
We use the List Item Workspaces tool on our own portal for managing projects and much more. You can see the tool and download it free from:
http://www.blackbladeinc.com/en-us/products/liworkspaces
Hope this helps.
-Eugene
Does anybody know if it is possible/advisable to create a custom field type that returns a folder name as if it were meta-data? Any advice, ideas or suggestions on the best way to do this would be appreciated.