Family Editor Thought and Tips

There are many great ideas for improving the family editor experience "out there" already. Here's another thought prompted by some Shared Parameter loading.

When you first enter the Parameter Properties dialog, after clicking the Add button, the radio button for Family Parameter is selected and the Select button is disabled.

Seems to me the button could be enabled. This would allow me to click on the button to select a shared parameter without having to first change the radio button selection to Shared Parameter instead. It's just one click different but if you load a series of shared parameters repeatedly now and then one less click is one less x number of parameters involved.

Seems reasonable to me...now for a couple tips.

Here's a little data entry tip in the Formula field, click past the value to select everything faster. If you click "on" part of the formula entry the cursor lands there. If you click past it looks more like this.

If you click on the formula then it ends up like this.

Once you click in the field the "tip" is "off", you have to click elsewhere (outside the field) before it will work that way again. If you are already in the field the Home and End buttons work nicely to move to the beginning or end of the formula. I find CTRL + A (select All) doesn't work there so I tap Home and then Shift + End to select the whole line. Then again I don't usually do that at all, I use my tip and click past the text.

Okay, one more really subtle one, as if that wasn't subtle. Ever notice how the information in the family types dialog can "jump" when you click in a field, like in the formula column? That happens when the column is wider than what the dialog can display. Easy to fix, just squeeze that column so it's entirely visible and Revit won't jump (scroll over to the right usually is what I mean by "jumping").

Shared Parameters aka Dictionary

A Shared Parameter is like a definition and the Shared Parameter file is like a dictionary.

Consider that a family parameter is confined to a family. It can be seen from within a project but not scheduled or tagged unless it is a built in parameter like those listed under the Identity group (and provided for us by Autodesk).

Consider that a Project Parameter is part of a project and applied to categories of families so that it can be scheduled, but NOT tagged. Like a Family parameter it is "trapped" there, in the project.

A shared parameter bridges both trapped conditions, acting as a definition we look up in a dictionary (the shared parameter file). We store our common definitions there so they can be applied in other projects or families. When you create a family or project parameter using a shared parameter (definition from the dictionary) it is really just another parameter but it has expanded possibilities because it is "shared", the data stored with it can be scheduled AND tagged.

Parameter Related Post Summary

Updated August 1, 2013

Posts from 2005

(2005) What are parameters and why should I care?
(2005) Sharing Parameters - An Overview
(2005) Shared Parameters - Part 3
(2005) Shared Parameters - Part 4
(2005) Making a Shared Parameter File
(2005) When is an Instance really a Type?
(2005) Ignore Good Advice

Posts from 2006-2008

(2006) Walking on Thin Ice
(2007) Family Editor - Parameter Order
(2008) Duct Size Parameter - Inches - Revit MEP
(2008) Dept. of Subtle - Filter Parameter in Tags (really subtle)
(2008) Shared Parameter File - A Little Clarification
(2008) Shared Parameter - No you Can't -Yes you Can

Posts from 2009

(2009) The Order of Parameters - Revisited
(2009) Titleblock Parameters
(2009) Which Group? Choosing a Parameter's Parameter
(2009) Revit Family Style Guide
(2009) Titleblock Parameters
(2009) Dept. of Subtle - Family Editor Parameter and Formula
(2009) Back to Basics: Mark and Type Mark
(2009) Dept. of Subtle - Three Parameter Tips?
(2009) Revit API SDK - AutoParameter

Posts from 2010

(2010) Export a Shared Parameter
(2010) BIM Family Toolkit at Autodesk Labs
(2010) Dept. of Subtle - Parameter Shuffling
(2010) Family Editor - Use a Default Type
(2010) Dept. of Subtle - Omni Class Parameters Missing

Posts from 2011

(2011) Parameters Again
(2011) Parameters Again
(2011) Dept. of Subtle - Family Editor Parameter Lock
(2011) Dept. of Echo - Type Catalog Formatting
(2011) Dept. of Echo - Shared Parameters for Manufacturer
(2011) Family Type Parameter Gotcha
(2011) Revit Content Standards - ANZRS
(2011) Dept. of Subtle - Connectors and Diameter
(2011) No Math Characters in Parameter Names
(2011) Family Category and Parameter Dialog
(2011) Shared Parameter Utility - Revit SP Writer

Posts from 2012

(2012) Connecting Parameters
(2012) Connecting Parameters in Nested Families
(2012) Pushing Parameters Around
(2012) Parameter Grouping
(2012) Shared Parameter Article at AEC Bytes
(2012) The Shared Parameter File has no Relationships
(2012) A Small Collection of Family Editor Advice
(2012) Parameter Pecking Order or Priority
(2012) Shared Parameter Czar
(2012) Which Overwrite is Right
(2012) Shared Parameters aka Dictionary

