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.
