Well I’m happy to report that you can have your cake and eat it too. The above image shows a pipe fitting family (an elbow in this example) that, when used in a project, will get highlighted in red if the angle of the elbow is different than either 45 or 90 (the two angles provided by the manufacturer). Not only that, it will also show you a non-modal dialog warning as you draw. But wait, it gets better! There is no plugin, hack or workaround. This is a built-in feature in Revit. The below video shows this feature in action.

Click here to view the embedded video.

You can achieve this seamless highlighting by means of the IsCustom built-in parameter on the Pipe Fittings Revit family category. When in a project, changing this Yes/No parameter will display a modeless dialog warning like the one shown below. The parameter can be controlled via a formula that draws information from within the project. You can add the colored highlighting by means of additional geometry associated to the IsCustom parameter.

One of our customers has been enjoying a set of fittings created this way and his feedback couldn’t be better. Long pipe runs, where a mistake of a couple degrees on a fitting can end up causing coordination issues, are now easily reviewed and fixed. And if a custom fitting is actually needed, then this can be highlighted and reported.

We are working on a manufacturer-specific set of fittings that all have this feature built in. I’ll write more about it when we release these families and write a follow-up post with step by step instructions on how to create such a family. If you don’t want to wait for the follow-up post, I’ll be at Autodesk University this coming week and would welcome the opportunity to talk with anyone who is interested in implementing this feature in their Revit families.

To spice things up a bit, I took out my not-so-exciting (but very informative) voiceover that I recorded for the AU virtual booth video, and replaced it with a soundtrack timed to the images in the video. So turn up the volume, hit the play button, and let our Revit families help you celebrate the end of the week. Happy Friday!

Click here to view the embedded video.

I recently saw one example of this at the BIM Show Live here in London, where Adam Ward – BIM and Technology Specialist at BIM.Technologies – showed in his presentation a truss family that would ‘glow’ red whenever its length extended past the size at which the manufacturer could build them. I consider this a good example of a warning, or if you want, instructions about the real-world product’s limitations or performance.

Another example would be the below toilet partitions by Bradley. A disclaimer first: I have created hundreds of families for Bradley and the toilet partitions in particular were all created by me. Each of these families has 3D text giving instructions on how to use the family. I have seen and been asked to do this type of built-in instructions in other situations as well. In this case, however, I feel this is the wrong approach for a number of reasons.

First, the text adds weight to the family, to the order of 300K to 600K in this case. While I generally agree with Steve Stafford that, as he so nicely put it, “file size is a red herring” and shouldn’t take priority when evaluating a family, it does certainly count for something, especially when added up across many families. If every manufacturer were to take the same approach that Bradley did for providing instructions to users, we’d have a systemic problem of bloated families that would have a noticeable impact for users.

The instructions text shown also has a visibility setting, and that is where the second problem lies. It’s turned on by default; everyone will see it and have to go and turn it off. The family, if I may say so, isn’t so hard to understand as to warrant constant instructions. Most users will figure it out just by looking at the instance parameters available when in a project. This is penalizing every user out there for the few that are so new to Revit as to need these instructions. Optionally, you can edit the family and delete the text if you don’t want it there. That’s just not user-friendly and definitely not something a new Revit user should be expected to do.

So how else could we go about providing instructions for these families? If the information were made available on the page where the family is downloaded, I believe that would cover almost everyone’s needs. If you still really wanted to have the instructions available from within the family, then you could put links within parameters that would take the user to specs and other bits of information that might be relevant to the family and its related product(s).

Having said this, the approach Bradley took is definitely better than no instructions at all, and I consider it a step in the right direction. They added their text with the best interests of users in mind, and a lot of users might find that the embedded text and visibility setting work perfectly fine for them.

My main concern in this post is to begin exploring the different ways that Revit families can incorporate feedback mechanisms that help guide users in using the families properly within a project. I think this is an important topic for improving the usability of Revit families, especially for manufacturer-specific content. I’ll be following up soon with another post illustrating a feedback mechanism I’ve been working on. In the meantime, I’d love to hear if anyone has other techniques they’ve used or opinions about feedback mechanisms they’ve found in other Revit families.

