Adding Categories

Adding Categories - we didn't discuss it in class, but the consensus on AUGI is no consensus. There are ardent believers in allowing it, and ardent believers in leaving it alone... I'm going to try and find an official list of all the classes (categories) IFC lists as an example, but no luck yet. I'm a big fan of adding a discrete set of user requested categories based on a petition process or something like that. I don't think a free for all is warranted, but I also don't think never adding a category is a good solution either. My two cents...

Families / Types / Instances

The issue here is where does the "category" property reside? Does it remain at the family level as it does now resulting in duplicated families (and duplicated updates, etc...) or does it reside at the Type level allowing a single family to have types in multiple categories. This means we have a single family to update with changes. No one thought the category residing at the instance level made any sense. This would allow instance level overrides of categories and that just sounded too unruly to everyone...

Switching Categories

Switching categories wasn't covered directly, but we discussed it in the modeling tools section since it was pretty critical to achieving the second modeling option (model first, assign categories later). No one raised any major objections to this. Execution wasn't discussed in detail, but basically we talked about the category-ness parameters being removed and the new category-ness parameters being assigned. All other parameters are unchanged. There's more to discuss, but that's the skinny...

Modeling Tools

Modeling tools were perhaps the most contentious discussion. Most people agreed that the modeling tool and the category weren't related, however the execution of this in the project environment brought out some vehement disagreement. Mainly, this revolved around whether or not to have a "Second" way of modeling that was category neutral allowing assignment of categories after modeling was completed. Should these objects go into generic models? Should it have a null value and be unscheduleable and unexportable, etc...

Hosting

For Hosting we also agreed what we have is insufficient. I think we all agreed on the goals, but we didn't get into a deep discussion on a solution. Darn time...

Visibility

So, Visibility issues abound. We had great consensus that this isn't how things should work. However, we did have a few issues agreeing on how exactly it was best resolved...

Publish Post

Problems

Begin with the beginning! Here are the list of issues as stated at the beginning of the class. If you've got anything to add, comment away!

The Class

So, the class went great! (or at least I thought so...) I suppose we'll see with the surveys. Please fill them out if you were in the class.

We had a full house with 40+ people all told in attendance including many people who weren't registered (naughty!) but the conversation was just better for the additional ideas. Thanks to everyone who came and participated and PLEASE post on the blog. I'd love to get a ton of comments to prove to the factory how important this really is.

All the material is now successfully on the AU site, and for those of you not registered it should become available after AU, or you can download it here

Graphic Display by Category? Really?

Yet another example of categories being used to hard code non-category specific behavior is how they are cut in views. Basically, Autodesk has decided for us that lighting fixtures don't cut in section views. If it is a curved fixture and it obscures a bunch of other stuff, too bad. You have to hide it, and manually draw the section cut in. Can we say yuck?

I do understand that part of the point  in having the category control object display is consistency, and I'm not really suggesting we change that. Some have suggested it be managed at the family level, not the category level. I disagree though. All I think we need to fix this is end user control over ALL the currently hard-coded display settings for categories. I just want a checkbox in Object Styles to control whether a category cuts in section, or whether view depth clip works, etc... Here's why:

And there isn't anything we can do about this currently...

Family : Type : Instance

Changing categories of placed "system" families is of course going to cause a problem with the whole Family:Type:Instance paradigm. Right now, the System Family IS the Wall Layered Construction tool.


However, I do think the family/type/instance relationship should be maintained. What I'm proposing is that the part of the system family that corresponds to "Family" which is the "layered construction family" would now be allowed to be multiple categories. So, if I change the category of one instance, I'm actually changing the category of all instances of that type, and if it isn't already there I'm also creating a Family in the new category called "Layered Construction". This would also apply to creating families. So, when someone picked door and then grabbed the "layered construction" tool instead of place component, it would basically create a family in the door category called "Basic Layered Door" or something and then create a type under it for what you're modeling at the moment.


Of course, based on that last example the clear suggestion is that the Layered Construction family can be used to create ANY category, and similarly use can use a "component family" for any category as well. I think this is also critical because, frankly, there are walls that are neither layered nor panelized nor path arrays (railing tool). Those we need the flexibility of custom component families to create but we still need the "wallness".


I think you could make a pretty good argument for having the category be a property of the type and not the family on a program wide scope, but that would entail re-organizing the project browser (from a UI perspective) and I don't think it is critical to do so for this to be effective. People can always "duplicate" the family and change its category to get a new type in a new category. But that can be a discussion for AU.

Categories, not Modeling Tools

