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.
