Characters in Shared Parameters:

[jj mac]

Hi there,

I am considering different naming conventions for use in our office standards with respect to shared parameters. I would like to use the " : " (colon) character in the parameter name, in this fashion:

Parameter Name Example:

Doors: Door Material, where "Doors:" describes the Revit category the parameter belongs to and also groups similar parameters within a category group alphabetically. Door Material would be the parameter in question. In this particular case it is a text parameter that we use to describe the door material.. ie… HM (hollow metal)

Another example would be:

Walls: Wall Type Category, where Walls represents the Revit category, and Wall Type Category represents a parameter we use to categorize our wall types.

Two questions come to mind. The first is - what limitations might there be when using a colon in a parameter name? One example I thought of is when working with formulas. I am not using it for is dimensions because we may need to use dimension parameters in formulas from time to time; although I have tested it regardless, and the formulas still work. To be safe though, it's the only exception to the rule.

The second question is - does the logic in the examples make sense with respect to organization? From reading some other threads, it seems there are a few different ideas on how to organize the parameters so they are easy to manage in a project, and easy to implement for an office. All seem to make sense and are well thought out for that particular company or organization. This is the tread here:

http://forums.augi.com/showthread.php?t=107501&highlight=shared+parameter+naming+conventions


Any thoughts and ideas appreciated.

[twiceroadsfool]

We have some Shared parameters that have colons in them, but it gets confusing since SP's can have colons and regular parameters can not. Also, just to save everyone time when troubleshooting families, i try to get people to leave punctuation marks of any kind out of parameter names.

As for organization, its here nor there, if the wood Door is at the front of the parameter. it ONLY matters when looking at the Project parameters dialogue anyway, and most of our office spends next to no time there, since we have the parameters loaded for them.

[Alfredo Medina]

If you want to classify your objects by categories, you don't need to add a prefix; that's why the shared parameters dialog provides a feature for creating groups, and within those groups, you create your parameters.

However, if you name your shared parameters with a prefix by category, or even if you create groups by model categories, you are going to end up with a very long list of parameters, which will be very difficult to handle, and very redundant, because you will be using each parameter for only one category, missing the potential to reuse your parameters; you'll see later that many elements need most likely the same set of things. Keep in mind that shared parameters are recyclable.

Another approach is to have just a few groups, by function, with generic parameters that can be applied to multiple categories at the same type, over and over again.

[jj mac]

if the wood Door is at the front of the parameter. it ONLY matters when looking at the Project parameters dialogue anyway, and most of our office spends next to no time there, since we have the parameters loaded for them.

This is a good point on two accounts. The main reason I wanted to this is because the dialogue for project parameters is a) not expandable, and b) not group-able.

Most of our users are not concerned with adding shared parameters on their own either and this is either pre-set in the template or for some one-off cases, needs to be added as we go...

Thanks Aaron

[jj mac]

If you want to classify your objects by categories, you don't need to add a prefix; that's why the shared parameters dialog provides a feature for creating groups, and within those groups, you create your parameters.

However, if you name your shared parameters with a prefix by category, or even if you create groups by model categories, you are going to end up with a very long list of parameters, which will be very difficult to handle, and very redundant, because you will be using each parameter for only one category, missing the potential to reuse your parameters; you'll see later that many elements need most likely the same set of things. Keep in mind that shared parameters are recyclable.

Another approach is to have just a few groups, by function, with generic parameters that can be applied to multiple categories at the same type, over and over again.

Alfredo:

Thanks for your ideas and comments.

The idea behind the prefix is to visibly show and ID that the parameter is not OTB and is unique to “us”; and to better visually organize the project parameters dialogue. If the groups from the shared parameters dialogue were visible I think I would reconsider this more.

I do like the idea of recycling parameters and now that I read your comments I can see some potential error in my thinking. The trouble I am having with this though is deciding what way to organize groups by "function" as you say. Do you have an example of this?

[Alfredo Medina]

Alfredo:... Do you have an example of this?

The idea about recycling is based on the fact that a shared parameter is not related to anything in particular. Therefore, the same parameter definition can be used multiple times, in multiple projects, in multiple categories. What creates the difference? The project parameter that you create based on the shared parameter, which must be assigned to a certain category.

For example: assume you have a group called "Dimensions" (this is what I meant by 'function'). In this Group, I can have generic parameters such as "Object_Width", "Object_Height", etc.. Another group or function can be "Identity Data", where I can have something like "ID #", "Product ID", etc. Now, think of all the objects whose properties you could schedule with parameters like those : many elements in many categories at the same time. I can schedule instance lengths and widths of model families, you name it. All I have to do is assign these parameters to the categories I need, and then I will be able to include them in my schedules, in whatever category I need.

This is also useful when you are in the family editor; you know which parameter you need to pick if you need a shared parameter. There is no risk of confusion, since the parameters are always in different schedules that apply to different things. To make these generic parameters recognizable as "yours" you could add the initials of your company as a prefix.

[jj mac]

The idea about recycling is based on the fact that a shared parameter is not related to anything in particular...

For example: assume you have a group called "Dimensions" (this is what I meant by 'function')...

This is also useful when you are in the family editor; you know which parameter you need to pick if you need a shared parameter. There is no risk of confusion, since the parameters are always in different schedules that apply to different things. To make these generic parameters recognizable as "yours" you could add the initials of your company as a prefix.

I better understand what you meant by function now. I appreciate the explanation too. After reading through your last response I came to realize we actually have a hybrid mix of our two ideas. These are the parameter groups I have set up (so far):