So, IF we reinvent hosting, I'd say that we can then make some serious changes in how categories are assigned...

Rather than have it assigned by the modeling tool chosen as if there is some inherent relationship between the two, have it be chosen either prior to selecting a modeling tool or after the modeling operation is completed (and allow no choice to be made). 

I would imagine two different ribbon panels for these two different workflows. One would look much like what we've got today (minus architectural columns because if you uncheck "structural" in a regular column, guess what, it is architectural!, and some of the other redundant tools in there). Then, in the draw wall mode you basically get a bunch of modeling options in the ribbon just like you do now when you enter sketch mode - line, ellipse, circle, spline, etc... - except this time you get path (should support 3D paths), profile, face, panelized, etc... Pick one and your drawing mode changes appropriately, and it should default to whatever you used last probably. Same thing for floors, ceilings, roofs, etc... You set the category and then choose the modeling tool that best fits your intent. Alternatively, there should be a tab that gives you the layered construction, panelized construction, swept construction (railings anyone?) tools and when you finish the category is basically unset (a real reason for a generic model category) and it can be set later. This effectively gets rid of a lot of redundant tools like Curtain Wall / Curtain System.

The point here is that we can choose smart modeling tools that allow us to achieve both peak efficiency and modeling accuracy, AND have the end result be in the correct category...

This is crucial to achieving data consistency downstream.

The separation of categories from geometric tools also allows us to potentially change the category and the modeling independently. So, if we switch from a panelized wall to a layered one, instead of deleting it we can just change it and retain both the element ID and any wall meta-data already stored in that wall at the instance level. Or, we could realize this is no longer a roof but a ceiling, and we can switch the category and get all the ceiling meta data parameters without loosing the Element ID or the geometry we created. And, since we reinvented hosting and removed it from the category realm, we can do all this without loosing hosting associations.

Ahhhh, Nirvana...

Hosting...

Another problem we have with categories overlapping with non-category like behaviors is Hosting. Just like the geometric tools are defined by the category (despite reality), hosting is also defined by category (despite reality). I'll give you an example an Autodesk employee threw my way...

We were discussing the whole category thing, and I was making the point that we should be able to select something modeled on the wrong category (ceiling modeled as a roof for instance) and switch it to the right category (ceiling). He then came back and said it might make sense for system families, but it made no sense to switch between say a door and a wall. Naturally, I disagreed. My counter example? What about a concealed door that is really a hinged wall? It might be constructed more or less the same way the adjacent walls are but it has additional door like hardware to allow it to be opened and closed, and needs to show up in the door schedule and tag like a door. But, we need to host a blackboard or a white board or something on it like a wall. My intrepid collegue's response was to let us assign multiple categories to one object. I'm not into multiple personality disorder, so I think that is a bad idea! Take a wall and "add" door properties and behavior to it. Yuck, but it would work with the current structure. 

Of course, the category / modeling thing is part of the problem. But, hosting is the part that makes us not want to make it a door. If we do, we now have to make a face-based whiteboard family to go along with our wall hosted one, to go along with our unhosted one, etc... Hosting is just as much of a problem as associating geometry decisions to categories. In "reality" I can take screws, construction adhesive, and other "fastening devices" such as pookie and chewing gum, and I can "host" some whiteboard just about any where I so please. I don't have to call the manufacturer and order a different "whiteboard" to screw it onto a door vs. a ceiling vs. a door. So, I kind of feel like Revit should oblige me and do the same...

"Hosting" as Revit defines it is frustratingly static master/slave relationship only available between certain categories. Without launching into a Monty Python monologue about the feudal system, lets just say that sucks.

Hosting SHOULD be a way to define a relationship between multiple objects, regardless of category. What's that you say, make a face-based family? What if I want it to cut non-system families consistently? What if I want it to easily be non-hosted? What if I want it to have access to the host parameters to define information about itself? What if I want to relate three things to each other? What if the master / slave breakdown isn't clear? Face-based hosting is a first paltry step in the right direction that immediately causes us to loose another initial step in the right direction called reporting parameters. It isn't the solution...

So, we're going to be diving in to how to solve hosting as well, since it basically muddies the water in the category discussion and leads us down some bad paths otherwise.

Non-category specific behaviors...

So, the first question we should all ask is "what are categories really for?".

I think this is the fundamental root of the "problem" we have right now. Like many tools and features in Revit (worksets anyone?) the actual intent of the tool has been left to pasture and instead it is being using for many additional things it was never intended for.

