KeyNotes - You Keep Using that Word...

A recent exchange went a little like this:

Them: "Steve! I need some help with my keynotes!" Me: "Okay, how are you doing them?" Them: "Huh? I just drag this family from the Project Browser and place it in the view. When I look at my keynote schedule I don't see the keynote being added."

When software uses the same word we routinely use to describe something we do it is supposed to make it easier to understand and use. Sometimes the opposite happens, as in this situation the word Keynote or the practice of key noting  (keynoting). A good many of us in the AEC business are familiar with the concept of using keynotes on drawings.

I find it interesting that I didn't find a definition readily available on the interwebs for what we do with and call keynotes. There were lots of trade specific sites but not the traditional dictionary or wiki version. Most refer to being the keynote speaker at an event or related to music.

Regardless, for us it is a system to reduce clutter on drawings by placing symbols that either carry numbers or letters or both to identify different conditions that we should look to a separate place (key, like a map key to symbols) to read more information. Ideally it means we get drawings that are cleaner looking instead of the clutter of long descriptions nestled among the graphics that describes the building itself. It's also a way to help reduce the chances of making spelling errors or stating things differently because more than one person is usually involved in the process of completing drawings.

In Revit there are three ways we can apply keynotes to drawings. First we have a formal tool called, not surprisingly, Keynote. Second we have an older slightly less formal technique using a Noteblock Schedule based on a Generic Annotation family. Third we have the old school approach where we use a Generic Annotation symbol and then separate Annotation (lines) and Text elements to provide the appearance of a formal schedule we are familiar with.

I've often referred to the Keynote feature as the rich man's keynotes because it requires ongoing rigor and advance planning/effort.

We have to manage an external keynote file (TXT) and use specific annotation tags that work with this external data. Our families can each store a keynote parameter value (which a tag reports) and we can create ad hoc User Keynotes too. Keynote Schedules can (a Filter option) display only those that appear in the views that are on each sheet, a distinct advantage over the other techniques.

In the image below I'm using a cool tool called Keynote Manager to review keynotes. We have to organize the information that we want to be available for keynoting ahead of time or at least be prepared to stop and start when we realize we are missing something. The external data and process is more formal and rigorous. That's why I've observed it is also poorly adopted.

When we combine this process with Keynote Legends on sheets we have a consistent and predictable structure for keynoting activity.

In contrast the Noteblock approach, which I've often called the poor man's keynotes, depends on data stored in specific Annotation Symbol families.

It does require some rigor but not quite as much as the formal Keynotes tool and there is no external TXT file that keeps the data consistent. When we create a Noteblock Schedule we have to choose the correct Annotation Family to base it on. Then the schedule reports how many instances of that annotation family (symbol) we place in views, that are then placed on sheets. These are much harder to filter so we only show those that relate to specific views on sheets, there is no built in feature to filter them.

The third approach is not really any different than how I've seen it done for many years with CAD and hand drafting before that.

We place symbols, change the number/letter and then later create a legend on the sheet that provides a summary of the keynote symbols we've placed in the drawing. We examine the drawing and make an entry for each symbol we observe on the drawing. It isn't hard to do but it isn't fun and very error prone, especially as the project progresses and changes occur.

Referring back to the exchange at the beginning of the post, it turns out that the technique that was being used was the last one, symbols, lines and text. It helps a lot to figure out which technique is being used before launching into helpful responses that assume either of the other two possibilities are in play.

Revit MEP Annotation Scale

In the settings dialog for duct, pipe, conduit and cable tray Revit provides a parameter called Use Annot. Scale for Single Line Fittings. There is also a second related parameter called "XXX Fitting Annotation Size" where "XXX" is the element involved. As the parameter names suggest they are related to single line views, where the detail level is either assigned to Coarse or Medium for their category (duct/pipe/conduit/cable tray).

When the first parameter (previous image) is checked Revit will check (turn on) the parameter that each fitting or accessory has, called Use Annotation Scale, each time they are placed in your project.

The purpose of these related settings is to provide a consistent symbol size regardless of view scale (in single line views). This way the symbols don't suddenly become much larger or smaller in different scale views than the symbols we show on our legends. When you see this occur you'll need to double check the settings and the individual parameter values for each affected family.

If the option is off in the Settings dialog then every fitting or accessory you place has its own Use Annotation Scale setting unchecked (off). It's a global on/off switch to enable the feature. You can still interact with each fitting or accessory's own parameter to enable the annotation scaling feature or vice versa. When you change the view's scale you'll find that the annotation symbol graphics will not remain the same printed size.

The following image shows one ball valve accessory that has had its Use Annotation Scale turned off. It's larger than the other fittings and accessories in the view, they adjust their symbol size so they are the same size when the views are printed on a sheet. The lower plan view is using 1/4"=1'-0" scale and the upper one is assigned to 1/8"=1'-0" scale instead.

This image is both views placed on a sheet for comparison.

