The family editor in Revit is the single most powerful interface with the Revit database.

By mastering content creation and building a library for your firm, you can single handedly make the difference between the success and failure of an implementation. But, as they say, with great power comes great responsibility. As the most critical tool, we need Autodesk to focus a lot of development on the editor to continue to improve it. It would be one thing if it were perfect, but that is far from the case. There are numerous usability issues for content creators, even more user interface issues for the end users of the content, and - yes - even more restrictions on what you can actually program into the families as a content creator. The following list is meant to describe a series of changes that would really take the family editor to a "whole 'nother Level", as described on SNL:

1. 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. For some other 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. Having used this workaround on 10+ projects, I can say without a doubt that this is a must-have feature for our designers. 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.

2. Family Types? Where are my family Types? 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. 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 break up a complex problem and breaking it up into interchangeable parts. Now, 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. 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" or dare I say "evil"? 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!).

3. What are 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 recreate 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. 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.

4. What kind of an array are you? Arrays are really powerful 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. 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 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, that's what you do. 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? That's why #4 is type-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). What's even more confusing is that the Family Type parameter that controls these derives it's 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 As??? 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.

7. Parameter Ranges and Constraints, and no you don't get your 1 phone call Mr.
"Width". As if that weren't enough changes to the family types dialog, here's another one. I want to lock a parameter to a certain value range. No, I don't want to "lock" it to a specific value. I never understood what that was a cool addition to the massing editor since you could always lock a parameter by entering a fixed value in the formula field (ok, there are some parameters you can't enter a formula for, so this was to make it so you could lock all parameters. I know, consistency is good right? Yes, so let me type a formula for all parameters instead of giving me a freakin' toggle lock as an added "feature"). However, since we've gone to all the trouble to create a lock toggle, let's

change that to be a constraint toggle. If picked, I can then "constrain" the parameter in addition to the formula field. Using this feature, I could tell a number parameter controlling an array never to go below 2! Or, I could make a family type parameter only display shared parameters that begin with the word "Panel" so my bloody panel: type parameter will stop showing me frame types as if I could even pick one without trashing the family. Or, I could make that standby "Zero" parameter = 0. Yes, I know, for some of these you can create a second duplicate parameter, have it control the geometry, write a conditional statement for it making it equal the first parameter as long as that first parameter meets the range conditions desired, and then call it a day. Of course, when they change that to 1 the family doesn't break it just doesn't do what they expect. Oh, and you've got twice the parameters you really need. Oh, and editing it is confusing as well. You get the point. #7 is constraint ranges for parameter values. Giving us this (along with conditional formatting if these ranges are violated) let's us better control user input and communicate what's wrong with their input! Of course, with rules come rule breakers and (gasp) error messages - see #10...

8. Get rid of those Pesky Love Handles in only 15 minutes a week... Don't you just love
handles? It's fantastic when you load a family in, place it, need to stretch it, and they just work. But OH is it frustrating when they don't! We really need to have some control over which parameters get handles and which don't. I know, type parameters don't get handles. But what if I've got an instance parameter but I really don't want it to have a handle? (Give it a formula, make it type anyway, ignore it). I've got some families with 15 instance dimensional parameters. 15!. I want to control all but two of them using the align tool in the project. Just the overall width and length need a handle. Instead, I've got 30 handles cluttering up my screen every time I select the family (one for each end!). Worse, some of them overlap and I can't even figure out which I'm picking until I move it. Why can't we specify which instance parameters get a handle and which don't? This would make placing and editing complex families much simpler! So, #8 is a way to define where I've got a handle and where I don't. If only my workouts could be simplified like this...

9. I walk the Line... Line based families rock. Truly. But why do we need a separate
template to create one? Why can't you just say: "Revit, I want the length parameter to be the variable of a line-based input method." I've heard two great suggestions to do this. The first was to let us check "line based" in the Family Category and Parameters dialog and then pick the parameter it should use. The second was to do that but have the parameter you pick be the default. In the project, when placing such a family you could modify in the options bar which parameter it would use (obviously it would only display instance length parameters that aren't controlled by a formula) or uncheck a box and just place it using the default instance value from the family. Aside from letting us switch easily from one entry method to another without creating a new family from scratch, and giving the user more control over his placement method; this also opens up the ability integrate angle-based or radius based or any-other based elements we could dream up (and convince Autodesk to program). I'd love to be able to create a radial array formula for chairs in an auditorium and pick the radius to place it on instead of having to place the family and manually adjust it. Once again, this would give advanced family editors to streamline the UI side of placing and editing a family to meet end user's needs. That's why #9 is all about letting us choose to flip a line-based switch instead of having to start from a template with a reference line and a dimension (like we aren't smart enough to do that ourselves???).

10. Internal Error, does not compute. I can't believe I'm asking for this, but it's only fair. As
much as I gripe about the bogus errors in Revit it is only fitting that I should be able to create some bogus errors of my own. Of course, I still have some griping to do. Nothing is as frustrating as breaking a family in Revit. The errors are pretty much summed up by "Failed to apply family parameters". Why? What parameter? Who am I? The errors within

the family editor need to get much better at helping the family creator figure out what when wrong and fixing it. "Did not work" just isn't cutting it. The flip side, of course, is the end user's interaction with the family on the project side. Just like Autodesk needs to make its errors more useful in the editor environment, we content creators need to be able to provide some feedback to our users about why their values didn't work. How else are we going to bring Johnny 5 back alive??? So, to tie in with creating ranges for a parameter that are acceptable, we need to be able to create an error that tells them why they can't apply those values they just input into the family. Of course, this can apply to parameters that don't have value ranges locked in too. There are all sorts of reasons why a family breaks, and I'd like to have some input as a content creator over what error the end user sees when it happens. This one is way out there, I know. I have no clue how you could implement it for that matter, and that's why #10 on the list is letting the content creators write error messages for their families failures. It isn't that it is the least important... That's right, we just took 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, 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...