When you are creating Revit families and begin the task of naming and assigning parameters how much thought do you give to the end user experience and how they will need to interact with those families in a project setting?
When creating content we need to look at who will use, modify or access the information. We need to design for a variety of user types and roles; those with little Revit experience and veteran users; various ‘specialist’ roles in the design team (interiors, planners, envelope, general detailing); users with varying degrees of professional experience and downstream stakeholders who may only see the parameter as a data field name.
Let’s look at some examples. When creating a bookcase family, how would name the various parameters in the image shown. Would the face dimension be a WIDTH or a LENGTH? Would the front to back dimension be a width or a thickness? Is the top to bottom dimension a height or a depth? The overall dimension of the unit might be considered a height by most, but most people would call the vertical measurement for each shelf a thickness, not a height.
Take the case of simplified, rectangular multi-purpose family for furniture. You could create every conceivable piece of four side furniture using this family. When considering just three parametrs to define the basic geometry of the shape (the X, Y, and Z aspects) you could get confused.
For a bookshelf X=Length (or width?), Y = depth and Z=height.
For a work surface X=length, Y=depth, Z=thickness.
For a bed X=width, Y=length, Z=height
To combat the issue the case can be made for naming parameters within the family using ‘universal’ naming conventions. The values exposed to the user could be more in tune with the specific needs of the family type. This approach would allow for increased internal standardization (fewer shared parameters) and a more consistent approach to naming things and at the same time may reduce confusion or ambiguity to the end user as a result of using cryptic parameter names.
This line of thinking might apply to families where users are able to define types more than families that have set types. i.e. If the end user will not be permitted to alter or create new family types then it really doesn’t matter what the parameters are called.
In addition to all this fuss the usual naming convention issues also come into play;
UPPER CASE; lower case; Title Case
Underscore_Separator; Space Separator; NoSeparator
Hyphens or no hyphens (pretty much universally not recommended in case you want to use parameters in formaulae)
and on and on…
So what’s the answer? No answers here, no one-size-fits-all; I just wanted to get you thinking. As with most things in life there are few absolutes; just a variety of choices each with benefits and consequences. How you define these standards for your office or your clients will depend on the end goals you are trying to achieve and weighing the pros and cons.