My position on all this is that categories are simply a tool to assign non-geometric data sets (classes) to objects in an efficient manner. In other words, instead of you and I having to manually associate multiple parameters to objects one by one, we can make something a "wall" and certain parameters and properties are inherited as a result of that choice!

Basically, assigning the "wall" category associates anything that we deem as "wallness" to that element. Sounds good to me? You?

But, what it Autodesk or other users have decided certain things should be included in the "wallness" that you or I think otherwise? This is exactly what has happened with the wall tool. The only supported way to make a wall category object is with the wall tool. This tool not only assigns wall properties, it also creates the geometry using a layered construction assembly wizard. Right? You draw a wall, and as Shrek would say, "it has layers donkey."

But what if we're drawing a panelized wall system? It's assembly type is no longer "layers" but "panels". We can make a panelized construction using the curtain wall or curtain system tools, but we can't call them a "wall" anymore. Same thing goes for ceilings (ACT anyone?). Autodesk (and formerly Revit) have forced our hand and told us "all walls have layers" and "no walls are panelized except glazing". That leaves us with two options: Grossly misuse the tools we are given to correctly model the things we need (use a curtain system for ACT) or grossly misuse our time and attempt to model something panelized using a layered construction tool and adding reveals to it to mimic panels (like a metal panel wall or ACT). You notice I didn't offer "use a surface pattern as an option... Surface patterns don't export to Navisworks or any other 3D coordination tool on the market, which means your panelized system can't get coordinated against properly. I don't think that is an option...

So, that is the real problem with categories in my book. That the program is associating non-wallness things with walls and gives us no supported option to get the needed result (a panelized wall).

Now, some people will say that all that "wallness" that gets associated with the wall category isn't that important. If your models stay in house and never leave, then you're probably right. But you also probably don't care if it gets better. If, on the other hand, your models frequently leave the architectural world and make it over into construction management and fabrication worlds (like ours do); then you probably do care. I can't count the number of times I've had to explain over the phone to a subcontractor, estimator, or project engineer why we modeled ceilings or walls as curtain systems. There is no reason we shouldn't have that modeling (geometry) tool available to make walls, ceilings, roofs, or whatever!

My 2 cents...

Category Manifesto Part 1

So, in light of the selection of "The Future of Revit Categories" for AU2010, I should probably get started with the setup.

Basically, the idea for the series of Revit Futures classes I submitted came from several conversations with the peeps managing the Revit development process. A few of us Revit Geeks got an e-mail chain going that included them and would basically debate what we thought Autodesk should do with some of these key foundations of the program to make it better. During one of these discussions it was suggested to me by one of those guys that I should do this as an unplugged class so it was recorded and could be listened to after the fact at the factory. So, here we are today!

Categories was selected, and I'm not going to read anything into that beyond that it is the principal organizational structure at the heart of the program so why not start there? 

So, what do we have exactly anyway? We have a bunch of "categories" of objects that each have their own special rules they play by. Most behave more or less similarly, but we do have some super-special categories out there...

1. Some categories are so special that we shouldn't see them the same way as other categories... Instead, when we tell the model we want to cut it in half with a section and look at it, these categories don't cut and hide all sorts of useful information behind them! Ugh... 
2. Some categories are "system" categories and only officially allow creation of elements in those categories through Wizards in the project environment. Walls, Curtain Walls, Curtain Systems, Floors, Ceilings, Roofs, Ramps, Stairs, Railings, and anything that uses a profile family are the ones that come to mind in Revit Architecture on the modeling side. On the annotation side this is both less of a big deal (because no one quantifies tags) and more of a problem because basically every annotation is a "system" family to some level - though some are worse than others (like Dimensions!). Once again, anything that has a wizard is basically limiting what you can actually do by definition.
3. Generic Categories! Yes, just in case we didn't create the right category for your object there is a generic one just for you! So, take your pick between generic models and specialty equipment and go to town modeling everything AND the dog in these categories to make up for the inability to model all those system families the way you really want to! These ARE the miscellaneous drawer in your desk where you can never find what you're needing...ever.
4. On a need to know basis categories are those that your wife / consultant doesn't tell you about until the day before a project deadline and 6,000 orange lines show up on all your floor plans out of nowhere because "analytical lines" somehow got magically turned on... Basically, all those categories (and subcategories) that show up when you hit the "show categories from other disciplines" checkbox. Because, really, we don't need to know what those "other disciplines" are doing anyway...right?

So, those are some of the problems with the category system we have currently in Revit. Those, and the inability to create new ones to meet specific needs. So, more to come. I'll try and break down each of those 4 items and give some detailed listings of the different categories and which have these...downsides.

Until next post...