Parts&Families Management Rant

Robert::

Perhaps I am not interpreting your comments correctly, but I believe that a large amount of your complaint (#1) is solved in V8i with Family/Part Concatenation.  The screen capture simplistically captures concatenation where a part "CMU" exists in the family "Wall Leafs" at both the project and corporate level and the project settings over-write the corporate.  The blue "Wall Leafs" indicates that a part from that family is defined elsewhere, and the red "CMU" indicates that the part is being overwritten by a part definition at an other level.  If you are not familiar with this and would like me to elaborate just reply indicating as such and I will go into further detail.  

I hope this helps,

Travis

Robert::

Perhaps I am not interpreting your comments correctly, but I believe that a large amount of your complaint (#1) is solved in V8i with Family/Part Concatenation.  The screen capture simplistically captures concatenation where a part "CMU" exists in the family "Wall Leafs" at both the project and corporate level and the project settings over-write the corporate.  The blue "Wall Leafs" indicates that a part from that family is defined elsewhere, and the red "CMU" indicates that the part is being overwritten by a part definition at an other level.  If you are not familiar with this and would like me to elaborate just reply indicating as such and I will go into further detail.  

I hope this helps,

Travis

The problem is it is still too compicated  

The terminology does not even match educaton.  I never heard of a wall in any architectural school but I do know what a wall is and a wall assembly is.

I don't know what you think is too complicated?  Steps... 1. Copy part from corporate level  2. paste into project XML 3. make changes to part setting as needed  4.  Commit changes.

If you are being critical of the names of the families in the screen capture that is just one workspace (not Bentley's delivered workspace) and you can call them whatever you like?

I gues I am lost to a need for a project level unless you are looking for less parts to scan through.

Otherwise why not a growing group of parts that will evolve into something for all new projects.

Otherwise you spend time copying from project and recreating the wheel.

I have this need as some clients require client-specific deliverables (not just particular gov't clients, but others) AND they have model deliverable needs as well.  They don't want a jumbo-all-encompassing dataset of every part I've ever created.  They just want theirs.  

If all you have is a 2D or a PDF deliverable, your single growing-group parts may work.  In my world of multiple offices, synching part libraries, model deliverables, etc.   Project-based libraries are crucial and integral to the workflow.

Echoing Shawn's comment.  Firms that have any of the following: multiple offices, studios, divisions, or project types would want Family/Part concatenation.  There are certain parts that can be standardized for all project types and those would be your Corporate standard families/parts.  Then there are parts that are project type specific.  You wouldn't want the same parts for designing a hospital as you would for designing a manufacturing plant.  There are specialized wall types for prisons/institutional buildings that not everyone would want in a corporate mega-dataset.  There are also cases where 1 project might want to show data differently from other project for one reason or another, concatenation allows that.  In most cases, there will not be a single solution that fulfills every need.

-travis