Posts from 2013

(2013) Working with Type Catalogs
(2013) Associate Family Parameter

Connecting Parameters

You've just downloaded some content from a manufacturer's site and realize that none (or many) of its most interesting parameters are not going to show up in your schedule. This is due to the lack of a common shared dictionary of parameters that we can all rely on. Revit's "system" parameters like Width and Height for some components (like Doors or Windows) just work automatically. Just starting out with a door template means that at least a couple parameters will work without any extra effort. Not true for enough others though.

The Autodesk Family Style Guide (AFSG) while primarily focused on the needs of Autodesk's Seek site also provides a set of shared parameters we can all use (check out ANZRS too). It's weakness is relevance and timeliness. It has a lot of MEP related parameters but doesn't delve into other disciplines seriously and it's really late to the table. Most of the firms that have been using Revit seriously have already dug into their own shared parameters by now. Redoing their library to be in line with Seek and the AFSG doesn't actually begin to help them unless they really start using a lot of Seek content, which is another can of worms.

Rather than continuing to lament the situation this post is intended to provide one solution to getting "foreign" content to work within your existing project(s) and template(s). Assuming you've already mapped out your own shared parameter strategy you just need to connect the dots between the parameters the family is using and those that you wish it was referring to, your own.

It's rather simple really. Add your own Shared Parameter versions of the critical parameters in the family you are working on. For each, in the formula column enter the name of their equivalent parameter. This maps (connects the dots) their parameter value to yours.

Now you can schedule their component along side your own, even tag if necessary. It's a lot simpler than trying to remap all their parameters to your own by replacing them.

It is a little risky in that people will have two places that the values could be touched, their parameter and yours. I usually just segregate them in a separate Group. Just let your teams know how you are dealing with content obtained from other sources and it's not mysterious anymore.

Shared Parameter Article at AEC Bytes

Since I recently wrote a series of posts about them I thought I'd mention yet another source of information about them. Daniel Stine wrote an article recently for AECbytes. Check it out!

Parameter Grouping

Consistency, CONSISTENCY, consistency...

This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.

When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.

If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?

Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.

Curious about why I'm using Mounting Elevation when you can clearly see Default Elevation just above it? I can't tag something with the Default Elevation parameter (Data Devices in this situation), it's not among the parameters available in a tag family. I'm using a shared parameter for Mounting Elevation and "connecting the dots" with a formula that is equal to Default Elevation.

I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...

I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.

Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.

Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!

If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.

Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).

Export a Shared Parameter

or alternate title, "Road to Recovery"

When you don't have access to the original Shared Parameter's file there are two ways to get to it, via a family or in a schedule. Either way you need to be able to “touch” the parameter so you can use the Export option for shared parameters. Revit will add the parameter to the current shared parameter file you are using.

In a family you need to open Family Types, select the parameter, choose the Modify button.

In a project schedule you need to take a look at the view properties for the schedule, view the fields, pick the parameter, then click Edit.

In either case you just need to click Export and Revit will warn you that it will add it to the current shared parameter file you are using.

 

If the Export button is not active it is because you don’t have a shared parameter file selected yet. You’ll need to do so first. Go to the Manage Ribbon > Settings panel > Shared Parameters button, browse to find it or create one from scratch.

The only family type that doesn't play along with this scenario is titleblocks. Shared parameters that are used in titleblocks must be "connected" to a project by adding the shared parameter to the project as a project parameter too, since titleblocks are sort of a "tag" for views.

Parameter Pecking Order or Priority

There is no preference applied to one over another. A Shared Parameter is no different than a Project Parameter... a parameter is a parameter. How they are defined and shared between projects and families is different.