But going to a conference is ultimately about being there with the other attendees, and we’re especially looking forward to having the chance to meet some of our customers, partners, and friends in person later this month. If you’re attending AU and would like to meet up or just say a quick hello, drop us a comment on this blog post, send an email to contact@andekan.com, @ us on Twitter, or just look out for these guys:

Look out, Jose Fandos has his eye on you! But the conference is just after Thanksgiving, Jose, not Halloween!

Am I drinking guacamole!? These were really just the best close ups I could find.

And while it is all about the human element, we clearly live in the digital age, so I’ll close by mentioning that Andekan will have a virtual booth at this year’s AU. I’m not sure when the virtual booths will go live, but when they do ours will include a video showing some new families, along with plenty of information for anyone looking to learn about us or get in touch.

Good luck to anyone making final preparations for a session or booth, and we hope to see you there.

If you’re reading our blog, then you might be most interested in the long-overdue update to our Sample Downloads page. We added 5 new sample families for you to download and check out, including the Clow reducing wye and Tyler Pipe roof drain shown below. You can see all of the new samples here.

We’re excited to begin offering this wider range of sample downloads, one that reflects both the breadth and depth of our experience creating Revit families. We hope to continue adding families to the page as the months go by, and we’ll be sure to continue announcing those new additions here.

Happy downloading!

Type catalogs, on the other hand, have been getting better, more practical for day-to-day use, and, thanks to an improvement in Revit 2012, easier to deal with than ever. Gone are the days when creating a type catalog was an exercise in self-mutilation. Now you can just open any family in Revit 2012, choose Export -> Family Types and your template type catalog txt file is ready, without any chance of spelling mistakes or incorrect data categories. Sweet!

So what about the built-in family types? What’s wrong with them? I did a little research on the evolution of types in Revit by posting a question in some LinkedIn forums to find out how built-in family types and type catalogs came to be. My feeling was that the built-in types were first and type catalogs came later as a more thought-out solution. Wesley Benn confirmed my suspicions when he wrote, “…family types showed up in version 2‚” while “…Catalog files (then known simply as the family type browser) showed up in version 4.0.” And from the version 4 release notes as posted by Wesley:

Family type browser:

Families now can have types defined in external text files. These files must have the same name as the families itself and reside at the same directory location. When the family is loaded, externally defined types are visible within the “Load Family” dialogue and only those types selected by the user are created in the project. For families with a large number of possible types such as structural shapes, this makes it simpler to manage the type lists in a project.

So there you have it: type catalogs were created as a solution for families with “a large number of possible types.” This points to the one small advantage to built-in family types, which is that they allow you to bring into a project a family and all its related types in one fell swoop. In that sense they are a sort of group, and that’s about it. Everything else about them is a drawback. Say you have a family with built-in types and you don’t want some of the types in your project. Tough luck. After you load it, you’ll have to hunt down the family in the project browser (not an easy task given the current user interface) and remove the unwanted types. If the unnecessary types are left in there, you are wasting space and increasing memory requirements (though I would have to test the latter more thoroughly to be able to make that claim with certainty – if anyone is up to the task and wants to report back, it will be appreciated). And what if you don’t have time to go hunting and instead just leave the extra types in the project? If you’re working on a team, someone less familiar with the types of that particular family might pick the wrong type, and you end up with the wrong information in the project.

It doesn’t end there either. The maximum recommended number of types built within a family is 5. That is, recommended by the Seek guidelines (though not necessarily what users do in practice). With 5 types, updating some parameters for one type and forgetting to update those same parameters for other types is a common mistake. It’s one of the reasons why I always leave the creation of new types until the very end of the family creation process. But even that won’t help if I’m editing an existing family with built-in types. The interface doesn’t make things easy either. If you don’t check for yourself, there is nothing in the family editor to tell you that a family has other types!

In contrast, type catalogs won’t automatically bring in a set of types with just a double click. Instead, when loading a family that has a type catalog, you are able to select only what you need, and even filter through the available family parameters shown in the type catalog. You can repeat the procedure to bring in other types later, when and if you need them. And editing the types or adding types to the family is something that can be done from Excel or a Google Spreadsheet. You don’t even have to know Revit to update a type catalog – think about all the manufacturers who have or will have Revit families and need to keep them updated as their product lines evolve year after year.

