When someone first shows me how they’re using SharePoint I look for a sure sign whether they understand and have implemented the SharePoint paradigm to document management—I look for a folder. Granted using an occasional folder here and there is not the end of the world and doesn’t prove someone doesn’t know how to use SharePoint effectively. But if folders are used in a similar fashion to one’s hard drive it is indicative in a lack of understanding.
This isn’t entirely the fault of the end users mind you. Often they are simply thrown SharePoint without a thorough understanding of how to leverage it effectively. The end user simply starts uploading and managing documents they way they’ve known on the file share and/or their local hard drives. The solution to the problem is found in proper and complete training.
Let’s take a look at the major reasons to avoid folders in document libraries.
Improved Findability
If you’ve ever tried to traverse someone else’s folder structure looking for a document you know what a terrible experience it is. We often end up frustrated and still without what we set out to find. Often folder titles take on something meaningful to the original user, but even when using a standard template to folders it still becomes difficult to find documents.
Using a single Documents library that comes out of a new SharePoint site does little to explain the information contained therein. Users then look at this single document folder as the root to an endless array of folders. The better approach would be to separate out your documents into multiple document libraries with titles more indicative of their contents. It also provides a better solution for your quick launch navigation in finding the information.
Content Type Effectiveness
Content Types are the backbone of categorizing and rolling up data in SharePoint. Content Types are limited to applying only to an entire document library so if you wanted to limit a content type to appear or not appear on a folder level isn’t easy nor is in intended to do so. Content Types are made for the document library and should be a representation of the data within the library. Remember that a folder is also a SharePoint content type, and putting documents within folders limits their ability to be surface through methods such as the Content Query Web Part (as you wouldn’t query all documents inside of the folder Content Type).
The Reasons for Views
Views in SharePoint provide the alternative to viewing data within a library without the use of folders. They are based largely on metadata set on the documents from (usually) the Content Types. When adding folders it renders views in SharePoint ineffective. Views provide powerful ways to view data and switch them quickly and easily. I wish more and more I had views and metadata instead of folders in my local computer.
Security
Another big reason to not use folders is the way SharePoint handles security. You’ll notice that security is done on the list level. You can set permissions on a folder which seems like a good solution, but it’s only temporary. As your sites grow it turns into an administrative nightmare to manage all your disparate security settings. The best way is to use the groups for security on the list which inherit on up the site collection, and when you need to aberate you can do so in a cleaner fashion.
Conclusion
This is a small sampling of why folders aren’t the best method in SharePoint document libraries. While not exhaustive it provides a basis for using the powerful paradigm presented in SharePoint to collaborate and share documents inside of SharePoint.
Great outline of the metadata for files.
We are at a transition within our company to take our existing files off our our local domain drives(Drives and folder heirarchy which does not make any sense to anyone). We have been given SharePoint repository’s for specific product subteams.
When over-hearing the “plan” the director was going to copy the folders over to sharepoint.…JOY!
I totally understand the point behind the basics of sharepoint and file properties to manage content retrieval. What I am trying to understand is how to preapre our product development teams for putting data into the library and having them leave the appropriate trail of attachment to the related documents without having to make too much of a chore of it.
Example…We receive a product complaint(web-portal workflow manager for compliance with our business policy). We then take the information and get photo’s, descriptions from related sales and product engineers etc…and then the folders begin to be created. One for photo’s one for an anlysis of a product freeze effect on current inventory and mitigation to get the production up and running again, RAIL document, etc.…
We would have a project property such as ComplaintNumber assigned to the document…Good start. Potentially the phase of the investigation (DMAIIC possibly), but the discipline needed rom people is just nonexistent.
One tool we use that is very helpful is a requirement management system that is also for compliance to business process. We understand that because we have tracelinks and connections from one document object to another. Is this kind of linking etc supported in some way by sharepoint?
Another example could be a component I need to make will require three quotes from three suppliers and they must be archived for retrieval as well as data around price and delivery needs to be extracted and entered in for calculation into lead time and product cost. Again, attaching it to the process of “Go out and get three quotes for component (1…N)” Is there some way to effectively attach (and store) related documents to say a CAD file?
I have been trying to get this going within our IT department, but they are a little too understaffed to get it going. They give me blank stares and “why would you do that” kind of looks.
Sorry for the rant…Any suggestions to a mechanical engineer who knows just enough about applciations to really muck it up quickly?
Regards,
Dave
@Dave,
I’ve a feeling you’re still thinking in folders.. hope I can help you a bit.
“but the discipline needed from people is just nonexistent.”
First thing that comes to mind is: How is this discipline managed today?
In SharePoint you have the possibility to make columns required. That way you can “force” product development team to fill in the required information. If it is not filled in the document can’t be added to the library/list.
On with these columns ’cause that is what it’s all about with SharePoint… As you state you can add a property such as ComplaintNumber to a document. So why not add some more properties like document category (photo, analysis, complaint, email, etc).
The linking from the req. management system you are revering to can achieved with grouping in a library/list, two levels deep. You can group for instance on Complaint Number and will find all documents grouped, that belong to one number.
Requiring quotes from suppliers can be done via (Nintex) workflow, send out emails and store their replies , related documents AND the CAD file in on library or list, grouped by their common divider.
The lesson here is, don’t use the CAD file as a starting point, use it’s meta data to structure your content.
In this case I think you will need the library and not a custom list since attachments in lists won’t be searchable.
HTH,
Mike
1) More items may be stored in lists when folders are used.
2) They are more intuitive to use for simple business users.
3) They can be manipulated VIA Explorer view not some less than spectacular Microsoft web interface.
4) They may be controlled using Event Receivers.
This so called “discipline” is brought about by crappy application design: EX// SharePoint … Folders could work perfectly if Microsoft made them work … infact, I’ve built a massive folder based list with meta data stored in a different list … My lookups are much faster because I only traverse files in one folder and have not a need to search them (image data) .. plus I can save as many images as I want in one list without any hastle.
Grouping makes the UI slow and ruins the user experience because column data is now hierarchical.
@Matt: Thanks for stopping by! I don’t know where you base that you can store more data with folders since the same best practice limits still exist. Custom views give high amounts of control over how many items are returned in a view before going to pagination.
While it might be more “intuitive” in the short term doesn’t mean it’s a “better” paradigm. Case in point, my wife continues to tell me how much she hates the Ribbon in Office 2K7, but when she sees the advantage to the workflow she will be glad for it just like I am. Going back to 2003 seems dated.
The explorer view is an abomination, and I hope it gets removed from 2010 (although I know it won’t). It continues to push a “file share” mentality into SharePoint and not a enterprise class document management and knowledge management tool. Plus it allows you to circumvent setting custom metadata/content types by circumventing the UI.
While not a SharePoint developer I can’t speak to the event receiver comment.
About grouping: yes it has it’s drawbacks, and I hope dearly it is improved in 2010. However, getting to know the paradigm will be instrumental in moving forward especially if your organization has chosen SharePoint as their document management platform.
Stumbled across your site while researching a problem I am having with … guess what? Folders and views.
One point, just to follow on @Matt’s post bullet #1, is that we were told by Microsoft that one way to address the impact of a large number of list items was to organize them into folders, which we are in the process of doing now.
I would assume that was the reason for Matt’s first point, but I would certainly be interested in your comments on this tactic. Thanks!
@Jim: So MS told you to add folders eh? Interesting. Did you adjust the pagination on the library, or creating views with filters?
I have also found your blog while trying to develop a simple document storage solution. A tree of folders seems to be the only valid approach.
We want users to be able to checkin and checkout multiple documents associated with a single project. We’ve created a project list with appropriate columns: customer, description, date, etc. When a user creates a new document, we want them to select the appropriate project and upload it.
But because SP lists are not relational, there’s no way to link the fields! A user could upload a document, selecting one customer, then selecting a description for *another* project. I’d end up with a row in the library, with the appropriate document, but mismatched data in the customer and description columns.
I know there are ways to code around this, but a custom application is not an option.
@Tom: Thanks for stopping by! In 2007 the only way to enforce any kind of relation between list/libraries without code is using a lookup list, but that only works on single line of text fields which kind of sucks. In 2010 this has been greatly improved, but you’re right about your current situation. The only thing you can do is apply the same column to multiple lists/libraries through a content type.
I found an interesting way around this which allows a little more content for lookup purposes.
I use it for a part number and description field combination all of the time. I have a list that has the part number and description and a lot of the specifics for a part. I create a formula(calculation field) using the typical excel alpha combination scheme using “&” symbol. To create a “PartNum_Name” field. I then use this combined field as a lookup within the other lists or doc.library you may want to reference.
This is especially helpful for issues, taasks, etc, so people know where the problem is attached.
IS this what you were trying to address?
–Dave
I found this useful, since some people know something by name, some know it by number, etc.
Its the composite fielddifferent lists.
Regarding Folders.…I found an interesting way to break people of this habit by inserting the external lookup field lists, as well as showing how the documents could look via the document library views that disable the folders, but group or filter the web part vies.
Let them make it in folders, but you also have to force them to assign the meta data to the document by requiring a field for example.
You can get what you want, you have to meet them half way. What really helps is when you show them how useful the field properties are.
Also to avoid confusion, have the property fields you wish to track as a separate lists that is hidden or leave it exposed if it is something usful.
–Dave
@Dave: You can also create a view that removes folders from it as I mention in this post.
Folders will never ever go away. The sooner we all except this and stop the folder vs meta-data debate, the better.
In my opinion we as an IT professional community has failed to not recognise the potential merger of both. It is not a one or the other debate. Current attempts at making them co-exsist range from desperate to hopefull.
We seem to think users do not understand meta-data and then go on about their dicipline (or lack of).
I have also done this untill I realised that users love meta-data, they just have difficulty agreeing on it. The legacy of folders…
…User created folders imply meta-data. The user does not realise it, but he/she is is creating implicit meta data for the documents. The typical file-based collaboration problem then becomes to create alignment on the folder structure. Point is… users have been fighting over meta-data for as long as file servers have been available to them. Pre-dating formal document management etc. They just called it something else.
Tools such as Sharepoint has largely failed to understand the huge resistance to change they will have to overcome when introdicung meta-data driven systems.
Here is my attempt at a solution:
If e.g. Sharepoint could present its meta-data as folders the problem will go away. Lets introduce a conceptuall view called: Folder View (as opposed to Grid View, Normal View, etc.)
The setup for this view would be essentially ordering the metadata in a specific order rendering a view which can be presented as folders. Done deal, everone is happy. Ofcourse they would not be able to create ad-hoc folders anymore, but they will not care if all the meta-data is there. Adding meta-data is easy and the problem is well solved in Sharepoint.
The following advantages now become evident:
1) Meta Data (real) is seemlessly used to facilitate traditional click through searching. Your user is completely unaware of the difference.
2) When a user creates a file in a specific folder, all the meta-data for the new document is implied by the parent structure of the folder. This meta-data could automatically be attached to the document, thereby removing the need to populate it. Only the difference will be presented for capture. This is a good thing because meta-data can become very laborius to capture.
3) Obviously, multiple folder views can be created, thereby bringing home the advantage of meta-data to the user. Yah!
The current sharepoint (up to 2007, since I do not know the 2010 spec) comes kinda close with the option of a Group by view. But no cigar and here is why (in order of severity):
1) For reasons beyond my understanding you may only have two levels. Epic Fail.
2) It does not look like folders so users feel uncomfortable. Fail.
3) If you add a documents the advantage as per 2 above is obviously not present. Minor Fail.
All my searches on this topic leads me to threads similar to the one, which is essentially a folder vs meta-data only standoff.
The reality is that the folder paradaigm can never be removed. It is well and truly entrenched. It can however be hijacked by meta-data (as described above).
I would be interested to here this groups thoughts on this?
regards,
CHM
@Carl: I wouldn’t say “never” to folders going away. To many pundits have said “never” in the technology space and been proved wrong. It’s just a cultural thing that takes time to unravel.
SharePoint 2010 allows metadata inheritance through folders as you mentioned in a dream state. SharePoint views also allow you to remove folders from the view to retain a metadata driven view. Metadata navigation in 2010 also improves upon this.
The “group by” option was never meant to be a folder replacement just another option in a view. It doesn’t meet your criteria for folders, because it was never meant to do so. Also, the problem with (main) problems of folders are inconsistent labels and deep hierarchies. I’m glad the group by view doesn’t go more than 2 levels.
I’m confused on your statement about security. What do you do if you have content within a list that requires varying security levels? Do you implement item level security? That would force you to set the security on every document every time one is uploaded.
We use folders so that through inheritance, users can upload as many documents as they want to a folder with a given security scheme without having to modify the security on every document they upload.
You could write a receiver to set permissions on things as they are uploaded, but have fun with that as users invent new lists with new permission schemes that force you to constantly update the code.
Performance wise folders are better as well. Imagine a library with 10,000 documents contained in 1,000 folders. Whats better for performance, 1000 folder permission sets or 10,000 item level permission sets?
I have implemented a lot of document library lists at my company and while I agree with your basic premise that excluding the folders makes the list cleaner and easier to work with, my experience is that this is only true for small focused lists with a limited audience. As soon as you start adding lots of different types of documents and start including a larger audience, then you have to use folders.
@Nate: I would say once you start needing different permissions you should start thinking about different lists or libraries to separate them first of all. I would especially start thinking about this when you need folders to separate what may be thousands of documents or items.
SharePoint 2010 can handle millions of records in a list or library, but that doesn’t mean it’s the best way to organize that information.
Putting documents in different document libraries is just like splitting documents into folders. Except now there is another level of separation and you can’t really see them in the same view anymore, which is one of the benefits that the metadata provided. Not to mention, once you start creating a bunch of document libraries it can makes your quick launch look pretty ugly.
For my projects, even if I did create a bunch of document libraries, I would still have to create folders in them because of multiple security levels.
@Nate: Are you kidding me?! You have a choice of what you put on your quick launch and where to point the links so saying, “once you start creating a bunch of document libraries it can makes your quick launch look pretty ugly” is not accurate. Have you ever looked at a link that points to something in a nested folder? Now that’s ugly! Sometimes change isn’t always fun to enforce, but those brave enough to rough it will be rather pleased once they’ve jumped on the metadata band wagon.
No I am not kidding you,
Here is an example url from our system. It is not ugly at all.
http://siteurl/documentlibraryname/project1/invoice/
In fact I think its better than one that references metadata:
http://siteurl/documentlibraryname/view.aspx?FilterField1=project_x0020_number&FilterField1Value=project1&FilterField2=ContentType&FilterField2Value=invoice
With folders, your url is shorter and you don’t have to know internal sharepoint column names or the syntax used to escape special characters that exist in the column names.
You also don’t get what I was referring to with the quicklaunch being ugly. If you compare a sharepoint site with 1 document library with 1000 folders vs a site with 1000 document libraries, the one with the folder will render better and faster. The folders will display in a nice grid with built in paging displaying the first 100 records. The one with 1000 document libraries will display them all in the quick launch all at once which stretches the page out making it quite lengthy and it isn’t a very graceful way of handling it.
My opinion is that if your quick launch contains more than 30 or 40 things, then it probably has too many things in it.
Not to mention that you can’t sort the quick launch like you can with the folders, or view modified/created/created by, or other metadata. You can’t add custom metadata to document libraries at all.
Okay, so lets say I turn all my project sites into individual document libraries, then someone wants to view all invoices for all projects, unfortunately I would have to tell them to open every single project document library one by one, where as with my folder system, I could create a view that shows them all at once. Views don’t span across document libraries.
I could go on.
I am all for change and better ways of doing things, but it seems that folders are often the best way.
Final Note: I always utilize folders AND metadata. I usually create views that exclude folders for situations where metadata views work better. That way I can deliver the functionality that only folders can provide while still allowing powerful metadata views.
@Nate: Anytime I have a lot of libraries or sub-sites I create a custom list with the name and URLs of those sites and present this list to the user for navigation. It looks better and is more flexible than the QL.
@Savanah: I have to have folders for security reasons and I need to be able to present all of the documents in a single view for upper management. As Nate stated, I can’t do that with a bunch of libraries.
I have to say I find the discussion regarding Folders vs. Metadata always interesting. Keeping it brief, I must say I am in complete agreement with Chris.
I base this on the fact that there seems to be 2 big issues that users deem folders are necessary for: Security and Large list issues. Now we all may not agree on usage and settings and the little eccentricities of SharePoint I have to be clear about Security and Large Lists.
You can have an extremely large number of files/items in a library or list. The most I have personally seen is in the range of 157,000 items (Library). The default view presents 50 of the most recent documents only. The results populate across the WAN half a world away in about .34 seconds. All the documents may be retrieved based on Folder Names (not real folders but what their team decided to call their metadata column), dates, authors, and up to 6 other metadata items. Their longest list returns 4,500 items (only 3 exceed the recommended 2,000 item limit) in just under 4 seconds across WAN, half a world away. I think that mystery is solved.
Finally — security. Why an organization would find it necessary to manage the security of 10,000 separate items is beyond me. I guess it happens though. The same goes for folders. Why would yo want to manage information on that level? Document management, collaboration, processes, and Information management are but a few issues that come into play with SharePoint. IF a company has developed some sort of folder structuring system where many of their documents are managed and secured at folders levels then they have not been led down the right path by their consultants. OK, I will admit, I have used folders, but for very limited reasons, and never for security purposes. It has been mostly for archival purposes. How I overcome the security problem is through information architecture. What are the items, who uses the items, how often are they used, when are they used, how often are they reviewed, appended, changed, and finally when is it considered archivable.
If an organization plans their document structure company wide, I will guarantee you that the structure will not lend itself readily to folders, but to Sites and Libraries structured around security, usage, need and the type of information. As an example, I finally had a department of a particular client come to me after using SharePoint for 2 years with their information stored in several libraries under several sites and THOUSANDS of folders. In some cases the structure was 10 levels deep. At the time it was what they wanted and there was no arguing them out of it. When they came to me they begged for restructuring. Security was bombing out because they couldn’t keep ahead of the changes. People were storing documents anywhere they thought was right. They had 5 levels of security but based on their design you would hav ethought there were 500. When we finished, they had 7 Sites, each secured at the site level only as libraries inhereted from the site. 2 of the Sites were Portals where other users could accesss cross department information. No more than 7 security groups used to manage security and at the site level only. No woperational for 6 months with no permisisons issues reported and not 1 single folder in use. So here is to metadata, long live metadata.
Many of us are still thinking in terms of folders. We have to move forward.
Folder concept is inferior to metadata concept because with conventional folders you can have only ONE view, whereas with metadata you can have multiple views to sort your files.
Another problem you will face if you start creating multiple levels of folders, is that the URL length will become too long.
@Greg — fantastic!
@Nate — I’m Shocked!
SP 2010 is point and case, to be quite frank it should put this debate to rest.
But let’s ignore that for a moment: in 2007, a lot of the issues people experiece *without folders* are due to bad design rather than *having folders* being better! If you give users a folder structure 27 levels deep with nothing findable — they would not know better — thats what they’ve always had — so when you deliver a ‘folder solution’ in many ways you can’t fail. It takes good design and planning to make a new ‘paradigm’ work.
1. Enforce the population of metadata — they’ll get use to it;
2. Filter items on list at entry point
3. No one needs a single point of access 10’s of thousands of documents — split up libraries
4. If after filtering you return more than say 5000 items (nice round number) (excluding an archive which is accessed less often) you may need to re-think your filters
Job done
OK, I’m going to get slain here, no doubt. I’m not the techy that the people are in this discussion. I’m the person who runs the company and relies on the IT people to provide sound advice for a proper solution. I’m computer literate, so I constantly suffer from not knowing how to keep away from being cut by the “bleeding” edge vs. the cutting edge of technology.
I understand folders very well, and we have designed a folder system that has worked very well over the years with automated security because we are very disciplined; however, the effort to enact that discipline is, well, hard to do. If there is a better way, then I’m all ears. Unfortunately, I have a hard time getting my arms around this issue. It’s not that I don’t see the value of meta data and new thinking. What I mean to say is that the ideology behind meta data is sensical and causes me pause. The difficulty is in the “goodness” we have achieved in our file structure. It works. It makes sense. It provides discipline of information flow. It is sound in practice.
Here is where my problem is and why I am joining this discussion. I can’t stand what I’ll call the Microsoft person. This goes hand in hand that I love the Google person. Don’t get me wrong. I define the Microsoft person as a techy software engineer type. The Google person is represented by a blank white screen with a data entry box in the middle. Many billions of dollars later you see the Microsoft person telling the Google person how stupid they are, and how there solution doesn’t have all of the power, and how blah, blah, blah. I’m reminded here of the Apple vs. PC ads on TV. The Microsoft person is probably right, but who really cares.
If I have to go through HELL to get to easy, then I think I’ll stay stupid. In the very least I’ll wait until the Microsoft person creates a really easy point and click thingy that gives me what I want without having to get education like I am now. Consultants, engineers, etc. just don’t get that business owners want solutions that don’t require them to give the keys to their business into the pocket of the IT guy. The solution is only as good as the design created by the IT guy. If there is a good IT guy out there, then, well, you can see what a bad situation that is.
Why do we have to have this debate? Why can’t the Microsoft guy create a tool that forces good design regardless of meta data or folders. I’m looking at coming back to Microsoft (Office 365), and here I am having to learn computer again. Over at Google everything happens. I’m not sure how, but I get productivity quickly. Google docs just doesn’t cut it, so here we are at Microsofts door. The door opens, and there is that stubborn arse forcing me to be smart. Turns out I like being stupid.
Let the attacks begin,
Scott
Thanks for stopping by Scott. I don’t doubt you have a folder based system that seems to work well, but like anything in our lives just because something works doesn’t mean it’s the best. I could open a can of beans with a steak knife, but what I really need is a can opener. Most of us don’t realize how much better things can be until they experiment with an alternative, and no where is this more true than in technology.
SharePoint 2010 (and Office 365) has made improvements to how folders are handled specifically in regards to metadata inheritance, but it is still a sub-optimal solution. My issue isn’t necessarily with a folder structure that is only one level deep, but they never end there. They become hierarchical, and that is where the problems begin.
Perhaps I should do a video contrasting the two approaches.
Chris,
You hit the nail on the head. This arguement is, I think, solved for you if you can show what you mean. For me I will then learn and understand more appropriately what people mean behind the rhetoric. I’m a show me kind of guy. The key would be to having the show encompass the opposing sides concerns and responses; otherwise, the “show” would appear to be a spin.
How exciting that my comfortable solution would be as caveman-like a comparison of opening a can of beans with a steak knife. I’m more than willing to experiment, but I’m very, very tired of having the engineering sort talk out of their other mouth and not listening to the realistic concerns of the end users. Forcing me/us to rely on a good designer isn’t and never will be the answer because you simply can’t trust the designer to be good or understand your business.
Let the video begin,
Scott
I didn’t mean to trivialize your solution Scott simply to point out that sometimes a solution is not the best tool for the job.
I have posted the requested video.
Chris,
I don’t think you trivialized my “solution” at all. In fact it is clear that I don’t know what I’m doing, so any solution I have is suspect. I have a solution that has worked in the past, but I’m all for best practices. I’m just really tired of narrowly focused individuals (Microsoft types) who are stuck in a rut and can’t see beyond the end of their own paradigm. Therefore rhetoric needs to be backed up with “show me” ability. I’m excited to see your video and learn for myself what you know and argue.
Thank you so much for the energy you have poured into this. I’ve been trying to get a handle on it. To say the least it has proven elusive.
Scott
[…] and folders in Sharepoint 2010 It is instigated by the discussion in his blog about the Folder-less Sharepoint Paradigm. This discussion is very enlightening because of the divers views of participants of using […]
just wanted to say, this is a great post, and a great conversation. Lots of valid points throughout.
[…] SharePoint users and consultants, and I think the folder debate is probably the most common. Some, like myself, have gravitated in an extreme manner away from folders, and others have tried to tow the line […]
I’ve to agree with the post of Carl-Hein Mostert, in short
folder structure = meta data
(OK, meta data might do more than the strict tree structure of folders, but since (hd) folders can be links its almost the same)
Which automatically leads to the fault of the original post:
People that did not care about a file structure on the HD will also not have the discipline to fill in the META data.
But required field…
Just that a field is required does not mean, that it will be filled with meaningfull data.
And not all sharepoint owners do have admin rights and are allowed to change required fields.
It’s one thing which is the academical best solution, but often another thing what the user wants or is even able to understand. And users are already frightend by the word MetaData, because it sounds already quite abstract.
While I’m using categories for my private blogs (the articles are natively in a flat structure, no matter if Joomla or WP) I’m forced to use folders for sharepoint. pragmatically.
I you write the metadata yourself and especiall if you are admin, it’s a fine thing, I guess.
I would probably spend 30% of my working time, training the sharepoint members, if I would not used folders.
Interesting to see that you’re still keeping up with visitors talking about the folderless paradigm.
I’m in the position where I recognize the benefits, but sometimes it just cannot or should not be done.
This isn’t to say that there’s a lack of discipline on the part of the users, or that I don’t have the will to make it work for them. I know what the benefits are, and it’s just that metadata doesn’t fix everything.
I’ve commonly seen project documentation organized in the fashion where at the root level, you have the phases of the project, and then varying kinds of documentation underneath, and subfolders under those subfolders, etc. The fact is, you simply can’t cast this as a problem that metadata fixes. You can certainly do it at the root level, indicate that documents fall into certain project phase categories, but what happens after that? You have metadata that only applies to the sublevels of particular folders, and doesn’t make sense within the context of the others. For example, why would I need requirements documents to reside in the release instructions folder? Why would I need dataflow diagrams to be in the QA? You end up with a design where people are directed to skip the metadata where it doesn’t apply, thus leading to them generally ignoring it on the whole, and you waste a ton of time, energy, DB space/performance, and resources to put a square peg into a round hole.
And to what end? Yes yes, you can make views that filter on the metadata. But now your views list is a mile long, security management is a nightmare, and you’ve not actually helped anyone do anything better.
People understand the folder motif because it organizes things. They might be made to learn other paradigms, but it’s not part of their workflow, and does the training and effort result in a good ROI? In my experience, it really does not.
Rather than flattening everything out, I believe the superior way to handle this would have been to allow Document Sets to nest. Then you can maintain your organizational hierarchy without having your hands tied by it. Too bad Microsoft missed the boat on that one.
You would want document sets to nest? The whole point of document sets is that they be thought of as one logical unit and share similar attributes. Allowing document sets to nest with varying attributes doesn’t seem like the best route. I do wish, however, that there wasn’t a 50MB limit on a doc set.
I think the same direction like Drew (except this nesting thing).
If you have a folder structure the owner predefines a fixed structure. A member can follow this structure and see, which subfolders exist and where a dead end is. The member needs initiaaly zero knowledge of the structure.
If you convert the folder structure to metadata, the member does not only need to know which metadata is valid (i don’t know if there is a possibilitey to get a drop down box of existing metadata for filtering), but especially the member does not know which combination of Metadata is valid.
So I have to refine my agreement with Carl-Hein Mostert: Yes you can convert a folder structure in Metatags (like tag Project Phase instead of folders Project Phase xx-zz in Drews example) but for the user it’s not really equally.
Pragmatically I would say it is good to use Metadata if you have a flat structure (like a blog with articles of different categories), but if you have a system where you have already an underlying tree structure, often the tree structure itself is an important part of the information. Then it’s probably better to go with the folder structure.
This might change if MS improves the MetaTag filtering/navigation.
I’m tech-savvy, but have limited experience with SharePoint, and I’ve read the benefits of the new 2010 version, but am still not sure about a few things. Our organization is looking to migrate our information from the older version, which means we’ll have all documents in one library– no folders. It’s great, and it forces you to shorten file names and make the Titles the lengthy part (this may seem trivial, but for everyone to do this, it’s a major change). We have created a document library to house Timesheets… and we are creating/designing a Site. Some of my colleagues have gone into the library to add folders for each staff person’s name, and transferred over the corresponding documents into them. Others felt that it would be better to have a different document library on this site for each staff. I’m not sure about which one is the best approach. Any suggestions? We need the documents to be checked in and out, without being able to see everyone else’s timesheet, so permissions is an issue as well. Oh, and keep in mind that we do not have access to SharePoint Design.
Eve, I would actually suggest you not use documents at all. I would look into an InfoPath solution using SharePoint to streamline the process of managing time sheets.
Problem with that is that we don’t have that kind of Administrator access to unprotect the timesheet and convert it into InfoPath… plus our SharePoint is 2010, but all our other Microsoft programs are still 2003. We’re very limited in what we can do.
If you only have a few people then separate libraries would be fine. However, if there are lots of them then you might be better off with folders.
Dear Chris and all
I have an enquiry that is related to but not directly regarding the above discussion but there seems to be lots of expertise here so hopefully you can help me.
I am not a techy person but I am computer literate and have had some SharePoint training and been charged with the task of constructing a SP site for my company to replace the old, bloated one which got out of hand quickly due to the excessive use of folders. One thing I am not familiar with is SP designer so I am trying to build the site just using the functions available through full authority with the Site Actions.
My issue is mentioned briefly above by Amir Kashmiri and it is one of navigation/organisation of the site without using excessive layers of folders. Basically the site I want to produce will necessarily have many layers of organisation due to it’s size and scope. There are a number of sub sites at the top end and document libraries at the bottom (some of which will contain folders but they should only ever be one layer deep.) However on most of the sub sites users will need to pass through 3 layers of navigation before they reach the document library holding what they want or providing the correct space for an upload. What function does SharePoint provide to produce these layers without uising folders?
I am sure this must be very obvious to an expert but I am struggling. I already have enough sub sites and they are not suitable for the purpose, you cannot populate lists/libraries with other lists/libraries therefore they are no use until the actual storage stage and I have not found an effective way to do it with pages that would protect the end user and site from unwanted alterations. This has left me at a bit of a blank.
The whole point of this redesign was to make navigation to the correct document/storage space very simple (without layer after layer of folder) but I cannot achieve this without having the freedom to add as many layers as is necessary and the only way I have found to do so is folders but that comes with all the above problems attached (and more..!)
I hope this question is not out of place in this thread and any help would be greatly appreciated. Thanks for taking time even to read. Best Wishes
H
Sorry Hugh, but without a clear understanding of the information you’re trying to organize I can’t be of any assistance. Remember though that you can leverage multiple document libraries which might help in your case.
Sorry Chris, as I say I am not that well versed in this area so I might be using the wrong terminology, or even be making a fundamental error in my site design so please bear with me.
The information I am trying to organize is quite basic and consists almost entirely of fixed office documents and images (j.pegs) that will be uploaded/downloaded for sharing and reference but not for working on while on SharePoint. Our site will be relatively simple in what it is used for (literally sharing images and files across different international offices) and there are many functions of SP that we will not use. In other words we are using it much like a drive but with proper governance to try and ensure correct practices.
The actual organisation of these files can be done using document libraries which fit our needs well. However the issue for us is how to structure the layers of navigation from site level down to the document libraries themselves. To give an example, the site as a whole will have 5 sub sites that represent different regions. Then take one in isolation, for example the sub site for the Americas. The organisation from the home page of the site then has to be split by country, then by brand, and then at this point I will leverage multiple document libraries to store the relevant documents. Therefore it is these two layers of navigation (after regional sub site) that will lead the user to the correct country, then the correct brand before selecting the correct document library to access or upload at the correct location. On a drive they would appear simply as other folders to click through but this use of folders is what I am trying desperately to avoid. Ideally it would be incredible to have the flexibility to add as many layers of navigation as is necessary through the same method.
Is this any clearer? I have some site maps I could email if possible? As ever, without taking up too much of your time any help would be greatly appreciated.
Hugo
I really agree with the whole idea of driving views etc by metadata.
The real gotcha for me in my organisation is libraries with a large number of documents (30,000+) and the use of Explorer view and the performance problems that view causes.
The Explorer view reminds me of the quote ‘Just when I try to get out, they pull me back in’.
The Explorer view seems to be the only way (out of the box) to change the file extension of a file. Similarly when you create a document from a template, and click Save it shows the Explorer view and all documents in that library with the same file extension.
**sigh**
Both approaches have their problems and benefits. However, it seems that metadata approach leans on benefits side more than the folder approach. But I am not convinced that the metadata approach is as intuitive as folders even though it’s more flexible. Ofcourse one can learn a new paradigm and train, but I still don’t see it being as intuitive as folders. Folders put users in an appropriate hierarchical context, which makes it easier for us to understand where the user is. The problem with nesting folders is that it’s not easy to see an overview and find the right one. Right now a folder represents only a single possible hierarchy for a document, however a document could belong to two logical branches. That’s where I would like the flexibility of metadata. But right now metadata approach in SharePoint does not present an intuitive way of navigating and defining right hierarchical contexts for a document. I think if we come to a marriage between intuitiveness of folders and flexibility of metadata we will have a much better solution. I like the wordpress tagging feature where I can define a hierarchy and also assign multiple tags to a single post. And the flexibility can come from the ability of metadata to be presented hierarchically as well flat.
This might have been said already, but there are cases where you want to email a shortcut to a set of documents to someone. This can be done on a folder, not on a view. It all depends on how users are using the data and how they need to access it (and what kind of content is in a library).
Tyler, that’s actually incorrect. Anytime you change a view the URL changes in the browser. You can even change the URL in the edit view screen. They can be sent out just fine.
True. But I think there are still cases where you might not be able to filter metadata to a level where you’re getting what you’re looking for. (I’m for views.. this case has come up for me though).