The Death of the Family Types

As most Revit users know, a family that has types can be created in one of two ways: you can create the types within the family (which I’ll call “built-in” here) or you can create the types in an external txt file called a type catalog. For quite some time now, I have been pondering over the use and future of built-in family types. The more families I do, the more built-in family types just don’t seem like the right way to go. They feel more like a shortcut.

Type catalogs, on the other hand, have been getting better, more practical for day-to-day use, and, thanks to an improvement in Revit 2012, easier to deal with than ever. Gone are the days when creating a type catalog was an exercise in self-mutilation. Now you can just open any family in Revit 2012, choose Export -> Family Types and your template type catalog txt file is ready, without any chance of spelling mistakes or incorrect data categories. Sweet!

So what about the built-in family types? What’s wrong with them? I did a little research on the evolution of types in Revit by posting a question in some LinkedIn forums to find out how built-in family types and type catalogs came to be. My feeling was that the built-in types were first and type catalogs came later as a more thought-out solution. Wesley Benn confirmed my suspicions when he wrote, “…family types showed up in version 2‚” while “…Catalog files (then known simply as the family type browser) showed up in version 4.0.” And from the version 4 release notes as posted by Wesley:

Family type browser:

Families now can have types defined in external text files. These files must have the same name as the families itself and reside at the same directory location. When the family is loaded, externally defined types are visible within the “Load Family” dialogue and only those types selected by the user are created in the project. For families with a large number of possible types such as structural shapes, this makes it simpler to manage the type lists in a project.

So there you have it: type catalogs were created as a solution for families with “a large number of possible types.” This points to the one small advantage to built-in family types, which is that they allow you to bring into a project a family and all its related types in one fell swoop. In that sense they are a sort of group, and that’s about it. Everything else about them is a drawback. Say you have a family with built-in types and you don’t want some of the types in your project. Tough luck. After you load it, you’ll have to hunt down the family in the project browser (not an easy task given the current user interface) and remove the unwanted types. If the unnecessary types are left in there, you are wasting space and increasing memory requirements (though I would have to test the latter more thoroughly to be able to make that claim with certainty – if anyone is up to the task and wants to report back, it will be appreciated). And what if you don’t have time to go hunting and instead just leave the extra types in the project? If you’re working on a team, someone less familiar with the types of that particular family might pick the wrong type, and you end up with the wrong information in the project.

It doesn’t end there either. The maximum recommended number of types built within a family is 5. That is, recommended by the Seek guidelines (though not necessarily what users do in practice). With 5 types, updating some parameters for one type and forgetting to update those same parameters for other types is a common mistake. It’s one of the reasons why I always leave the creation of new types until the very end of the family creation process. But even that won’t help if I’m editing an existing family with built-in types. The interface doesn’t make things easy either. If you don’t check for yourself, there is nothing in the family editor to tell you that a family has other types!

In contrast, type catalogs won’t automatically bring in a set of types with just a double click. Instead, when loading a family that has a type catalog, you are able to select only what you need, and even filter through the available family parameters shown in the type catalog. You can repeat the procedure to bring in other types later, when and if you need them. And editing the types or adding types to the family is something that can be done from Excel or a Google Spreadsheet. You don’t even have to know Revit to update a type catalog – think about all the manufacturers who have or will have Revit families and need to keep them updated as their product lines evolve year after year.

Type catalogs feel like the way parameters ought to be managed. It’s easier than ever to create them, and every piece of family management software that I’ve tried or seen works as if type catalogs are the norm, i.e. allowing you to load just the types you need. Yes, there is still room for improvement with type catalogs (worth another post), but built-in family types don’t seem to be going anywhere. Rather they appear to be slowly fading from use in Revit, and that’s fine by me. As far as I’m concerned, they are already dead.

Shared Parameter Standards Part 2 – What’s a Manufacturer to Do?

There are a number of standards offering a list of shared parameters for manufacturers to make use of when developing families for their products. But which standard should a manufacturer follow? I will argue that none should be followed, but that all should be taken into account.

As long as there are competing standards for defining the names and properties of shared parameters, choosing one standard over another is problematic for a manufacturer that wants to facilitate the use of their families as broadly as possible. I believe the solution to this problem is simple: manufacturers shouldn’t add any shared parameters to their families. Instead they should include family parameters for every piece of information most of their users within the AEC industry might want to use within a project.

While I began by saying that there are competing standards for shared parameters, the truth is that calling something a standard does not make it one. And so I will correct myself here and say that there is a lack of standards, competing or otherwise. For something to be a standard, there needs to be an uptake and use of said standard among its intended audience. I personally don’t see evidence of this in my day-to-day work.

Architectural and engineering firms have their own shared parameters that rarely will include any shared parameter from existing published lists, even though the same information might be covered. Whenever I start working on a manufacturer’s project, I usually start by reviewing existing content from similar manufacturers, searching for anything that could be construed as a standard way to put together the families, including shared parameters. Again, rarely do I come across shared parameters from published lists within the manufacturer content I review.