Data
Dimensions (Parameter category with exception to my "rule")
General
Identity Data
Materials and Finishes (Would consider this category as "recyclable" as well)
Other
Text
Title Text

Basically the thinking is to create parameter groups based on Revit's existing parameter categories.

In the dimensions group I have made an exception to my methodology, which follows your explanation of function. I find this especially valuable when creating families.

The prefix tells me (and other users) what a parameter is for. I am finding that a lot of our parameters are "one-off's" and we only use them for one Family category. Others I find, could be used for more than one, but probably do not.

We do have a lot of shared parameters. I have documented all of them in an excel file and it actually exceeds 80 parameters right now. However, based on the way we work, this is very necessary.

Thanks for the all responses to the OP and for all the ideas. Although we all have slightly different approaches, I feel as though we are all on, more or less, the same track. Alfredo or anyone else, if you have any further thoughts please let me know.

Cheers

[USMCBody]

-The Problem
One thing that I bumped into and I don't think I can get around is when you want to use your shared parameter in a formula.... Basically I need a way to tell Revit that X-Axis is a parameter. Some programs you can use the "" to group together things but not Revit...

-The example
I like to say X-Axis, Y-Axis, Z-Axis. The problem here is that when I put it in a formula Revit reads it as 'X (parameter) Minus Axis (parameter)' which is not the case as I do not have either parameters... Just the X-Axis parameter...

-The Solution
until I can find a work around is to stay away from using symbols & letters that will invoke a function....

[twiceroadsfool]

Yeah, you just have to accept never using the minus sign, ot the plus sign. I even avoid underscores, though they dont invoke a function. No harm in calling it "X Axis" or XAxis" except were not used to seeing it that way.

[USMCBody]

True.... I just wish it would sync a little more like all the math classes I've ever taken...

but then again, I still wish the names of just about everything would be more in sync with AutoCAD... I guess I should be happy that at least Copy does something close to the same thing. B-)

[Gadget Man]

... I still wish the names of just about everything would be more in sync with AutoCAD... I guess I should be happy that at least Copy does something close to the same thing. B-)

Why do you presume that ACAD and Revit should do things the same way? After all, these are two totally different programs. One has nothing to do with another, except of their owner and the fact that both are used (among other things) in architectural drawings.

In all honesty, I used to compare Revit with different programs too (especially with CadsoftBuild which has some brilliant tools that Revit can only dream about).

But I learned better, as I started to use other programs with similar functions (e.g. Corel Photo Paint and Adobe Photo Shop) and realised that different programs have simply different methods of achieving similar results.

Just get used to it. There are many ways to "skin the cat". It doesn't mean that they are worst or better - they are simply different...

[USMCBody]

It's funny and I'm sure I'm going to confuse everyone, but I agree with you...

What I'm getting at is, as I'm sure you all know, that when people in general switch from AutoCAD to Revit they lose their minds... I mean they lose their minds so much that they forget some basic principles like.... (I've coordinated for many years in the business and now I can't coordinate myself out of a box) And I'm sure everyone has some similar statement. It looks every bit like culture shock to me.

If anyone has ever lived, not vacationed, overseas for at an extended period of time where the sky, clouds, trees, grass, people, culture, food, and everything all around you is different. That gets to you because all you want to do is to find something familiar to you... I don't care if you love the place or not, it is basically nothing like home. And people tend to lose their minds... sometimes for real.

So, what I'm getting at is that I don't think they could get away from the culture shock all together, but if they could at least make the terminology of the two a little more similar it would help out. Basically it would be nice if they could just make transition easier.

and for god's sake it would have been nice if they had a draftsman involved in the design... And remember the people that made AutoCAD (or refined it at least) were not idiots... They seemed to have a good hold on how people perceive things.. Color has the potential to show a lot of information. Followed in a distant Black and White. (if you can remember the difference between black and white TV’s and color TV’s) (A better more current example is analog TV over the air to digital TV over the air. It is was kind of funny seeing all the makeup and imperfections on the newscasters face...) And yes I do wish we plotted in color. A lot more information could be conveyed, but defiantly more expensive.

In that vain I still wish I could attach colors to line weights like in AutoCAD because for no other reason than to check others drawings at a glance.... Rather than having to click on everything to double check...

Don't get me wrong I like the concept of scaling everything up front in Revit. It was a bit more difficult than it needed to be to figure out what scale everything needed to be.. Text, Lines, Blocks... etc they all did it differently in AutoCAD. Not impossible but easy to mess up, but at least I had a bit of control on everything...

Now I'm going to surprise you again... I do love the concept of Revit. Better coordination between everyone, I think it does improve on something’s… and other things. And in the next 7 years or so I think Revit could surpass AutoCAD in versatility, but so far the transition is so hard for a lot of people... Even the ones that do it 'correctly' and Revit is just now starting to be a good program for mostly everyone, but not all, that can use it... Without being forced into workarounds... (and we all know how stubborn us drafters can be and culture shock doesn't help)

I've said it before in many more words and I'll say it again...

Hand Drafting = Club
AutoCAD = Battle Axe
Revit = Scalpel. (and it could have been a repeater rifle at least)

To sum up my ranting I love Revit, but I wish it was better... Kind of like you wish the best for your children. But then again if I ruled the world there would be a whole different set of problems....

And I'm done for now... Please check your head because I can talk it right off sometimes... There it goes... you better grab it.

[Gadget Man]

Boy! And I thought that I could talk... :lol::beer: