AB314 41 Good Autodesk Revit Project Templates Keys to Efficiency

Good Autodesk Revit Project Templates: Keys to Efficiency

Robert Manna Burt Hill David Spehar AIA Burt Hill

AB314-4

This course will focus on how a firm can improve team and project performance by developing a solid project template. A well developed template and source files can help your teams be more efficient and improve quality control and accuracy. Developing a good Revit template involves not only graphics standards but also practice standards or best practices. This course will also summarize and present the discussion results of the AU Unplugged Session: What Makes a Good Autodesk Revit Project Template

About the Speaker: Robert graduated from RPI in 2003. He is currently working for Burt Hill as an intern architect and BIM implementer. He has helped to lead Burt Hills adoption of Autodesk Revit traveling throughout the firms offices offering training, support and project specific assistance. He has been a key team member on several large projects and has assisted and offered advice to numerous others.

Robert can be contacted at his work e-mail address: [email protected]


2

Table of Contents:

Starting a Project Template .......................................................................................................4 What does it mean to standardize Revit? .................................................................................................4 To start a Revit template, there are two choices:......................................................................................5

What Next!? .................................................................................................................................6 Keep it clean..............................................................................................................................................6 Be Consistent! ...........................................................................................................................................7 Find Your origin. ........................................................................................................................................7

Project Browser ..........................................................................................................................7

Project Settings...........................................................................................................................8 Fonts .........................................................................................................................................................8 Keynotes ...................................................................................................................................................8 Site Settings ..............................................................................................................................................9 Project Parameters....................................................................................................................................9 Line Patterns ...........................................................................................................................................10 Line Styles...............................................................................................................................................10 Object Styles ...........................................................................................................................................12 Sun & Shadow Settings ..........................................................................................................................13 Phases ....................................................................................................................................................13 Materials, Patterns, Filled Regions .........................................................................................................14 Color Schemes........................................................................................................................................14

Views..........................................................................................................................................15 View Types..............................................................................................................................................16 View Filters..............................................................................................................................................18 View Templates.......................................................................................................................................18 Legends...................................................................................................................................................20 Viewports (View tags) .............................................................................................................................20 Schedules................................................................................................................................................21

Stuff We Never worried about Changing (but you might) .....................................................22

Families......................................................................................................................................22 System Families ......................................................................................................................................22 Families you need to load: ......................................................................................................................24 Annotations .............................................................................................................................................25


3

Model Families ........................................................................................................................................26 Detail Families.........................................................................................................................................26

Wrapping Up a Template..........................................................................................................27 Create Some Stuff...................................................................................................................................27 Leave Some defaults!!!!! .........................................................................................................................27 Tracking your features, changes and updates........................................................................................27 Upgrading................................................................................................................................................28

Source Files...............................................................................................................................28


4

Starting a Project Template A few of basic truths about "standards" (of which templates are a type):

1. If the "standard" is "built-in" and does not require additional thought or consideration by the user, they'll use it.

2. If the "standard" makes the task easier for the user, they'll use the standard (but the user has to be able to understand the value proposition of the standard).

3. If the "standard" requires additional effort, thinking or consideration by the user, they probably will not use it (unless there is a greater value proposition that the user can see)

4. Most people want to do their jobs, and then do something else. 5. "Systems" that are obvious, straight forward, and easy to understand will lead to greater and

better adoption of the standard the system is meant to support.

What does it mean to standardize Revit? What is a Revit project template, what is it not?

CAD standards were "mostly" concerned with two things:

1. Is the geometry on the right layer? 2. Are the correct blocks set-up and being used?

Behind those two goals, was a great deal of work and effort that went into maintaining and achieving those two simple functions. Having objects on the right layer meant they printed correctly, displayed correctly, it even meant that tools could be used that simulated some of the same functions that Revit and other BIM tools inherently achieve. Using the correct blocks was a part of this ecosystem and helped to meet the goal of well done, well organized drawing set.

On the other hand, Revit by its nature takes care of many of the things that required a great deal of effort to standardize in CAD. Most important to understand when building a Project Template is how Revit's ecology of Families and Types carries into everything Revit. From your text and annotations to views, the hierarchy of Categories, Families, Types and Instances makes it much easier to establish systems which can easily be adapted and leveraged by your users to accomplish their primary task(s) (designing, documenting or constructing buildings). User's who are familiar with the Revit hierarchy will find it very easy to use what you provide them, and adapt it as needed to meet project specific needs, while maintaining the "company standard".

A couple of notes about this handout.

I tried to make lists often, to make it easy and straight forward to find information. I wrote paragraphs when trying to explain a concept If you see text in Italics then most of the time I'm offering what I would consider to be the "voice of experience"

(i.e. my opinion) versus what I would consider to be facts or accepted best practices within the greater Revit community

If you see bold text then I thought it was really important, either in the context of a heading, or in-line with other text.


5

To start a Revit template, there are two choices:

1. Start with an existing template. 2. Start from "scratch" (select "None")

1) Starting from an existing template You don't quite know what you're getting (unless you made the source template/project yourself). You get a fair number of objects, settings and families configured without additional effort. You may not realize what you can manipulate (and what you can't).

2) Starting from Scratch You quickly realize just how much can (and needs to) be customized in a Project Template. You have complete control; there are some basics that come with it, but anything that is added is

