Friday, September 17, 2010
A Whole ........ 'nother ........ Level!
That's right, this is my recipe to take families to a "whole 'nother Level!" Just because we aren't software developers, don't know C++ or .NET, and pretend to but don't really understand those t-shirts with binary jokes or clocks that tell time in binary; doesn't mean we can't or don't need to create content that is as professional and foolproof as the wizards we've got in Revit already for things like walls. While I don't think we can expect to be able to create a custom GUI like the wall preview or wall structure editor dialog, I do think we can expect to create things as complicated and as reliable. But, to meet those expectations we need the things above, and probably some other things as well. Some that almost made the list are a Parameter Manager app/menu, Copy Parameter from/to nested/host families, the infamous Family Flexor (THANK YOU to someone who posted a link to a Type flexor add-in. If ONLY it did instances), and many more... Please add your own top 10 lists, or cue up the critics and lets knock some holes in the ones I've put down...
#1 - System Family Categories anyone?
As we all know, you can only create real families (.rfa files) for certain categories in Revit. Users are restricted from creating family files for any of the model system families (Walls, Roofs, Floors, Ceilings, Sweeps, Stairs, Rails, Ramps, etc...) as well as the annotation system families (View Titles, Sections, Levels, Elevations, Callouts, etc...). For some of these, you're able to create what are effectively families to nest into the system families. Profile families for sweeps and View Title annotations are an example of a model and an annotation family where you customize the nested family, load it into the project, and then tell the "real" family to use this one vs. that one using a Family Type parameter cleverly disguised as something else.
For some families (Walls, Roofs, Floors, Ceilings, etc...), you can create "custom" versions "In-place" which then imposes some serious limitations on re-use of that family inside and outside the project file. For all these families we have "wizards" to allow you to create "customized" versions within a set of predefined rules. Some of these basically let you pick line and text formatting options and a family type to nest in a profile family or an annotation family. Others are more complicated and include graphical previews and tons of options (The stair tool or the Wall Types dialog for instance), The problem with all these is that if you as a designer want to do something the wizards who made the wizard didn't anticipate, you're SOL.
There is an unsupported pressure valve if you're willing to risk it. Those categories which allow you to make an in-place family can be exported through the save group as file function and renamed to .RFA to create a family file for those categories. Of course, this doesn't even cover 1/2 of the locked categories so it is only so useful. Did I mention that it is TOTALLY unsupported. How unsupported? Try opening the family categories and parameters dialog in one of the hacked RFA files and watch revit hard crash. It's a neat parlor trick over at the Q/A table at Autodesk, really... Also, good luck hosting a family with a void or opening to cut the host (author winces in anticipation). But, other than those "minor" downsides...
Having used this workaround on 10+ projects, I can say without a doubt that this is a must-have feature for our designers and contractors. It can make or break an integrated team's ability to provide downstream data in the right category for estimating, coordination, scheduling, etc...
So, #1 on this list is the ability to create a family of ANY category from the family editors (model and annotation) without exception. We are past the point where wizards can do the work for us, it is time to get our hands dirty!
For some families (Walls, Roofs, Floors, Ceilings, etc...), you can create "custom" versions "In-place" which then imposes some serious limitations on re-use of that family inside and outside the project file. For all these families we have "wizards" to allow you to create "customized" versions within a set of predefined rules. Some of these basically let you pick line and text formatting options and a family type to nest in a profile family or an annotation family. Others are more complicated and include graphical previews and tons of options (The stair tool or the Wall Types dialog for instance), The problem with all these is that if you as a designer want to do something the wizards who made the wizard didn't anticipate, you're SOL.
There is an unsupported pressure valve if you're willing to risk it. Those categories which allow you to make an in-place family can be exported through the save group as file function and renamed to .RFA to create a family file for those categories. Of course, this doesn't even cover 1/2 of the locked categories so it is only so useful. Did I mention that it is TOTALLY unsupported. How unsupported? Try opening the family categories and parameters dialog in one of the hacked RFA files and watch revit hard crash. It's a neat parlor trick over at the Q/A table at Autodesk, really... Also, good luck hosting a family with a void or opening to cut the host (author winces in anticipation). But, other than those "minor" downsides...
Having used this workaround on 10+ projects, I can say without a doubt that this is a must-have feature for our designers and contractors. It can make or break an integrated team's ability to provide downstream data in the right category for estimating, coordination, scheduling, etc...
So, #1 on this list is the ability to create a family of ANY category from the family editors (model and annotation) without exception. We are past the point where wizards can do the work for us, it is time to get our hands dirty!
#2 - I want my Freaking Family Types with Freaking laser beams on their heads allright?
Family Type parameters are the most powerful, and the most restricted type of parameter in Revit. You can't nest them, you can't add them into a family if you haven't already loaded in a family of matching category, you can't control it with a formula, and you can't easily control what they select from or the order that list is in. That's right, turn that lock and throw away the key...
The big issue is the nesting part. The whole point of nesting families is to simplify family creation by taking a complex problem and breaking it up into parts. The whole point of a Family Type parameter is to allow you to take a complex problem and break it up into interchangeable parts. Hmmm. Right hand, meet left hand - now play nice.
But, with all those restrictions what happens if it makes sense to have the FT parameters 2 or 3 levels deep? Well, you have to make that level shared and have to make the FT parameter a Type parameter so you can access it by clicking on the nested family instead of the host. Hold the press... What?
You need it to be an instance parameter? SOL. You need to have it in the host family for scheduling? SOL. Want to control it with a formula? SOL. Anyone want to play Dr. Evil and make a sound every time I want to do something "creative" with a family type parameter? Zip it... Zip it good.
So, #2 on the list is letting us nest those family type parameters several levels deep and tie them to family type parameters in the host families (or control them with a conditional formula, or something!). This takes the meanest parameter on the block an unleashes it on the unsuspecting masses. As for those other problems I mentioned earlier? Those could be resolved by another number on this list...
The big issue is the nesting part. The whole point of nesting families is to simplify family creation by taking a complex problem and breaking it up into parts. The whole point of a Family Type parameter is to allow you to take a complex problem and break it up into interchangeable parts. Hmmm. Right hand, meet left hand - now play nice.
But, with all those restrictions what happens if it makes sense to have the FT parameters 2 or 3 levels deep? Well, you have to make that level shared and have to make the FT parameter a Type parameter so you can access it by clicking on the nested family instead of the host. Hold the press... What?
You need it to be an instance parameter? SOL. You need to have it in the host family for scheduling? SOL. Want to control it with a formula? SOL. Anyone want to play Dr. Evil and make a sound every time I want to do something "creative" with a family type parameter? Zip it... Zip it good.
So, #2 on the list is letting us nest those family type parameters several levels deep and tie them to family type parameters in the host families (or control them with a conditional formula, or something!). This takes the meanest parameter on the block an unleashes it on the unsuspecting masses. As for those other problems I mentioned earlier? Those could be resolved by another number on this list...
#3 - Tell me about your values...
I'm sure we've all been there, that one parameter we have to have in both the host and the nested family, but for some reason the value is being driven by the nested family and not the host. Oh well, tough luck. Re-design your family, or re-create the conditions in the host family (regardless of whether they're needed there) or just drop the whole nested family to begin with and make it all in the same family.
What? Did you say reporting parameter? Buah ha ha hahah ahahahahaaaa... Sorry. Those only work on geometric constraints, can't be used to determine the value of some parameter types, can't be used on a host, can't be...you get the picture. Reporting parameters ala 2011 are like a neutered/spayed dog - no good for families - oh snap! This is a much broader implementation of "reporting parameters" that I'm talking about. Much more like a database query than a dimensional gag gift.
Need a better example? Let's pretend you've got a shared nested panel family in your door family. Let's say that in that shared nested family you've got some type parameters (can't be controlled by the host!) that govern the lite size or the hardware or something else. What, you need to schedule that parameter in the door schedule which only shows the host families? SOL.
This is an example without a workaround that doesn't compromise the functionality of the family. There are tons of examples with complicated workarounds that at least work, but add difficulty and confusion to the family creation process. That's why #3 is the ability to create a parameter in the host family that instead of controlling a parameter in a nested family is controlled BY a parameter in the nested family. No exceptions to what formulas or parameter values it can be used in, etc... This needs to just work.
What? Did you say reporting parameter? Buah ha ha hahah ahahahahaaaa... Sorry. Those only work on geometric constraints, can't be used to determine the value of some parameter types, can't be used on a host, can't be...you get the picture. Reporting parameters ala 2011 are like a neutered/spayed dog - no good for families - oh snap! This is a much broader implementation of "reporting parameters" that I'm talking about. Much more like a database query than a dimensional gag gift.
Need a better example? Let's pretend you've got a shared nested panel family in your door family. Let's say that in that shared nested family you've got some type parameters (can't be controlled by the host!) that govern the lite size or the hardware or something else. What, you need to schedule that parameter in the door schedule which only shows the host families? SOL.
This is an example without a workaround that doesn't compromise the functionality of the family. There are tons of examples with complicated workarounds that at least work, but add difficulty and confusion to the family creation process. That's why #3 is the ability to create a parameter in the host family that instead of controlling a parameter in a nested family is controlled BY a parameter in the nested family. No exceptions to what formulas or parameter values it can be used in, etc... This needs to just work.
#4 - What kind of an array are you?
Arrays are really nice but have two MAJOR flaws in Revit. The first and most frequently discussed is that they can't have a value of "1". I'm not putting this on my list because I think everyone knows that needs a "solution". Suffice it to say, we need some way to enter the spacing and the vector of the array without having to have the second member populated. (Oh, and while you're at it fix that pesky radial array requiring 4 families nonsense too...) That makes baby Jesus cry...
The second flaw is the fact that the arrayed elements have to be exactly identical. I know, you're thinking: "That's not a flaw, that's the point!". Oh, I beg to differ! The point of an array is to define a repeating pattern of elements, nothing more and nothing less. What I want, when defining an array, its to tell it if I'm making an array of an instance of a family (implying all elements will be identical) or of the type of that family (implying that within the array instances elements could vary their instance values). Why, you ask? Well, whether it is an array of chairs around a table or structural members in an auditorium what do you when one of those elements needs to be slightly different? You blow your array to smithereens Terminator style, that's what you do. (Hasta la vista, baby...) Why should we have to? They're all still basically the same. They're all still chairs around a table but I want the 1st and 4th to be high back chairs? Or perhaps I want the top two beams to be 5 inches longer to engage with a steel beam instead of the tilt-panel the rest meet up with. Why should I loose the parametric behavior of the array?
This is a CRITICAL way to greatly expand the power of content creators to meet the demands of their end users. That's why #4 is differentiating between type-based and instance-based arrays.
The second flaw is the fact that the arrayed elements have to be exactly identical. I know, you're thinking: "That's not a flaw, that's the point!". Oh, I beg to differ! The point of an array is to define a repeating pattern of elements, nothing more and nothing less. What I want, when defining an array, its to tell it if I'm making an array of an instance of a family (implying all elements will be identical) or of the type of that family (implying that within the array instances elements could vary their instance values). Why, you ask? Well, whether it is an array of chairs around a table or structural members in an auditorium what do you when one of those elements needs to be slightly different? You blow your array to smithereens Terminator style, that's what you do. (Hasta la vista, baby...) Why should we have to? They're all still basically the same. They're all still chairs around a table but I want the 1st and 4th to be high back chairs? Or perhaps I want the top two beams to be 5 inches longer to engage with a steel beam instead of the tilt-panel the rest meet up with. Why should I loose the parametric behavior of the array?
This is a CRITICAL way to greatly expand the power of content creators to meet the demands of their end users. That's why #4 is differentiating between type-based and instance-based arrays.
#5 - To Share or not to Share, that is the question...
In this case, I'm referring sharing families, not parameters. The problem with sharing a family is that it has so many consequences. It doesn't just allow you to pick from families in the project using a family type parameter. It also makes the families type parameters uncontrollable by the host family, and causes the nested families to show up in schedules and tag upon placement (if that option is turned on). Oh, and once you share you can't go back without a royal PITA. So, you better pray you want all, or none.
Obviously, this causes conflicts. I'd prefer have a checkbox for each in the family category and parameters dialog. So, I can have it "shared" so that it can be loaded into a host family from a project file. But, I don't have to schedule it or have it tag. Now, when my nested panel family is placed by association with its host door family, I won't get two tags in the floor plan and I won't have to set up a filter in the door schedule just to hide the 157 panel families that came in with my 126 door families (I can count - some of them are double doors and have two panels, so there). Or, what if I want it to only pick from what I load in the family but DO want it to schedule or tag. Or so I can tie Type parameters to parameters in the host family but still get tagging, scheduling, and loading...
What's even more confusing is that the Family Type parameter that controls these derives its shared/non-shared nature from the first family you load when you create it or the first family assigned to it. Shouldn't that be a property of the parameter not of the family? This is why #5 is to re-work shared families and let users control the various different behaviors in the model individually instead of the all-or-nothing we've currently got!
Obviously, this causes conflicts. I'd prefer have a checkbox for each in the family category and parameters dialog. So, I can have it "shared" so that it can be loaded into a host family from a project file. But, I don't have to schedule it or have it tag. Now, when my nested panel family is placed by association with its host door family, I won't get two tags in the floor plan and I won't have to set up a filter in the door schedule just to hide the 157 panel families that came in with my 126 door families (I can count - some of them are double doors and have two panels, so there). Or, what if I want it to only pick from what I load in the family but DO want it to schedule or tag. Or so I can tie Type parameters to parameters in the host family but still get tagging, scheduling, and loading...
What's even more confusing is that the Family Type parameter that controls these derives its shared/non-shared nature from the first family you load when you create it or the first family assigned to it. Shouldn't that be a property of the parameter not of the family? This is why #5 is to re-work shared families and let users control the various different behaviors in the model individually instead of the all-or-nothing we've currently got!
#6 - Simply Not Conditional...
So, we all know the PITA of having your parameters grouped in the family categories in the family editor. There are all sorts of tricky ways to get them in the order you want, but it takes 10 times longer than not worrying about it - so I don't. Unfortunately, this confuses the hell out of end users. Really. Nothing like hunting for a parameter in what appears to be an inverse alphabetical list but that one you want that starts with an F is at the bottom between to A's???
And don't you love how to change the name of a family parameter you have to enter a modify dialog box instead of just typing in the one you're already in?
What about parameters where only certain value ranges are acceptable, wouldn't it be awesome if they'd change color if they were out of range? I could set a ramp slope calculation parameter to highlight in Red if the input caused it to exceed 1/12!
Of course, then there are those parameters that should be grayed out because they're determined by a formula - but since that formula doesn't involve another parameter or complex math Revit chooses to leave it black and let people enter stuff for it anyway?
And then there are the parameter categories themselves. The mere fact that there is an "Other" category is testimony to the fact that the available ones aren't cutting it. And then there is the order of the categories. It is pseudo-alphabetical but sometime of them get special billing in certain situations and flip out of order for god only knows why.
This is the joy that is family creation and parameter management. I should be able to rename family parameters on the fly. Drag and drop the parameters to change their order, or to change them from one family category to another. I should be able to make a parameter or it's value Bold, Underlined, Italic, and any color of the rainbow or the pantone color chart I so please (ok, pantone might be excessive). I should be able to create additional family categories just like I can create object subcategories, and arrange them how I see fit. I should have basic sorting capabilities in the headers for those categories so I can sort the parameters by Alpha or inverse Aplha, and should probably be able to auto-sort the family categories as well - and these settings need to stick in the project not change willy-nilly. I should be able to hide parameters from users in the project type and instance dialogs so they don't get confused by a parameter they can't edit and is only there because for some idiotic reason I can't get a Yes/No parameter to say "A" when its a yes and "G" when it's a no so I have to create another parameter to schedule correctly. While I'm on that one I should be able to control how certain parameters schedule somewhere - I'd prefer that control in the schedule and tag families but if you want to give it to me here, I'm good with that. I should be able to drag a parameter into a formula field rather than having to type it exactly or type in a dummy value, switch to the parameter I want, select the name, copy to clipboard, go back to the formula field, delete the dummy and then paste what I wanted in the first place. Who's the dummy now? (Me). I want to be able to give conditional formatting for parameters as well. if(parameter < 2, "Red" "Bold" "Scream like a banshee", "default"). Ok, I don't need sound effects but you have to admit it would be cool. I know I'm asking for a COMPLETE overhaul of the UI in the family types dialog, but as families get more complex and more users start using them the ability of the family creator to clearly communicate the intent of the various parameters and guide the users to the right decisions becomes critical. This overhaul is non-negotiable and simply is not conditional. We need this one bad! This is why #6 is giving us FULL formatting and conditional formatting controls in the family types dialog in the family editor - this would be so fine there's no telling where the money went...
And don't you love how to change the name of a family parameter you have to enter a modify dialog box instead of just typing in the one you're already in?
What about parameters where only certain value ranges are acceptable, wouldn't it be awesome if they'd change color if they were out of range? I could set a ramp slope calculation parameter to highlight in Red if the input caused it to exceed 1/12!
Of course, then there are those parameters that should be grayed out because they're determined by a formula - but since that formula doesn't involve another parameter or complex math Revit chooses to leave it black and let people enter stuff for it anyway?
And then there are the parameter categories themselves. The mere fact that there is an "Other" category is testimony to the fact that the available ones aren't cutting it. And then there is the order of the categories. It is pseudo-alphabetical but sometime of them get special billing in certain situations and flip out of order for god only knows why.
This is the joy that is family creation and parameter management. I should be able to rename family parameters on the fly. Drag and drop the parameters to change their order, or to change them from one family category to another. I should be able to make a parameter or it's value Bold, Underlined, Italic, and any color of the rainbow or the pantone color chart I so please (ok, pantone might be excessive). I should be able to create additional family categories just like I can create object subcategories, and arrange them how I see fit. I should have basic sorting capabilities in the headers for those categories so I can sort the parameters by Alpha or inverse Aplha, and should probably be able to auto-sort the family categories as well - and these settings need to stick in the project not change willy-nilly. I should be able to hide parameters from users in the project type and instance dialogs so they don't get confused by a parameter they can't edit and is only there because for some idiotic reason I can't get a Yes/No parameter to say "A" when its a yes and "G" when it's a no so I have to create another parameter to schedule correctly. While I'm on that one I should be able to control how certain parameters schedule somewhere - I'd prefer that control in the schedule and tag families but if you want to give it to me here, I'm good with that. I should be able to drag a parameter into a formula field rather than having to type it exactly or type in a dummy value, switch to the parameter I want, select the name, copy to clipboard, go back to the formula field, delete the dummy and then paste what I wanted in the first place. Who's the dummy now? (Me). I want to be able to give conditional formatting for parameters as well. if(parameter < 2, "Red" "Bold" "Scream like a banshee", "default"). Ok, I don't need sound effects but you have to admit it would be cool. I know I'm asking for a COMPLETE overhaul of the UI in the family types dialog, but as families get more complex and more users start using them the ability of the family creator to clearly communicate the intent of the various parameters and guide the users to the right decisions becomes critical. This overhaul is non-negotiable and simply is not conditional. We need this one bad! This is why #6 is giving us FULL formatting and conditional formatting controls in the family types dialog in the family editor - this would be so fine there's no telling where the money went...
Subscribe to:
Posts (Atom)