Family : Type : Instance

Changing categories of placed "system" families is of course going to cause a problem with the whole Family:Type:Instance paradigm. Right now, the System Family IS the Wall Layered Construction tool.


However, I do think the family/type/instance relationship should be maintained. What I'm proposing is that the part of the system family that corresponds to "Family" which is the "layered construction family" would now be allowed to be multiple categories. So, if I change the category of one instance, I'm actually changing the category of all instances of that type, and if it isn't already there I'm also creating a Family in the new category called "Layered Construction". This would also apply to creating families. So, when someone picked door and then grabbed the "layered construction" tool instead of place component, it would basically create a family in the door category called "Basic Layered Door" or something and then create a type under it for what you're modeling at the moment.


Of course, based on that last example the clear suggestion is that the Layered Construction family can be used to create ANY category, and similarly use can use a "component family" for any category as well. I think this is also critical because, frankly, there are walls that are neither layered nor panelized nor path arrays (railing tool). Those we need the flexibility of custom component families to create but we still need the "wallness".


I think you could make a pretty good argument for having the category be a property of the type and not the family on a program wide scope, but that would entail re-organizing the project browser (from a UI perspective) and I don't think it is critical to do so for this to be effective. People can always "duplicate" the family and change its category to get a new type in a new category. But that can be a discussion for AU.