your fault responsibility.

It starts with a simple question:

If you're serious about building a solid project template, then you should seriously start from scratch. Its the best way to assure that what you get is what you want. When you find something is either "wrong", incomplete, or not working the way you want it to, you have only yourself to look to. You know that you can "fix" it, or change it, without wondering "where did that come from?" or "can I change that, should I? If you find that you're in need of templates for more then one system of measurement, or more then one global region, then likely you're going to want to build more then one template. If you want them to closely


6

match (as much as regional differences in practice allow) then developing them in parallel is probably your best bet. If you go to use Transfer Project standards, or insert views, you will need to keep your eye on units in particular. If the same users are not likely to be switching between systems of measurement, then it is perhaps not as critical to have your templates match.

Tips for dealing with multiple units:

Use one set of names for everything (annotations, views, text, etc) varies the settings as needed. Ex: instead of 1/4" Aerial Text, just call it Medium Aerial Text, Small, etc.

Annotations should be in the native dimensional format, keep two sets of families in two different folders with similar or identical names - pre-load them into the template.

Apply the same standards (naming, organization, shared parameters) to the same objects (walls, ceilings) in each template with customized dimensions to match the region/area/unit system.

What Next!? Ask yourself a few more questions (you already answered one):

What is the intent of your project template?

What phase of work is it going to be used for Conceptual Design, Schematic Design Development, etc? Once a model is started, will it persist, or it will it be rebuilt?

Do you need it for a specific discipline, virtual construction, a specific building type or market sector?

Who are the users who will be using the template, what is their proficiency with Revit?

How often are new projects started?

Knowing the answers to these questions will help you to design a template that best meets your users needs. Filling your template with preloaded families and assemblies, that are specific may make your users more efficient, in a different situation, all those preloaded families may just slow your users down.

Keep it clean.

First off, treat your new template like Holy Ground. Try very hard not to do anything to defile, blemish, or bring pain and suffering to it. Make sure that anyone who has access to the template has been indoctrinated into the "cause" and that if they break this sacred rule, they will surely burn in the depths of Revit hell. To keep this golden rule, do something very, very simple, do not import or insert anything directly into the template that you did not directly create yourself in Revit, or otherwise know its provenance. My suggestion, keep (or make as needed) another "blank file" to use to import items into and "filter" them as needed. One of the biggest offenders to the cause is anything with roots in DWG/DXF/DGN files. Unfortunately these file types have the nasty habit of inserting a great deal of junk into the tab "Imported Objects" under Object Styles. If CAD information is


7

actually imported (not linked) into a Revit project file, these additional categories under "Imported Objects" can never be purged. Families should also go through a scrubbing process as they cannot be fully cleaned either.

Families derived in some way from CAD data are the next biggest offenders after directly importing or linking CAD files into Revit projects/templates. This is why nothing should be inserted without first checking it, as you never know when your family might let you down.

Other places to watch out for blasphemous CAD infiltrators are:

Line Styles Filled Regions Line Patterns

Be Consistent! If Revit has a name for an object, a family, a setting, a parameter

then use that name when you create new stuff. This will lead to less confusion overall, and emphasize the correct vocabulary.

Establish conventions - specific suggestions to follow, but develop naming systems, and stick to them!

Find Your origin. This has become less of an issue now that there is the Base and Survey point. However you may consider putting a group of model lines at the origin (we even created a custom line type) and pinning the group. If you're still using pre 2010, the quick way to Origin (any Stargate fans?) is to link a CAD file "Origin to Origin" with the origin in the CAD file marked with a couple of lines.

Project Browser Several approaches can be taken to how the browser is organized:

Some people choose to add custom parameters to views and sheets to allow various sorting options of the browser.

Some people use naming conventions to distinguish between what types of view there are. Naming Conventions really are not optional (see the section on Views)

If you decide to use the custom parameter route (our preferred method), if you make a mistake, remember to clean the mistake up in your View Templates, and not just your Views.1

1 Steve Stafford "Revit OpEd": http://revitoped.blogspot.com/2009/10/dept-of-subtle-cant-get-rid-of.html


8

Organizing, and providing methods of organization for the Project Browser is an important step to making it a crucial Project Management tool. You should pre-create filters for the View & Sheet browsers that make it easy for a "Project Manager", "Project Architect" or "Lead Modeler" (feel free to substitute your own vocabulary/job descriptions) to understand what is going on in the model.

Our PA's and LM's have found it incredibly helpful to toggle between a custom filter that shows all views, and one that shows only views that have not be placed on sheets. Since we differentiate "Documentation" views from other types of views (by way of a custom parameter), it becomes very easy to know how the document set is progressing, and if anything has been "left off". Of course this only works if your teams also cartoon their sets in advance....

Project Settings

Fonts Font's are not really a project setting per se (would be handy right!), but because they show up everywhere this seemed to be the best place. Fonts need to be fixed everywhere (unless you really like Aerial):

Text Types Dimension Styles Coordinate families Built in annotations (contour labels) Schedules Color Scheme Legends Annotation Families.... (tags, annotations, grid bubbles, level heads)

To get to certain items (such as; contour labels, spot slope, grids and levels) you need to activate the tool, making the "type properties" accessible.

Keynotes