Any shared parameter that exists in a family but not in the scope of a project’s output, i.e. in a schedule, is of little benefit. And the little benefit that it has gets squashed by the current implementation of schedules within Revit. Although it might be the case that information provided by a shared parameter is pulled out of the project without touching any particular schedule, I will err on the side of that being a much less frequent practice, and add that even in that situation other scheduling done within the project will still be negatively affected by unnecessary shared parameters. Let’s take a look at a couple cases in point.

I recently finished a batch of Tyler Pipe families. These were mainly floor drains, and there are two types of information that you can apparently use for drainage calculations. On the one hand you can use fixture units for the drain, and on the other hand you can use the flow rate and free area. I would imagine that whichever option is used within a company comes down to the preference of their plumbing engineers. Having all three pieces of information as shared parameters only serves to muddy the waters for everyone. The parameter(s) not being used will always appear in the dialog boxes for creating schedules. And if the family has the connector set to use the flow rate parameter rather than the fixture units one, choosing the latter for your schedule will still require editing the family to change the association (in this case to change the Flow Configuration parameter in the connector).

Below is an image from another piping manufacturer. The family has 6 parameters added to those that were originally part of the template, and all 6 have been set as shared parameters. It’s hard to see the point of this, especially since these parameters don’t seem to hold any valuable information for the plumbing engineer.

If you try to schedule any information out of your project with that family inside, you will have to see those parameters. The two images below show the Schedule Properties dialog box when trying to create a Multi-Category schedule in a project. The first shows the dialog box for an empty project, and the second for a project that includes this piping manufacturer’s family. Just one manufacturer family added to our project, and we now have 6 extra parameters to sort through, spelling mistakes included.

If manufacturers refrain from setting any parameters within their families as shared, and yet those parameters are still included with the right information in them, then all it takes is a quick edit by those adding families to a project or company library to get all of the relevant data into their corresponding schedules. The only thing for the manufacturer to decide is the name of the family parameters. And here is where looking at current lists of published shared parameters comes in. The manufacturers should try to use common names from published lists whenever possible and appropriate. It facilitates the job of turning that parameter into a shared one by the architect or engineer, and it doesn’t require learning any manufacturer-specific nomenclature.

In short, I see no benefit to manufacturers defining shared parameters in their families, whether using published lists or their own criteria, but would encourage manufacturers to look at published lists for guidance on how to name their family parameters.

Offset Parameters for Plan Symbols – Part 3

This is an update to the two previous eponymous posts that adds a small but elegant improvement. The idea comes entirely from Bryan Caudill, Electrical CAD / Revit Leader at Cannon Design.

Earlier I detailed how a length parameter, Plan Symbol Vertical Offset, can shift a symbol away from a wall. This helps avoid symbols overlapping in plan view when two objects in the model sit on top of each other, e.g. a receptacle (socket) and a light switch, without having to move any 3D geometry.

As shown in the image above, the parameter’s length value represents the distance the symbol will shift in paper space. If we don’t know the exact dimensions of the symbol, this might require some trial and error to get right. And if we have more than two symbols, we’ll have to do some arithmetic to make sure that all the symbols are evenly spaced.

With Bryan’s improvement, we can simply set the order of the symbols with values like 1, 2 and 3, as shown in the images below, in order to achieve a cleanly spaced offset.

What follows is a technical explanation on how to implement this technique. There is no video this time, but if you had a look at the previous posts and follow these instructions there should be no problem to get it working.

First let’s add a new parameter to the host family and call it Plan Symbol Vertical Location and make it a NUMBER. Then set its value to 1.

Next let’s edit the nested symbol family and change the old Plan Symbol Vertical Offset and call it just Vertical Offset (I also changed the Group from Constraints to Other). Then add the following formula to it:

(Plan Symbol Vertical Location - 1) * [symbol’s height]

We will end up with the parameters and formulas shown below.

Next we will need to create two parameters in the host family, i.e. Plan Symbol Vertical Location and Plan Symbol Horizontal Location, and delete the old parameters (Plan Symbol Vertical Offset and Plan Symbol Horizontal Offset).

Finally, insert the symbol family back into the host family, associate its two Plan Symbol Location parameters to those of the host family, and we are done. Now we can just plug in a sequence of integer values to our overlapping symbols’ Offset parameters – 1 and 2 if we have two symbols, or 1, 2, 3, and 4 if we have four symbols, etc. – and generate a neatly spaced row (horizontal offset) or column (vertical offset) of our symbols in plan view.

There is one caveat. As it turns out, not all symbols have the same dimensions, so in the formula shown above, where it says [symbol’s height], you should make use of the most common height within a library of symbols and then use the same for the width. That will allow you to enter integer numbers for the Offset parameter most of the time, and only now and again require tweaking the parameter to have a value with decimals.