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.
