Organization of Shared Parameters ?

[MKEllis]

Having developed a number families using shared parameters - I've started to look beyond the immediate file and more towards how these shared parameters should be named and structured.

For the moment I had created shared parameter groups based on the general family type:

Doors

Internal Screens

Furniture

etc...

Trouble is, I quickly found that certain parameters are common across many groups (ie. length, depth, thickness, width....). Initially I got round this by making more specific labels. ie Depth became "Door Frame Depth", "Internal Screen Frame Depth" etc. and each was placed under the appropriate category. I can see how this could very quickly become unwieldy with possibly hundreds of variation of a 'depth' label to suit each occurence.

So presumably, it is better to group the parameters more by parameter type and allow them to be used for whatever family type needs them. Can a shared parameter (say 'Depth') be used across multiple families with no issue ? (obviously not within the same family). If this is the case, can the parameters be arranged along the lines of say:

Dimensions (length, depth, thickness, width....)

Physical Properties

Design Requirements (security, acoustic)

Materials

Thermal Properties

Fire Performance

Life Cycle

Manufacturer / Supplier

etc.

In addition, I am also looking at CoBIE 2012 UK - which also has a raft of parameters, some of which apply to multiple types of family. It looks as though I may have to add a couple of other CoBIE specific groups - or maybe add those parameters under the same headings above.

Does anyone have any advice, or pointers to how the Shared Parameters are best organized on a practice rather than project level ?

Many thanks

Martin

[Paul_F_Aubin · Accepted solution]

I think your insight on this is correct and your second proposed groupings are the way to go. You can successfully use the same shared parameter definition to create parameters in any project or category without issue. In fact, when you consider schedules, having the SAME parameter for multiple objects would allow the values to appear in the same column in a multi-category schedule (should you ever need that).

[MKEllis]

Thanks Paul.

Shared Parameters seem to be one of those areas where - if you're not too careful - you can progress along one path before realising there is a more efficient way of dealing with it. Although I've created a few nested family types (internal doors and screens), it may be better to re-define these with a bit more rationalisation in the Shared Parameters.

Heck, the more families that I've put together I begin to realise that they could all do with a bit more rationalisation (I do have a tendency to throw too many parameters into a family trying to cover as many eventualities as I can think of).

I guess it is the nature of Revit, that the more you learn, the more you realise how badly structured your previous constructs have been and If you're not too careful you can end up re-doing the same content again and again.

Thanks again Paul,

Martin

[Paul_F_Aubin]

Right you are! I can't tell you how many times I have gone back into some peice of content and found myself wanting to completely rethink it... 

It does settle down after a while.

Shared parameters often provoke "over thinking". I like to keep it as simple as possible. But this is not always easy to achieve. I certainly understand the temptation to plan for eventualities. But you can end up overdoing it too. Remember, you can always come back and modify later if necessary. And when you do, you'll look back on your previous attempt and question your decisions again... vicious circle... LOL. 

[MKEllis]

Is the Shared Parameters file a 'live' document ? in other words, is it referenced after a family has been established with shared parameters ? will any changes made to shared parameter names / grouping impact on families that have already been set up and placed in a project  - or is it a once only reference to the file whilst the parameters are being 'mapped' in the orginal family creation.

I assumed that it remains a live reference - and that I would therefore need to reconstruct the families if the shared parameters are re-named / re-organised - but if not, then I could leave the families as they are (?).

Thanks,

Martin

[Paul_F_Aubin]

The shared parameter file is NOT live. In other words, once you make the parameter, it is its own thing. However, it contains the unique ID that came
from the shared parameter so that if you use the same SP in another context, Revit will treat them as the same. Here is a quote from AU class this year on this subject:

"The shared parameter is really just the rules to create the parameter. Each shared parameter is completely unique. In the shared parameter file is a
unique identifier that Revit maintains for us. This is very important to ensure the proper functioning of the shared parameter and is what makes it
“sharable.” Think of the Shared Parameter as the recipe for your favorite meal. It establishes the ingredients and steps required to get a tasty dish.
But it is not the meal itself. But each time you prepare the recipe, you get similar results. In similar fashion, in each project or family where you
use the same shared parameter, you will get the same results in your content, schedules and tags."

You might want to check out this paper as I have discussed a lot of info on shared parameters in there. 

You cannot "rename" a shared parameter in the shared parameter file. Once it is created, it is unique. You would have to delete it and re-create it.
However, you CAN easily rearrange them into different groups after creation and this has no impact on the families that use them. The groupings ONLY show in the shared parameter file. If you do decide to delete and recreate, you can edit an existing parameter in an existing family or project and modify the parameter to point to the new definition. This will change it to match the new one you select including the name.

Hope that helps

[Paul_F_Aubin · Accepted solution]

This board seems VERY fussy about links. I tried to post the link to my AU paper in that last reply and it did not work. Even though there is a link butotn here, it fails everytime. Very frustrating. 

OK, my website has the papers posted for my AU classes. This year I did the Advanced Families lab with lots of info on shared parameters. I am going to try to attach the PDF here. See if allows attachments. 

Otherwise, visit www dot paulaubin dot com slash au

[MKEllis]

Many, many thanks Paul, that PDF is great - and seems to address many of the issues I was coming up against.

I see what you mean about being unable to rename shared parameters. Given the ad-hoc nature of my shared-parameter naming to date, I am inclined to redo it - and then simply re-map the shared parameters as necessary (or remodel the families in question - some of the earlier ones need a bit of 'rationalisation').

Many thanks again Paul,

regards

Martin Ellis

[Paul_F_Aubin]

Glad to help.

[SteveKStafford]

As Paul wrote earlier, I too think you are grasping the typical concerns that arise. It does make sense to avoid creating many depth parameters when one could do. For me groups should help me look up a parameter definition easily. The typical reaction is doors, windows etc... But as you've discovered that may not be the ideal grouping.

There are also a number of system parameters, like Height and Width, that beg for our own versions because they are predestined to behave a certain way by Revit.

In those situations it makes sense to use a prefix that can still be generic enough but unique, such as Unit Width or Unit Depth for overall dimensional values like we find on catalog cuts. I also see firms using their initials to make their own shared parameters stand out, like A_Width or A_Height.

I think the Shared Parameter file is a lot like a dictionary. We store definitions there. We can look up definitions while working in a project or creating a family. We (Revit) store the definitions in either and Revit doesn't need to look up the definition anymore. Like a dictionary the shared parameter file is a resource but it doesn't have a live or linked relationship to any projects or families.

Fwiw, I've written about Shared Parameters (parameters in general) frequently over the years on my blog. This is a SUMMARY post if you're interested.

[LDShaw]

Before I start. This idea came from Michael Kilkelly’s website it does not originate with me.

I know this is an old thread I was looking up advice on organizing families and I ran across a great trick on this very subject. Create text parameters that act as comments and describe how the parameters are to be used. While it may clutter up your parameter dialog box 6 months from now it could be of unfathomable help.

Here’s an example.