Type catalogs feel like the way parameters ought to be managed. It’s easier than ever to create them, and every piece of family management software that I’ve tried or seen works as if type catalogs are the norm, i.e. allowing you to load just the types you need. Yes, there is still room for improvement with type catalogs (worth another post), but built-in family types don’t seem to be going anywhere. Rather they appear to be slowly fading from use in Revit, and that’s fine by me. As far as I’m concerned, they are already dead.

As long as there are competing standards for defining the names and properties of shared parameters, choosing one standard over another is problematic for a manufacturer that wants to facilitate the use of their families as broadly as possible. I believe the solution to this problem is simple: manufacturers shouldn’t add any shared parameters to their families. Instead they should include family parameters for every piece of information most of their users within the AEC industry might want to use within a project.

While I began by saying that there are competing standards for shared parameters, the truth is that calling something a standard does not make it one. And so I will correct myself here and say that there is a lack of standards, competing or otherwise. For something to be a standard, there needs to be an uptake and use of said standard among its intended audience. I personally don’t see evidence of this in my day-to-day work.

Architectural and engineering firms have their own shared parameters that rarely will include any shared parameter from existing published lists, even though the same information might be covered. Whenever I start working on a manufacturer’s project, I usually start by reviewing existing content from similar manufacturers, searching for anything that could be construed as a standard way to put together the families, including shared parameters. Again, rarely do I come across shared parameters from published lists within the manufacturer content I review.

Any shared parameter that exists in a family but not in the scope of a project’s output, i.e. in a schedule, is of little benefit. And the little benefit that it has gets squashed by the current implementation of schedules within Revit. Although it might be the case that information provided by a shared parameter is pulled out of the project without touching any particular schedule, I will err on the side of that being a much less frequent practice, and add that even in that situation other scheduling done within the project will still be negatively affected by unnecessary shared parameters. Let’s take a look at a couple cases in point.

I recently finished a batch of Tyler Pipe families. These were mainly floor drains, and there are two types of information that you can apparently use for drainage calculations. On the one hand you can use fixture units for the drain, and on the other hand you can use the flow rate and free area. I would imagine that whichever option is used within a company comes down to the preference of their plumbing engineers. Having all three pieces of information as shared parameters only serves to muddy the waters for everyone. The parameter(s) not being used will always appear in the dialog boxes for creating schedules. And if the family has the connector set to use the flow rate parameter rather than the fixture units one, choosing the latter for your schedule will still require editing the family to change the association (in this case to change the Flow Configuration parameter in the connector).

Below is an image from another piping manufacturer. The family has 6 parameters added to those that were originally part of the template, and all 6 have been set as shared parameters. It’s hard to see the point of this, especially since these parameters don’t seem to hold any valuable information for the plumbing engineer.

If you try to schedule any information out of your project with that family inside, you will have to see those parameters. The two images below show the Schedule Properties dialog box when trying to create a Multi-Category schedule in a project. The first shows the dialog box for an empty project, and the second for a project that includes this piping manufacturer’s family. Just one manufacturer family added to our project, and we now have 6 extra parameters to sort through, spelling mistakes included.

If manufacturers refrain from setting any parameters within their families as shared, and yet those parameters are still included with the right information in them, then all it takes is a quick edit by those adding families to a project or company library to get all of the relevant data into their corresponding schedules. The only thing for the manufacturer to decide is the name of the family parameters. And here is where looking at current lists of published shared parameters comes in. The manufacturers should try to use common names from published lists whenever possible and appropriate. It facilitates the job of turning that parameter into a shared one by the architect or engineer, and it doesn’t require learning any manufacturer-specific nomenclature.

In short, I see no benefit to manufacturers defining shared parameters in their families, whether using published lists or their own criteria, but would encourage manufacturers to look at published lists for guidance on how to name their family parameters.

The Knauf Walls pack covers 98 manufacturer-specific wall styles, each with relevant 2D details, materials and textures. Since walls are system families within Revit, Paul took the approach of grouping the families for each wall style and saving them as a Revit project. This allows you to import a complete wall style into any project you’re working on using Revit’s “Load as Group” option.

