#7 - Actually, I'd like fuzzy handcuffs to go with that padlock...

As if there weren't enough changes in this list 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 why 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. 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. (Yes, I know there is a workaround - this post ins't about a crummy workaround that takes 2 minutes per parameter to execute) 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, aren't we smart enough to do that ourselves...ummm, duh???).

#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...

The beginning...

So, in the "my bad" department I've got a more developed list to start off this branch of Revit Futures than I do for Categories. But since I've got it...

The family editor in Revit is the single most powerful interface with the Revit database (Think continuum transfunctioner in Dude Where's My Car). 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 posts are meant to describe a series of changes that would really take the family editor to a "whole 'nother Level", as described on SNL...