The public beta of SharePoint 2010 is out there for all of us to try who don’t have privileged access, and so now starts the time of deciphering the impact the next version of this very important software package will have on us. One of the things that excites me the most is improvements in the ability to architect information across your entire SharePoint farm with a metadata management service application (formerly SSP), and improvements in navigation by metadata. One thing I was not expecting to improve but has is the use of folders in SharePoint.
SharePoint 2007 brought us great improvements to how we think about storing and viewing information. With powerful options such as extensive metadata options, content types, and countless numbers of lists and libraries there were many options available to us. The folder paradigm to storing information was still present in SharePoint mostly to ease the transition from a file share to a web-based application, and it led to a debate amongst information architects on whether folders were a best practice for storing information in SharePoint.
There were people on different sides such as Paul Culmsee who see the issue differently than myself, but the good news is that SharePoint 2010 adds functionality to alleviate some of my concerns in using folders.
Setting Metadata with Folders
One of the things I was concerned about was that folders would remove the desire to create custom content types and metadata and instead use the folder paradigm that they were used to from the file share. In SharePoint 2010 we can specify metadata for a folder (which has always been a content type), and it will be propagated to the documents contained within the folders.
Views Without Folders
In SharePoint 2007 was an explicit option to not include folders within a view. This seems to me to be the best balance between those who prefer a folder view to those, like myself, who prefer views that are grouped. I always disliked folders (inside or outside of SharePoint), because I felt it an impediment to optimal findability (have you ever tried to navigate someone else’s document folder?). This strikes the balance between those who like folder views and those like myself who prefer grouped views.
Now navigation can be modified out-of-the-box in SharePoint to allow navigation by metadata and content types. Now I don’t have to mess with the terrible tree view, but now instead I can focus on utilizing metadata to optimize the navigation experience. This adds quite a bit of versatility in constructing the user experience for your end users.
The SharePoint team has improved the use of folders in SharePoint 2010, and they’ve also improved the experience to not use folders if you so choose such as large list throttling so folders don’t become a necessity. I hope you get a chance to play with the next version of this exciting platform.
I am curious to know if the folder metadata can be changed within a data view or datasheet when using 2010. I have spent some time this morning trying to get this to work using a folder content type but to no avail!
Were you able to find how to apply metadata to folders in 2010, which is possible to do it in 2007 using Datasheet view? Or is there a better way to do it?
I didn’t know you could do that in datasheet view in 2007. You can apply default metadata for a folder in 2010 so that each document/item added to that folder will get default metadata.
Hi Scott. I just tried to do so, but my virtual machine for some reason isn’t configured for the datasheet view. Another 2010 mystery.
I assume you mean changing the metadata that is associated with documents inside the folder and not actually adding metadata to the folder content type do you? It’s not a good idea to mess with adding to the default SharePoint content types.
The sole reason we found for using folders in SP2007 was for permissions. For example, we have a library which contains files from 4 divisions, and wanted someone from Division A to only see files from that Division. To accomplish this we set up 4 Division folders, with distinct permissions on each. Our default view displays the data without folders, to allow senior management to view data across divisions in one fell swoop. We were hoping that SP2010 would allow for setting permissions based on a Division metadata column rather that on a folder, but we are told this is not the case. Is there a better way of accomplishing this in SP2010?
Thanks Shelley for the comment. I have a question. Do these divisions have their own sites? From what I can tell with your detail, I would’ve been inclined to separate the content into divisional sites.
[…] manner away from folders, and others have tried to tow the line between the two. Even though SharePoint 2010 has made improvements in the way folders can be used, I do strongly believe that folders have outlived their translation. […]
Reading this post is a revelation, but it raises a question (long preamble, but straightforward question, i promise).
I work for a local authority that operates a multiude of differentiated services, and is halfway through rolling out a sharepoint based EDRMS.
This process began about two years ago as a Corporate IT strategy, and has been led by a particular IT heavy department, with other departments now beginning to capitalise on that investment by rolling out Sharepoint section by section. The end intention is that this software, and surrounding policy, forms the basis of a legally admissable standard on data reproduction, thus allowing us to ditch paper records and paper working.
Here I am, joining at the half-way point in one of those ‘other’ departments trying to select sections with a workflow compatible to the tools created for our original IT heavy department, in order that there be exemplars pour-encourager-les-autres.
So, we have a self-developed client software that acts as a cross between a document viewer, and an administrative tool that allows incoming documents and records to be assigned to the appropriate person, whereupon it will be populated with the appropriate metadata necessary to prevent it disappearing into a morass of unstructured data.
Great, except this client software is designed for a workflow that see’s a large volume of simple form based applications, simple requirments, and quickly dealt with, at which point it becomes an archived record. By way of contrast, we have a smaller volume on ongoing investigations that require living documents, supporting data in the form multiple images, emails, etc, that may be ‘active’ for six months or more.
Much of this is manageable, our client software is already populated with enforced (and optional) meta-data tags before it can be declared as ‘processed’, paper gets scanned directly into sharepoint, and emails can be forwarded to sharepoint, however;
The client software in this workflow is extremely daunting to non-IT staff, not least because [their] library view can quickly become unmanageable due to the sheer number of images, emails, and documents that sit in their inbox for the duration of the case. Images are currently added to sharepoint by email.
To alleviate this problem I want to select “Save all attachments in folders grouped by e-mail subject” in Sharepoint. The result is that the email shows up in the client software as a sharepoint webpage showing both the email (which may provide important context to attachments) as well as the attachments themselves. One nice and neat entry in the client software which – outside task-specific applications that draw upon sharepoint resources – provides context to what would otherwise be a ‘soup’.
Now when I suggest this let me reassure you of the following:
1. I accept the ‘philosophical’ justification for enforcing meta-data tags over folders; we want to encourage users to adopt the sophisticated tagging system already in place, and not try to replicate the byzantine folder structures to be found across our existing network drives that they believe make so much sense.
2. I accept the technical justification that it is difficult to apply metadata to objects within folders, and created complex nested heirarchies is likely to cause the advantage of sharepoint to be lost altogether.
1. This is not a user-created action, merely the result of an email aggregation fucntion within sharepoint itself, nor too is it user-controlled, just automated action creating a flat one-layer-deep folder structure for some items, so I don’t see it harming good-practice by users.
2. In SharePoint 2010 we can specify metadata for a folder (which has always been a content type), and it will be propagated to the documents contained within the folders, so perhaps the associated objection is linked to our limited Sharepoint experience beginning with 2007 (now 2010).
To a large extent we are constrained by the need to; follow the Corporate IT strategy (which we think is great), and to resuse client-software created for the workflow of another department (which I believe we can work around).
So my question is this; given the workflow issues and policy constraints listed above, does my identified solution:
a) Seem appropriate?
b) Breach either of the two justifications given above for not using folders in Sharepoint?
Any assistance is appreciated.
So I don’t feel like I understand quite everything, but your situation might be a good one for document sets. At the very least a client like Colligo could help your users with the workflow.
Maybe if I felt I understood more I would be more confident in my reply.