Keynotes are a project setting, so if your firm uses keynotes at all, you should consider setting up a path to your default file.

At Burt Hill we have a default keynote file that has been greatly simplified from what comes with Revit. However that file has also been write protected, so therefore, projects need to make their own "project copies" to customize as needed.

If your firm does work almost entirely in a single market sector, or has repeat clients you may also consider setting up keynote files for those sectors or clients. If you work in a network environment with


9

multiple users you will likely also want to set the "path type" for the file location to be absolute, that way Revit will always look for the exact path to the file location.

Site Settings Take a moment to visit this dialog, and assign a section cut material, and set the units for Property data.

Our approach was to create our general Burt Hill template, then create a specific "site" template for creating site files that aggregate multiple building files together. The site template has had a great deal of "stuff" purged out, and many settings modified to better reflect the tasks and scale of work to be done in a "site" file. For instance:

Levels named to be "Sea Level" & "First Floor Finish Floor" Setting default view scales to larger sizes. Changing default project units to reflect typical Civil Engineering Units Adding a Cut/Fill schedule Creating dimension types useful for large drawings (unit overrides & text size). Pad types, including "gravel"

Project Parameters

Project parameters are an essential tool to help your teams more effectively leverage the model they're working so hard to build. It is easy to quickly end up with numerous parameters, particularly if users add their own as needed for specific projects. To help keep things organized, you might consider naming parameters first with the "Category" to which they belong, e.g.: Room Occupancy. Information that you may consider tracking with your own parameters:

UL Number (walls, ceilings, floors, roofs) STC rating View Classification Various parameters to identify and organize and sort

sheets by Package(s)/Submission(s) Contractor Furnished/Contractor Installed, Owner

Furnished/Owner Installed Code related information Single "Fire Rating" parameter assigned to; walls,

ceilings, floors, roofs Door/Window related parameters LEED info: recycled content, glazing ratios, qualified

spaces, flush rates, etc.


10

It is obviously useful to have many of these parameters as shared parameters so that they can be included in tags, titleblocks and or families as necessary. While it can be endlessly debated on how to keep shared parameters organized, one solution is to have a "Project Parameters" shared parameter file that lives in the same place as the Project Template. For specific items like doors, you might create a shared parameters file that lives in the library with those objects, making it easy to access for advanced users on an as needed basis (read only of course).

Line Patterns Here Revit does a good job of getting you started, but likely you're going to need to customize. You may consider adding multiple "scales" of styles, and additional styles to suite your practice's needs. Here's a snapshot of a portion of ours:

Note the multiple scales for the "Dot" pattern, and patterns for "Fire Rating". Also note the consistency in naming. Watch out for CAD infiltration here!!!

Line Styles Getting this right will have a big payoff. It will be easy for your users to create documents that are consistent with previous graphic standards. Revit's detailing tools will be a breeze, and everything will just "flow". Revit starts you out with "Wide, Medium and Thin". While it may be possible to draw with only three line weights, having a few more, and some variety will probably make it much, much easier for your users. While in this dialog, you should also take time to adjust the line weights of Revit's default/built-in Line Styles, these line styles are always bracketed with "". In particular, pay attention to the settings for and .


11

Our approach was to recreate a scheme similar to CAD but also borrowed from Revit's default behavior. We created line styles numbered 1-7, named this way:

(3) Medium Lines

this means that modifiers can be attached, such as:

(5) Wide Lines - Dashed

The parenthesis sorts everything to the top of the Type Selector (very handy) and the numbers keep everything in order they are also a quick reference with regards to line thickness. In addition these line styles were added to our detail and annotation templates, making it even easier for our users.


12

Object Styles The defaults are ok; you can make them better (honest). Some time spent with adjusting Object Styles, printing and comparing views of a model to existing document sets from other software packages is time well spent. However, object styles only get you so far. View Templates will take you the rest of the way. Items you should probably make sure to customize:

Modeling Objects tab:

Curtain Wall related categories Doors (including subcategories) - its always a good idea to set a "simple glass"

material as your default material for the "glass" subcategory. Furniture/Furniture Systems Specialty Equipment Walls Windows (including subcategories) - its always a good idea to set a "simple glass"

material as your default material for the "glass" subcategory.

Annotation Objects tab:

Callout boundary - make sure you have the line style and weight you want. Plan regions - make them an annoying shade of green, or purple, something, and

a nice line-weight. They should never be turned on in views going out of house, so making them visible, will help make sure that doesn't happen.

Matchline - the default is not so great! Revision Tags Various tags/annotations - you may want to consider a heavier line thickness. Reference Planes

You may want to avoid assigning line weight (1) to objects, this is the lineweight used by patterns, reserving its use will help object's profiles to standout compared to the hatch patterns (surface or cut).


13

Sun & Shadow Settings

You may want to consider creating some presets for different times of year or day (depending on what you do). At the very least some presets for the Equinoxes and Solstices would get your users started (starting in 2010 Autodesk has started to add some additional defaults). Since "place" is separate, there is no fear of locking your users into a single geographical location.

Phases Phasing needs some help. The defaults are usually not quite good enough. Things to consider:

Leave just one phase in the Template; "New Construction" or "Phase 1". If users have existing construction, they can start with the default phase, and add more as needed.