A family parameter is confined to the family. It can be seen and altered from within a project but not scheduled or tagged unless it is a built in parameter (created by Autodesk's Revit team) like those listed under the Identity group.

A Project Parameter is part of a project and applied broadly to a single category or even categories of families so that it can be scheduled, but not tagged.

A shared parameter bridges both, acting as a dictionary (the shared parameter file) by storing common definitions so they can be reused (yes "shared") in other projects or families. When you add a family or project parameter using a shared parameter (definition from the dictionary) it is really just another parameter but it has expanded possibilities because it is "shared".

If you add a family parameter to a door called "My Parameter" and add another Project Parameter to your project called "My Parameter" (applied to door category) and create a Shared Parameter (added to door and project) called "My Parameter" you'll end up with four (4) parameters called "My Parameter" in the project. All will be listed in the properties of the door family in the project. A couple will be listed in the door family itself when open in the family editor. A couple will be available in the Schedule Properties dialog. The name we "see" for a parameter isn't really what makes it unique. They have a GUID (globally unique Identifier).

Short answer...doesn't matter how you add the parameter, Revit doesn't pay more attention to one over another or deal with one kind first, then another...no pecking order.

Shared Parameter Czar

I encourage people to have a single point of contact (POC) with Shared Parameters. If a project needs a new parameter then see the POC for getting it added to the office Shared Parameters. Often this interaction makes a team aware of the fact that such a parameter exists or a similar one does for much the same purpose. Same goes for firms with more than one office. They just need to share a read only copy of the shared parameter file for each office so they can use them too. Call the POC the SP Czar or King or Gov... put one person who has the best handle on what exists and what's possible and what it's all about... Alfie.

If you have job or client specific sets of parameters, just create a separate group for them. Avoid having job specific things for generic things like length, width etc. Often this starts with documentation requirements, what has to appear in a schedule for example. If you and the office can define what information must appear in that kind of documentation you can map out a parameter strategy. Keep in mind that this situation is happening in every office and for every person that makes content... I think of it as the great big can o' worms that Revit and BIM have spun the lid off and hasn't resolved.

The Shared Parameter File has no Relationships

I frequently read about or hear questions about this concept that generally assume or expect that there is some inherent (permanent or connected) relationship between a shared parameter file and the use of such a parameter in a project or family.

The shared parameter file has no active relationship (no link, no "xref", no lookup) with your families or projects so there is no risk of someone running off with it, or it getting deleted. The shared parameter file is only used like a "dictionary". We/Revit uses it to "look up" a parameter definition to apply it to a family or project. Thereafter when Revit encounters it in the project it knows what it means. Thus no active connection to the parameter in the file itself.

If someone loses the shared parameter file it is possible to export shared parameters from projects that have them to restore their definition to a new "dictionary". You can read this post to find out how.

Room Name Alternates

This is a repost of one I wrote back in December 2008. It came up again recently in a question via email and I noticed it's a pretty old post so I thought I'd plug it again.

Sometimes a name is just too much, too long, it just doesn't fit in a room. The stock Name parameter for a room is easy, it's already there waiting for us to us. When we use abbreviations in this parameter we end up with some full names and some abbreviations. An abbreviation of "T." for Toilet might be fine on a plan view but it is less than stellar in a schedule. We could use another stock parameter like comments to store an abbreviation instead but that subverts its usefulness for actual comments.

Shared Parameters to the rescue!

I've written several posts about shared parameters in the past so I won't go into making them again in this post (see bottom). This is what you need to do to get a new parameter working in a project.

Create a shared parameter (called Abbreviation for example)

Create a room tag family that uses your shared parameter, save the Family and load the family into your project

Add a Project Parameter (Settings > Project Parameter) using your shared parameter too. Assign the parameter to the Room Category

Use the parameter in your rooms, set-up a schedule and tag your rooms with the appropriate tag.

This gives the best of both worlds. Supply abbreviations for names that are unruly and don't bother for reasonable names. A schedule will make it easy to define either and those that don't have abbreviations don't "need" them. Just make sure you use the correct tag to display the value you really want people to see. You could also use this technique to provide a room name in a second language, if necessary.

I've posted a revised copy of my Egress Example project that contains a working example of the shared parameter, tag and schedule.

This post Shared Parameter File: A Little Clarification provides a full list of the posts I've made in the past on the subject of Shared Parameters.

Assigning a Dimension Oddity

Received a question via email asking why Revit seemed unwilling to assign a Shared Parameter that used the Duct Size type to a dimension string. Here's what the SP properties looked like.

The quirky part assumes that you want to select a dimension string and then associate it with the SP. This is what happens when you do that.

I've recorded a brief video to show the result too.

Parameters Again

I've written about these a lot over the years. It seems to me that this dialog, and specifically the highlighted portion, is all too often either misunderstood or ignored.

The message seems pretty clear, to me at least, but here's my version:

• Project Parameters can be used in schedules but not for tags
• Shared Parameters can be used in schedules AND tags

I left out the part about shared with families and projects because...well...that's what the word shared means. I left off the part about exporting to ODBC because that's just another level of complexity. If you use Shared Parameters you win, you get that too.

If the information you care about is only expected to appear in a schedule then a Project parameter will suffice, it will work, it will give you the result you are after. If there is the slightest chance that someone will then ask for the same information to be used in a tag then you need to plan for a Shared parameter. You might consider only working with Shared Parameters for this reason, it's hard to out guess others.

This post "Shared Parameter File - A Little Clarification" revisits parameters and provides a summary of links to other posts I've written over the years. I've also copied them here:

What are Parameters and Why Should I Care?
Sharing Parameters Overview (Part 1)
Walking on Thin Ice
Making a Shared Parameter File (Part 2)
Shared Parameters Part 3
Shared Parameters Part 4
Ignore Good Advice
Home for Unwanted Doors