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!

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.

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.

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

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