If you decide to keep two phases (like the default Autodesk template) teach your users that if they have extensive existing conditions, start the model, and start by modeling existing conditions in the available views. Users can create new views which will default to the New Construction Phase. Once existing conditions are well underway delete the Existing Conditions phase and add future phases as required.

Add a few more filters: o Show Complete" - shows existing and new by category, hides demolition and temporary o "Show Current" (or active, whatever you want to call it) - a phase filter that hides

everything except elements created in the phase the view is set to.


14

Materials, Patterns, Filled Regions Organize your materials, out of the box Revit's materials library organization is slightly schizophrenic. There are a couple of approaches you can take to bring some order to the chaos:

By Type: each material name is prefixed with a type descriptor, ex: Metal, Paint, Carpet, Wood, etc.2

By use: each material is prefixed with a description of use, ex: cladding, interior finish, exterior finish, structure, etc.

Alphabetical: material names have no prefixes. By CSI (or other) division: each material name is prefixed with the appropriate CSI, Uniformat,

Omniclass, etc, code or descriptor.

Most materials should have need patterns assigned to their Cut and/or Surface settings. If you do not at a minimum provide your users with all the typical architectural graphic patterns (assigned to materials), then you're more likely to end up with inconsistent graphics. Having something like patterns in the model from the beginning means the first person to go looking, will find what they need, so will the second and third....

