if I had one of these you'd owe me my $70k back A doc like that would be very valuable IMO

I'll take the time to put one together if you really pay me $70,000 bucks. Maybe I can start developing one.... humm

I'm going back to "school" a week from tomorrow to start to develop just such a matrix. But mine will be different than yours as I'm a curtain wall detailer and my families and family categories would tend to be more specific to my business (not so many of them as are required by an Architect)

You're probably describing it correctly and I'm just being dense, but I'm not sure what some of these things would show?

For instance, what are you referring to when you suggest "what each category is capable of being nested in"? And what kind of info do you want to know about the parameter categories/labels?

I'm all for a "matrix" (I might even be able to help), but I don't think I'm grasping very well what you guys are looking for?

I'm not Alex, but I have an interest in a matrix also. It should contain, to start, from my noob perspective:
1. what types of objects should be created in what templates? Some are obvious, some not so much.
2. what family types can have nested families and which cannot, if any?
3. what family objects with a certain category type can or cannot be nested into a family with the same or different category type?
4. in what situations should Shared, Instance, or Type parameters be used? Does the selection change from one family type to another?
5. given you have decided on the parameter type, what type should it be (length, text, area, etc)? Some are obvious, some not so much.
6. what should the parameter be grouped as (identity data, dimensions, etc.)?

and, I could go on and on, but won't. I know that the answers to most of the above come with experience but it would be nice to have a family guideline matrix to help with family creation. A guideline that would say "don't go down that path, you need to head in this direction" when you have an idea for a new family.

oh, and btw, what the heck is Entourage.rft for?

isn't entourage people, cars, etc?

To start with the easy question: Entourage are "the finishing touch": curtains, mirrors, that sort of thing. People and Cars can be Entourage but are most of the time RPC's.

As for the matrix: that is going to be one hell of a job! Lot's of :banghead:. But I would like to participate in this, so we would have to think of a way to devide this challenge over multiple people. I'm guessing Dave is going to cover the CW-section...

To give a hint of the complexity, let's look at the questions you asked:
1. As for the not-so-obvious: what the hell do you create as a Generic Model, and what not? Mostly, I use this category for families that don't fit in anywhere else OR if I want a family to behave different from the standard way a template behaves.
2. To my knowledge, all families can have nested families to some extent.
3. This is something that should be thoroughly investigated. As a rule of thumb, you can only nest into families that are evenly or more constraint. For instance, you can nest a Generic Model into a Face Based Generic Model, but not the other way around. Although this might be a bad example, because thinking of this some more makes me doubt if that's not an exception (hence the investigation!). And there's a rather strict seperation between annotation and model families. You can't nest a model family into an annotation family and only very limited the other way around.
4. Well, this is just plain arbitrary. As a rule of thumb: I use SP's whenever I can. Or: when it needs to be scheduled / tagged you should use an SP. Type or instance? That's a real debate which is almost impossible to settle in a matrix.
5. Well, this might be the easiest question.
6. There's also a vey lengthy discussion about this one going on. So, this also can be difficult to cram into a matrix.

Again: let's talk about how to organize this... Start with the different Family types and divide them between people who want to contribute to this task? And take it from there?

Okay, I'm getting a better sense of it now.

Another example I would give is which families can you use "Join Geometry" to join together? For instance, you can join to "Generic" families together, but you can't join "Casework" families together (ughh!).

So, this might start off as a huge spreadsheet? I could see starting with a spreadsheet, with all the family categories down the side (rows) and all the various "features" at the top (columns).

Or do we need more of a "flow chart" approach?

Or is this just a word document with a set of lists? I could see starting with a word doc with a list of family categories, and a "feature set" under each family category (maybe broken down into a table?).

Seems like we need to compile a list of "features"? Dave, by all means, feel free to continue on with your list...

I think you will find a lot of these things are very office specific, like what to do with categories that dont fit the mold, and where to put parameters in terms of groupings. In terms of nesting and sharing, the only limitations i know of are Masses and Profiles, in that you can nest Profiles but you cant Family Type Parameter them/share them, and that Masses tend to... behave differently... When they are nested in other masses (they dont array, etc).

As for generic items, it really is an office decision. We tend to make a lot of things Specialty Equipment, since it is a ridiculously named Category that encompasses too much. But then there is the issue of SE not being cuttable, and suddenly we NAME a lot of things SE, that we actually create as Generic Models, so they can be cuttable. Or we nest shared GM's in to the SE's.

Then there are the options that are hard coded, which are stupid. Casework can have Visibility of items set to "Show only if instance is cut," whereas GM (cuttable) and SE (non) cannot.

Then, there is the issue that some Family Categories dont even respect view range: Some are able to completely bypass View range Far Clipping, like Structural Columns.

In a session of nothing more than feedback solicitation (read: No one from autodesk was talking, this was JUST our feedback to them, so dont read anything in to it) we advised them of the following:

1. ALL options for families need to be user definable: Cuttable, View range respect, Show pre-cut in plan vs. show geometry, etc.

2. Family categories need to be rethought. Obviously, opinions vary wildly on how that should BE done, but many models were presupposed:

- Keep them hardcoded, but rewrite them all to a system that makes more sense (MF2004, Omniclass, IFC, etc)
- Make them somewhat user definable (massive arguments follow this model)

In any event, it turns in to a discussion that people feel so strongly about, that it ends up being a user/office thing.

However, in preparation for that feedback session with the factory, we actually DID put the matrix together, with a sample family that was identical, but with the categories altered.

BUT, im not sure if im allowed to share it. I suppose ill have to ask on monday. It covers all family options, for all categories.