2016-17 Door Library - Head Height

A comment was submitted to an earlier post about the new library of door families that came with the 2016 release. The question had to do with changing the head height of these doors. There are two folders (see the images in the other post): Residential and Commercial as well as a smaller collection of doors that are more similar to the past door library we had, but using a new naming convention.

The doors in the Commercial folder have an Instance parameter called Masonry Frame which toggles on/off a solid form that adjusts how thick or high the head of the door is. This image is the same door side by side but with the parameter off on the left and on for the door on the right.

The doors in the Residential folder don't share this family strategy. Neither do the individual door families that are found in the root Doors folder. What is visible on the residential doors is trim, not a frame. The trim is designed to turn off if the Door Offset parameter is not set to zero. The frame form they do have are based on a sweep that doesn't allow for varying its dimensions.

Like all families, how they were conceived of and then created greatly affects their usefulness. In the case of the comment posted, the commercial collection of doors may work for them where the residential ones probably won't; not without some fundamental changes to the families themselves first.

Managing Content

Here's a little suggestion related to the ongoing (maybe terminal) content situation we've been facing ever since computers started helping us do our work. Where and how do we organize our stuff? For Revit I recommend this approach as a starting point. People are creative and this may not cut it for you or your firm but it works pretty well on average. I recommend the following folders.

• Revit Stock Content (their stuff)
• Office Content (your stuff)
• Project Content (the project's stuff)
• 3rd Party Content (everybody else's stuff)

Why go to the trouble to keep them separate? Why not just dump them all in one folder? Well for me one reason is versions, versions of Revit. IF you have to support projects using more than one version (2009, 2010, 2011 not RAC versus RST) you'll realize it needs to be obvious which version families were created for. We can't use 2011 families with older projects. Another reason is that I don't want to mix it all together just to try to keep my sanity. We can use careful naming conventions to avoid confusion and overwriting files by accident but separate folders seems more obvious to me. Naming is a whole nuther can O'worms! Once a family is inside a project its name will spark another conversation so folders with good naming conventions is a balanced team.

The workflow is something like this:

• I need something
• I look in our Office Content - find it/use it
• If not, I look in Revit Stock Content - find it/use it
• or search 3rd Party Content
• I'm not satisfied with either - modify it/use it
• I save it in Project Content (our quarantine)
• We review Project Content for promotion to Office Content

As a diagram or flow chart consider this:

You can also consider organizing the content into specific folders (Office Content) so that it becomes more obvious to users what is available/appropriate. You can also consider a product like Kiwi Codes Family Browser.

This application lets you define collections of families into tabs within their user interface. This means the content can be any where you want but the users gain access to only the content you really want/need them to use. Pretty slick!