You may want to create a simple generic family that can be used to assign and display materials to be used in the project. This has the added benefit of being able to schedule the materials (whether or not they're actually assigned to objects (paint for instance), while also giving users a visual reference in a specific view (you can consider the view to be a "materials legend") to see what materials are to be used/assigned. The objects can be tagged to indicate the proper code to be used for calling out the material(s).3

Filled Regions

While talking about materials, we may also want to consider Filled Regions. While technically part of detailing, they are project template based and not an external family (so this is as good as any of a place). Region types should be defined that match all you typical materials, and should be set to use the same patterns as your materials, this will help assure consistency in your graphics and improve usability. You may also consider filled regions with a range of solid colors, and regions with several different scales of the typical diagonal and crosshatch patterns.

Color Schemes4 These are not technically under project settings, but one might still think of them as "Project Settings" since they are project wide. Take some time to pre-set some schemes. If you're work is focused in a few particular market sectors it may be worth it to "pre-define" some full schemes. That is populate a scheme (for instance color by Department) with all the typical department

2 courtesy of WATG

3 courtesy of WATG

4 courtesy of WATG


15

"Types" that are used in your work, assign some attractive colors (since the machine processing tends to fail miserably at this task), and your teams will already have a workflow advantage.

Another good technique is to create a color by area scheme, that colors all areas "greater then zero" with a single color. If this is made the default scheme, users will automatically get colored floor plans with some simple shading for all the rooms. Once again, assign a neutral attractive color, and presentation ready floor plans are only a few clicks away for your teams.

Views Views are an enormous topic in Revit, no matter what you're discussing. For instance:

1. What views/sheets should be created by default? If you create too many, or the wrong ones, your users will just delete them the first time they create a new project.

2. Do you create views for multiple phases? 3. Do you create one sheet for each series, or multiple sheets within each series? 4. What View Types should you create? 5. Which legends? 6. Which schedules?

The list goes on....

View Naming conventions are not optional;

1. No two views in Revit can have the same name. 2. Even small projects create many views.

Therefore, give your users something to work with. Even if you create only a few views in your template use a system to name them. If you're not going to have many views to start, create a drafting view that documents the naming convention(s) for various views and view types.

Don't think of views as just a means for documenting the building. Views can be useful to convey information to the team, or provide instructions for users when they start a new project. Think of these views as "Management Views" or "Information Views".


16

Several Examples of these types of views:

Bulletin Board - provide updates on changes in the file, critical information for team members. SWC View - view that users should have open when then Synchronize With Central, to reduce

overhead on computer performance. Template Instructions - provide an introduction and instructions on the uses of the templates and

"features" that have been included Company Standards - document approved company standards for example; Sheet Numbering &

Naming Conventions, partition types, door families, casework, etc.

Image Courtesy of Craig Barbieri and his blog iRevit

View Types Creating custom view types can help your teams more effectively manage and organize their projects. Different view types can be one of your steps in how the project browser is organized. Organizing by View Type will make it easy to do tasks like apply View Templates, check to make sure the correct drawings are on sheets and exporting and printing the correct information for consultants and clients.


17

Types to consider:

Coordination/MEP Section - used for setting up sections to be exported as backgrounds for consultants (usually MEP engineers).

Modeling Section - views used by the team for the purpose of developing and managing the model.

Exterior Elevation Interior Elevation Modeling Elevation - elevations used by the

team for the purpose of developing and managing the model.

Information Views (2D) drafting views which convey primarily text information either about the project or model. Anything that is not a true "detail".

Detail Views (2D) drafted details of any type (that are obviously divorced from the model).

Other Types....? depending on market sector or project type you might want to add elevation or section types for: Bathrooms, Labs, Classrooms, Presentation, etc. If you are going to have a great many of something, it might be worth having its own type.

While the available behavior is somewhat limited it is also possible to create custom section heads to help differentiate views that belong on Sheets from views that have been added for other reasons. These custom heads don't need to be pretty, and they don't need to be perfect, as they should never show up printed on a sheet in the first place.

We always use the "round" elevation marker for our elevations that go on sheets. Therefore we assigned the "square" elevation marker to our Modeling Elevations, a quick an easy way for our users to differentiate the two. Adoption of these practices will make it much easier for teams to identify views in the model visually. Thus as a project advances, the general rule can be "If the view has no call out references (sheet and number), and it is not a Coordination or Modeling view, then the view can be safely removed from the model. Views created for sheets, belong on sheets, views for modeling should be identified as such, etc. If a user "looses" work because a model was cleaned up, then the user has no one to blame but themselves.


18

View Filters I like to tell people View Filters are the graphical version of what you can do in schedules (which, at a very basic level is true), however this also requires the user to fully understand how filters in a schedule work. Filters can also be thought of to be conditional formatting for graphics (which is similar to conditional formatting in Excel). We have found it quite useful to include some default View Filters for our teams. For instance "Fire Rating" filters, which color walls, floors and doors according to their given fire rating. This makes it very easy to do two things, check the assemblies that are being used in the model, and two, its very easy to generate a Life Safety/Code Review plan (assuming that color is acceptable). Due to the type of work we do, we've also found it helpful to have filters that can show Furniture & Specialty Equipment with different graphics based on if they are identified as "Owner Installed" or "Contractor Installed", etc. These filters are based on the Project Parameters we've also added. Using filters in this way is much more effective then building the graphic intelligence into the family itself.

Did you know? - Levels & Grids are also available to be used in filters, which can be handy on projects with a larger number of levels or phasing. You can create filters that will filter out levels or grids that belong to a previous (or future) phase.

2010 added one very important and very useful change to View Filter behavior, access to Elevations & Sections in the category list. This means it is possible to create filters that can be used to turn off "Interior Elevations" for instance, or hide sections/elevations at a scale larger or smaller then a specific scale. Watch out though, as the elevation circles/squares may stick around even when the actual view is filtered out.

View Templates View templates are one of the most useful features that can help get your teams started with views that have graphics that meet your firm's requirements. At a minimum you should set-up View Templates for the typical views that would be used in your drawing sets initially, for example: Typical Floor Plans, Building Sections, Wall Section, Elevation(s), Detail(s), etc. If you combine View Templates and View Filters you can make it easy for your teams to begin to set-up and configure more complicated views such as; Code Review/Life Safety plans that color construction systems based on fire ratings, Furniture and Equipment plans that indicate responsible parties, views that need to highlight particular types of elements or system (for instance elevations with windows & doors turned off to show rough openings). This combination of Filters and Templates is particularly powerful and important for MEP users, the ability to color code duct, pipes (and maybe someday more) by their system and usage makes it much easier to work and coordinate different disciplines in Revit.


19

With the addition of the Include setting "granularity" in View Templates you can begin to consider or think about View Templates as macros for automating procedures, not just something that manipulates settings. For instance you could create Templates that clear all applied filters, or templates meant to "reset" a view to default settings, these types of Templates can be particularly useful for modeling views that users may be constantly manipulating in order to work on the model.

Some users promote the use of View Templates in concert with what they refer to as "additive views.5 That is a view template is assigned to all view types that turns most categories off by default when a new view is created. Starting from this approach users are encouraged to create new view templates as needed based on how they set views and by using the "use on views of same type."

Watch Out!! - The option "Use on Views of Same Type" can be deceptive at best. This setting applies to all views of a particular type in terms of; Floor Plan, Reflected Ceiling Plan, Sections and Elevations. It does not allow for the assignment of separate view templates to different "types" within a View Type, that is to say you cannot assign a Building Section view template to a Building Section view type and Wall Section template to a Wall Section type, for example there can be only one View Template assigned to all sections, regardless of any types you may have created.

5 David Duarte: Revit Beginners http://revitbeginners.blogspot.com/2009/08/additive-views-vs-subtractive-views.html "


20

However, you can teach your users to correctly assign the "Default View Template" to each view as they create new views. If users learn this habit, view templates can become a valuable management tool for controlling the appearance of the model. Taking the time to set the default template is easy, and can be done while the user also names the view, and modifies any other important properties.

Legends Legends are useful views, but they cannot be moved between projects the same way that drafting views or even 2D elements in 3D views can be. Therefore you are left with the decision; how many legends do I create, which leads to the question how many families do I pre-load to create some part of (or all) of those legends? Legends you might consider:

Standard Symbols and View Callouts Fire Rating symbology Ceiling Types - Presumably you've create materials for you typical ceilings, and also filled

regions, start your projects off then with a default RCP legend (if you create a Ceiling Sheet you can even throw it on there too). In addition you can create Ceiling Types that match the legend (see Families)

Finish Floor Types - similar to ceilings, assuming you have finish floor types pre-created, a legend would be handy.

Door frames and door panels - this requires you to preload some door families, however it is probably worth it. There are some doors that almost always are used in every project. Starting a door/panel legend will make it easy for teams to adopt and adapt the legend(s) to their needs.

Depending on your market sector or practice you may also consider pre-created/started legends for:

o windows o casework o specialty equipment o accessories

keep in mind, these legends would require the families to be loaded too

Viewports (View tags) Viewports are system families to which View Titles (annotation families) are attached (similar to attaching section heads to Sections types). Thus you have a fair degree of freedom when it comes to what you want, and how you want it, but not unlimited freedom in creating viewports and view title behavior. If you start with a blank template there will automatically be a single View tag (since it is a system family). You must "Adopt" (rename & modify) this default type. In fact, you should make it into the Type that you expect your users to use most often (or the type you want them to use most often) as it will always be the "default" type when a user adds a view to a sheet. It is also impossible to delete this type (even with Purge).


21

At a minimum you should create a type with your standard View reference information. You may also want to create:

A type with no annotation at all (useful for presentation boards or other view "tricks") Another that says "N.T.S." (Not To Scale) or some such (because you really can draw views not

to scale in Revit, I promise...). A type without a number that can be used in conjunction with Legends (as they can never be

numbered on a sheet).

In addition you may want to create alternate variants to your standard tag. This is due to how Revit handles text in (all) tags. Text in a tag will only wrap based on the size of the text box in the annotation family. Thus, when you have a small (size) view with a long name, you probably want it to wrap to two lines of text. In order to do that in Revit you'll need a custom annotation that has a smaller text box. Same thing for very large views with very long names, you'll need a tag with an extra large text box.

Lastly you may want to consider some alternate types to be used on Presentation sheets/boards versus standard construction documents, and or some types with different size text for different circumstances.

I have two motives for recommending this approach; it hopefully makes it easy for your users, but it also reveals to them the possibilities of what can be done, particularly in a case where often times people may take the "basic" presets for granted. Offer them a menu, and they might ask, "what else can the chef make?

Schedules Are unique views, in some ways similar to Legends, however they can be easily moved project to project with "Insert View from File". In the same way that it is a good idea to have different classifications of views for modeling, exporting, etc. it is a good idea to have schedules for "modeling" and schedules that are part of your documentation. The universal schedule that almost all architects need is a door schedule, it also tends to be one of the more complicated, so set your users on the right path by pre-defining a door schedule for them.

We've also found it useful to include a door schedule for modeling, as well as a room schedule for modeling. In addition we provide "example" schedules of Furniture and Specialty Equipment, with the idea that teams need to make them their "own" once a project starts.


22

If you know that your work requires specific types of schedules, or there are schedules that help to make navigating your models easier, you should strongly consider including them as your template. Teach your users to use schedules, which combine Filters, Sorting and "Itemize Every Instance" as a powerful tool to navigate the model, and make mass changes to element sets and their properties.

Stuff We Never worried about Changing (but you might)

Structural Settings - not much there, but if its important to you (note, as of 10/28/09 Arch users with WU2 cannot access these settings).

Detail Level - suffice is to say we're happy with the default view scale relationship to default Level of Detail

Line Weights - we found it more important to make sure Object Styles were set correctly and View Templates

Default Location - conveniently the Latitude and Longitude define a location outside of Boston (hmmmm). Unless you're in the Boston area, you may want to consider a location closer to home, particularly if you practice more regionally.

Families What families should you load? Which ones do you need to load? Where do you start, its so empty.......

Traditionally (prior to the "Recent Files" screen) everyone worked hard to have a good template that was "light" in terms of overall size. With Revit no longer loading the template every time it starts, a little more freedom can be taken with regards to size.

One approach to consider is the 80/20 rule, that is, you need 20% of your content 80% of the time. The trick of course is figuring out what constitutes 20% of your necessary content.

System Families There are Model object system families, such as walls, floors, ceilings, etc, and there are Annotation object system families such as grid lines, viewports or contour labels. Some system annotation families leverage loaded families, like grid bubbles, or Viewport tags, and some model system families make use of loaded families such as profiles, fittings, accessories and panels.

Model Families Model system families are similar to Views, most projects will require quite a number of them, and unless your work is confined to a very tight or simple market then it is likely not possible to pre-


23

define all the types a project will need. Therefore creating an a-la-carte menu of types that set precedents is a great way to get a project team started.

We've found it useful to include three "types" of families for users to pick from:

1. Generic - truly a generic assembly, a default or generic material is assigned to a single layer (in the case of floors/walls/ceilings/roofs) assembly. Assembly sizes vary depending on the type of construction; exterior sizes are set to nominal dimensions, while interior constructions are named with nominal dimensions, but set to exact construction sizes.

2. Named Assembly Type - for instance "Finish - Ceramic Tile 12x12 (CT-1) - VERIFY ASSEMBLY", this assembly defines a naming scheme, and provides users something to work with, but it isn't a specific manufacturer of tile, there are multiple layers to the assembly, but it requires review.

3. Specific Assembly Types/Constructions - for instance "(F02) 2HR_4" C-H Stud w/SAB_1" GB Liner / Dbl 5/8" GWB_All to Deck", this assembly is part of a standardized system, the model geometry is specific, and the assembly carries additional data such as UL number, STC ratings, etc, as needed/required.

System families that need some definition (by default you get one "type"):

o Walls o Floors o Roofs o Ceilings (note there are two types, simple "plane" and composite geometry) o Stairs o Ramps o Railings o Curtain Wall

In the case of walls, we provide a sampling of our standard partition types. A simple set of generic types are provided for exterior conditions. Assembly types as well as generic assemblies are provided for most of the other system families. For curtain wall, we specify different types for "conditions" that is typical 6 curtain wall, storefront (center & front glazed), hollow metal, and a "blank" type that users can easily adapt to whatever they need.


24

With curtain wall, you need to make the choice; do you offset the mullion, or the panel? Offsetting the mullion means the "centerline" can be used to represent the line of glazing. Offsetting the panel means that the centerline can be the center of the mullion. In the default Revit template(s) panels are offset, and mullions centered. You pick....

Annotation Families Annotations are a critical portion of any document set, so you should provide users with all the necessary basics. Most importantly this means defining types for any systems families. Many of the system families are "specialty" annotations that often display "built-in" information that the user otherwise does not have direct access to, such as View Names & Numbers, contour elevations or grid numbers. These annotations also tend to be able to have automatic behaviors that adapt to conditions in the model such as automatic rotation. For many of these system annotation families it can be helpful to the end user to create different types of the annotations that have multiple options. For instance the Spot Slope system family, which can be set to report "Up" or "Down"; making a type for each will help to reduce potential user error in a project. Other examples would be:

o Spot Coordinates o Contour Labels o Levels: Elevation Display (Project vs. Shared), or in MEP different default space

calculation heights.

Families you need to load: When you load any families, make sure type names in the families are not duplicates of the Family name (tags & annotations are perhaps the one exception).

Level Head Grid Bubble Section Heads Keynotes Elevation Marker (oops, I wish....) View Titles Tags

Tags are cool, right (they are useful little things)? Tags with different options are even cooler, for instance:

tags w/multiple text sizes tag with different options/configurations: labels, static text, graphics tags that combine labels into strings

Load a tag for every native category of object (even if you think you'll never need it).

If you really must (or want to) skip loading some tags, fine. But absolutely do not skip Rooms and Areas. Revit has a nasty habit of not allowing a user to place said rooms or areas, unless the tag type is loaded already.

Did you know? - Titleblock families are technically "tags" for the sheet view object.


25

Tags are extremely powerful; however, because they're families, its not possible to allow "easy" direct manipulation of things like text size, layout, or overall format (among other things). However, using the visibility parameter of elements in a family, you can have "multi-use" tags with multiple types that meet different needs. For instance a "presentation" floor plan with colored rooms may require extra large room names so that it is readable from a distance. One room tag family can be set-up with multiple labels, all with different text sizes.

Other tags may be set-up so that additional information can be reported as a type, for instance a room tag that allows room number or area to be "added" by way of visibility parameters.

Something important we've learned, particularly in the context of Room or an Area tag is to adjust the Units format. For instance our default tags that report area for Rooms and Areas all round to zero decimal places. We have found that super accurate tags result in more questions, with very little benefit for team or client.

Annotations Other annotations that will help your teams out:

North Arrow Centerline Symbol Graphic Scales


26

Model Families The same approach we use for System families (three tiers) can be used for model families. In some cases there may be great value to your teams to load highly specific assemblies or objects, in other cases something "generic" but "real" may be sufficient throughout a project lifecycle, and lastly, truly generic objects may fit the need of your teams. At which phase(s) projects use Revit in your firm will also affect the decision making about the types of families to load and their necessary level of detail.

What your teams absolutely need to start:

Doors Windows "Empty" System Curtain Panel (grab it from the Autodesk template)

Objects that might be handy:

Profiles: mullion, handrail(s), gutters, thickened slabs, stair nosing, metal deck, generic (typical) shapes.

Custom curtain panels Typical toilet fixtures Typical casework Typical furniture (for your market(s)) Typical specialty equipment: for instance toilet room accessories, lab equipment or health

care equipment. Typical Profile(s): mullion, railings, moldings, parapets

Architecture teams don't need too much to get started, MEP needs much more, and structure of course needs a variety of typical framing families and sizes.

In our template we like to include a circular and rectangular profile both with parametric dimensions, these profiles can be used for anywhere for anything, from a railing to a wall sweep, to a custom in-place family. We also include a generic cubic object in Specialty Equipment and Furniture which have parametric dimensions, and therefore can function as placeholders for a variety of objects, simply by creating a new type with a meaningful name, and associated data.

Detail Families While most projects are not going to jump right into detailing, providing your team with some basics will only make their lives easier. We already discussed filled regions and line styles, since these are system families it is critical to define a system in advance for your users. Other Detail Components to consider loading:

Wheelchair clear circle & tee Brick & CMU Sealant & Backer rod Break Line "Fire tape" families (one way to life safety plans)


27

Wrapping Up a Template

Create Some Stuff But not too much.... No matter what, every template has at least one Level, name it something useful. Most buildings are probably going to require a second floor level, and a roof level. You should probably create floor plan and ceiling plan views to go with those levels, meeting all your typical needs (export, documentation, modeling, coordination, phases, etc), and name them with your naming standards.

The default Autodesk template comes with four elevations, we've kept that standard and named and set their types to be Exterior elevations. Some folks like to create some default sections too; however we've found that too often our buildings don't quite fit in the "neat box". The elevations are quickly adapted, but the sections would often be deleted. Needless to say we create all the other information views discussed previously, as well as some of the General Sheets, and floor plan sheets (100 - 300). Due to the breadth of our firm, we leave it up to projects to determine how to number and what additional sheets they require after the 300's and we do not put floor plans (or ceiling plans) onto the sheet(s).

Teach your users to always keep moving a Roof level up (if you name them that way), that way they dont need to worry about renaming views.

Leave Some defaults!!!!! Leaving defaults is perhaps one of the best things that can be done to help teams be more efficient and successful, and apply whatever company standards you have for the appearance, consistency and fidelity of your models.

To make your team's live's easier:

Default grids to "1" by creating (and deleting a grid labeled "0"), alphabetical doesn't work very well; nothing comes before "A".

Organize the project browser, close families, sheets, etc Default sheet number Default door number Default window number Default room number Run a purge, to check what you have in the template Default Text Style (create text and delete) Default Dimension Style (create dimension and delete) Default Wall, Floor, Ceiling, Roof type(s) (create & delete)

Tracking your features, changes and updates No matter what, your template should grow as your firm grows. Either as your firm uses the tools more, users become more familiar with them or as Revit and the industry itself changes. You may need new standards or old ones may change. Undoubtedly there will be new additions and changes to the template on a regular basis. It is important track this information, and perhaps even more important to let people


28

know the template has changed and what has changed. One approach is using an information view (such as the "Open/Close page") in the template and keeping a running list of template additions/changes. It may even be a good idea to set a schedule for updates every few months.

We've found it helpful to use our wiki to track what changes we've made to the template, or to make note of changes we want to make. This way multiple people can work on the developing the template and keep in sync. We also have added a project parameter called "Template Version" that we keep updated when we release a new version of the template.

Upgrading Some users will tell you, never upgrade a Project Template, always rebuild. Others will tell you they've been using the same template for years, without any consequences. In previous releases Revit saw some major structural changes to certain behaviors, the addition of linking, worksharing, rooms and their volume calculations. More recently we've seen an impressive array of form making tools added and there are signs that more "analysis" will be wrapped into Revit, particularly to help with sustainable design. How much actual "change" this has on the core of Revit only the Factory really knows. What little Autodesk opinion I've been able to gather is that generally there should not be adverse consequences or impact on your models from upgrading project templates. If you actually open, and re-save your template, that should be sufficient. The upgrade process in Revit always does an "audit" of the file, and "fixes" the database (if there are errors). Autodesk has never offered or given a 100% guarantee that somewhere, somehow a problem (that they're not aware of) could not occur in the process of upgrading a template. That said, your best bet is to probably document your template well, continuously evaluate, monitor your users, and expect, that at some point, it should be rebuilt anyway. Another good approach is the use of "Source Files" which by their nature helps to dilute the possible impact of changes, and make it easier to adapt or rebuild as necessary.

Source Files At Burt Hill we've made the decision to not attempt to keep multiple templates meant for different market sector or client types. Instead we keep a single "general" template up-to-date, and we provide additional "source" files to enhance the template to meet specific needs. Thanks to "Transfer Project Standards" and "Insert from File" this approach has proven relatively effective. Source files are populated with specific families, views and schedules for their intended purpose. For instance our "Partition Types" file includes details in drafting views for all of the typical top/bottom details. Wall types have been defined for each partition type and all relevant data populated into default parameters, or custom Project Parameters. Additional partition schedules and a typical "partition sheet" (laid out) have been created. A set of 8 " x 11" sheets have also been created which


29

can be printed as the "Burt Hill Partition Type" handbook. The whole file forms a cohesive unit all about our partitions; we do not have to worry about updating other parts of the file, only partitions.

Other possible candidates for Source Files:

Stairs, Ramps & Rails Curtain Wall Toilet Partitions & Accessories Casework Doors Health Care Labs K-12 Interior Design

In all these cases the project file can be used as a central repository for the firm's standards, as well as making it easy to update only small pieces, rather then having to worry about a complete template. One major drawback is the inability to transfer legends (however drafting elements in legends can be copy/pasted). In the case of the Interior Partitions example, the Project Template is seeded with the most commonly used partition types from the Standard Partitions file (20/80 rule). Should any of them change for some reason, the update would first occur at the Source File, and then be pushed into the standard project template. Source files are also a great way to allow specific people to focus on one key aspect of company standards. The people, who know all about how to detail a stair, may not be the right people to determine default content for a Health Care facility, or the best schedules and their formatting to document a K-12 project. Users can be invited to participate in and review only a source file, without having to worry about immediate impact on the core project template, or even the dreaded "CAD herpes". It is far easier to roll back, or redo, a single source file, then it is to redo a project template. In some market sectors or project types, it may be a necessary to compromise and live with some impact from CAD files. Source files also help to keep file size down, by allowing them to be populated with more families that meet specific needs. Lastly, the ability to develop documentation in Revit, based on the exact elements users will be working with in their projects is powerful. While you can keep DWF or PDF files available, you always have a single source both for the actual model elements and details as well as the documentation. Source files also focus on standards of practice, combined with standards of graphic presentation, rather then either being focused entirely on graphics standards or entirely on practice standards.

Thank you: Scott Brown: HHCP, Jim Balding: WATG, David Spehar: Burt Hill, Craig Barbiari: KlingStubbins, David Baldacchino: SHW Group, Steve Stafford, Guy Robinson, James Vandezande: SOM, and all the Revit experts and AU presenters that have come before me.

Documents

AB314 41 Good Autodesk Revit Project Templates Keys to Efficiency