Each of these MEP element has its own settings; Duct, Pipe, Conduit and Cable Tray. I think the most appropriate setting for each is checked (on). The second parameter XXX Fitting Annotation Size is usually 1/8" ( or 3.0 mm) (stock setting in templates) and that's probably a good starting point. You may find it necessary to adjust it slightly by increasing or decreasing the size to get the ideal symbol graphics.

The other thing to keep in mind is that the single line graphics in these families are defined by Model Lines that are set to be visible in Coarse and Medium Detail Level but to not be visible in Fine Detail Level. This makes it possible to generate the single line diagrams in 3D views too, otherwise there would be nothing to see. It also makes it a bit trickier to get the same graphic size when comparing one fitting or accessory with another.

This is quite different from electrical families by comparison because those primarily use nested annotation symbol families for their symbolic graphics. Those already conform to Revit's annotation behavior of maintaining their printed size. It also explains why, for electrical components, 3D views (and elevations/sections) do not show the plan graphic symbols we are accustomed to seeing.

No Math Characters in Parameter Names

I've mentioned this before in the context of older posts but never in a dedicated post. Don't use characters that Revit respects as mathematical symbols in the parameters names you create. That means don't do things like this.

Revit will be nice and accept parameter names that include most if not all of them but when it comes time to do something more clever with the parameters you'll regret it. More clevererer? Like using the parameters in a formula, that's clever! You'll get messages like this one.

Easy to resolve, just don't use mathematical symbols in parameter names.

Schedules, Symbols and Marks

Anyone dealing with a little bit of implementation with Revit has probably heard this one, "Uh, but we show a "delta" for each Revision number in our revision schedule". Second verse same as the first when discussing schedules for doors, windows, motors, VAV's, Lighting Fixtures...the list goes on.

I tell people all the time that with Revit you have one of three answers to any question you might ask:

Yes it can do THAT! (85%)
Ummm...do you have a minute? (10-15%)
NO! Well...not yet! (0-5%)

Yes means there is a specific tool or intentional way to do something. Ummm...means get ready for a work around because a precise tool is missing, an approach exists but isn't obvious or intentional or you must distort an intentional feature to get what you want. Usually the result is still good and in keeping with the larger idealism of Revit and BIM. No means no, but even NO has a workaround. However it usually is so ugly, painful or objectionable that most would run away to hide in order to avoid doing it.

This delta or door tag in a schedule column is a NO, not that can happen easily or automatically unfortunately. At its worst a work around is awful because you are asking someone to place a little symbol on top of every row in a schedule to get the "look" you want with the fairly obvious unpleasantness when the data changes. A slightly better solution is to just place one symbol at the top of the column instead. I try hard to get people to "relax" a bit about this one since they've (they should have) got a symbol legend already that explains what that little delta is all about. Caution though...don't actually tell someone who is tense to relax. Usually quite the opposite will happen! 8-)

Some are quite fierce about these established habits.

My problem is that I spent eleven years, working for a contractor and manufacturer, reading A/E drawings to get equipment, materials and personnel for projects prepared to then install in the field. My primary complaint with documentation was usually the lack of detail for a specific part of the project. Worse a section or detail that was "promised" in a plan but didn't materialize on the sheet it was supposed to be delivered on.

I never ever worried about a symbol or whether the elevation "punched". As long as the symbol was on the legend "up front" I was good to go. Of course there were plenty of symbols with out a match on the legend. When I was estimating a project I usually had about a half hour to make some pretty significant decisions about what our customers would need from us so "pretty" didn't cut it...I needed data.

Make no mistake, some drawings stood out to me, made an impact and caught my attention by being different. Usually these drawings were also "better" not necessarily because they were "prettier" but because such attention to detail tends to continue on into the subtleties of a project. One thing that always made schedules easier for me that is also a NO in Revit is even/odd shading or grouping of rows so there was some visual separation of data. This made it easier to read and find my way through large amounts of information.

After eleven years of that I was in for quite a shock when I started working for an architect who was quite particular about the documentation that left his office. It was an education in the finer points of documentation and design. For that I'm grateful and it has continued to this day every where I go. But once you've had Banana Cream Pie you don't forget...I've seen this issue from both sides and they are both correct...for different reasons.

I try hard to encourage people to not distract our progress with implementation by making a NO issue a "showstopper". I encourage them to contact Autodesk to make sure they (Autodesk) understands what they need done. Eventually they'll get to most if not all commonly requested features.

I try hard to keep moving forward because many of these kind of issues are not likely to turn up in a monetary penalty like change orders or rework. I'd gladly give up this sort of "sacred habit" if I could avoid some costly change orders because one of our staff is not busy putting little symbols on a schedule/sheet and instead catches that big "oops".

The first architect I worked for said in a meeting once that it often feels like he spends 90% of his time convincing people to do things, that they can do things and 10% designing and resolving things. He could only imagine what his work output/quality might be like if he could invert that. Apply that same thinking to documentation. If we spend a disproportionate amount of time doing things that don't add value but just keep us busy we probably are n0t catching significant errers or making better informed decisions.

Good luck with "that"!