The pack page contains a guide by Paul that describes the techniques he used to create the pack and how to load the walls into your projects. As Paul has pointed out, even if you aren’t using Knauf walls in your project, this pack is a great tool for learning how to create your own manufacturer-specific system family libraries. At $50, we think it’s a steal, and hope you will too. So check out the Knauf Walls pack here and let us know what you think.

At the core of this information smorgasbord are shared parameters. Shared parameters live within families, projects, and schedules. Ideally your project template already has schedules built in for use as deliverables, and your families have the right shared parameters to fill in these schedules from the moment you lay down your first wall. At the same time, content is coming from many sources: different groups or individuals within a company, product manufacturers’ websites, and third party providers (such as Andekan). Standards for shared parameters are required if project schedules are not to be incomplete at best, and erroneous at worst.

Some companies, or individuals within companies, believe the answer is to develop and use internal standards exclusively. Yet those BIM managers who claim their company’s Revit content is all created internally are doing a disservice to their employer. The task is too resource intensive, and public or third party libraries of content will grow to thousands and thousands of families over time. Ignoring the benefits of readily available content from the outside simply doesn’t make sense.

On the other hand, an industry standard for shared parameters must take into account the different disciplines within the AEC sector, as well as the industry specifics of various product manufacturers. To date, Autodesk has set the tone with their Seek team releasing an initial standard that contains shared parameters – the Revit Model Content Style Guide. The standard is limited, however, and has some incongruencies.

For example, the Seek standard has three shared parameters for fan power – Return Fan Power, Supply Fan Power and Exhaust Fan Power. I just created a centrifugal fan family for a customer that was manufacturer-specific and could be used within any of those systems, i.e. return, supply and exhaust systems. To meet the Seek standard, I would have to add three shared parameters for fan power, each with the same value reflecting the same product data.

With generic content we have the same situation. While the default content in Revit MEP 2012 shows some content split per system, it also has content that is system agnostic, e.g. Centrifugal Fan – Inline – Direct Drive, Centrifugal Fan – Inline – Belt Drive. The Seek standard tries to codify, within the shared parameter name, the system where the parameter is being used, but having to enter three shared parameters that will hold the exact same information is a waste of time, prone to errors, and, if formulas are used to keep the parameters identical, can even affect performance within a project.

Then there is the issue of deciding the proper units for shared parameters. Seek’s standard defines Supply Fan Motor Speed as a NUMBER. This parameter will accept as a value any unitless real number, measuring Revolutions Per Minute (RPM). Recently, another standard called ANZRS was published to address content standards for Australia and New Zealand. That standard doesn’t have a shared parameter named Motor Speed or anything similar, but it does have RPM_ANZRS. RPM_ANZRS, however, is defined as an INTEGER. If we are going to be meticulous from an engineering standpoint, the choice of INTEGER as the DATACATEGORY for the parameter is wrong.

Ignoring for a moment the engineering side of the issue, Revit throws a spanner in here. Let’s say you download a manufacturer’s family that follows the Seek standard. You’ve just cut a couple hours time from the process of adding such an item to your library. Now you edit the family and try to substitute its Supply Fan Motor Speed parameter with the RPM_ANZRS parameter. Revit won’t let you.

This could be handled by Revit easily enough if the parameter weren’t to be used in any other formulas within the family, but even then there is a chance that the parameter could already be in use within project schedules or calculations. And while you could argue that Revit should more gracefully handle the substitution of one unitless parameter for another, that still wouldn’t help in certain cases, say where one standard sets a given parameter as a LENGTH while another sets it as TEXT.

These examples are just the tip of the iceberg when it comes to issues with standardizing shared parameters, and my critiques are by no means meant to condemn or discount the efforts being made by Autodesk and other groups, such as the ANZRS. These initiatives are essential and progress is being made. I myself will be participating in the AEC Standards Committee a couple weeks from now, where Revit family standards and shared parameters will be discussed.

My aim here is to dig into the complexities involved in this endeavor, and to encourage an active and open discussion about the usability and long-term implications of proposed standards. Without this kind of consistent public examination and feedback, I believe we run the risk of getting ahead of ourselves and adopting standards that could prove more of a burden than a boon for Revit users. I plan to continue writing on the subject of standards in the weeks and months ahead, and in my next post I’ll look at Revit’s interface for shared parameters and how it has affected naming conventions to the detriment of long-term usability.