Keynoting Sheets and Worksets

Ryan wrote a post yesterday at The Revit Clinic describing a couple scenarios that result in borrowing sheet views while keynoting views. These affect versions 2012 and 2013 in particular. If you've encountered some quirkiness on your project using keynotes it is worth a read. A subtle point made at the end of the post reveals that 2014 has been tweaked to help resolve these issues. Ryan wrote:

For Revit 2014 keynote and revision functionality has been improved. Sheet view worksets are no longer borrowed during the same process, which should give larger project teams additional flexibility (especially during documentation-heavy project phases).

Btw, Ryan is also one of the author's of the Revit Essentials book I mentioned the other day.

A Case for User Keynotes

I wrote the following (April 2012) in a reply to a thread at RevitForum.org. It is one example of how a user keynote can be applied effectively to reuse instructions and avoid stating them differently in different places, as is easy to do with regular text elements.

Imagine a data receptacle plan. The data receptacles are essentially all the same (lets pretend they are all 2 drops) except for where they are installed. Some are mounted in a wall, some in a cabinet at a sales desk, some in a kiosk (free standing display), some are available for visitors to use and others are not. As far as a schedule to summarize them, then purchasing and installing them is concerned the faceplates and back boxes are potentially identical. To apply a keynote to define how they are different in use we'd have to consider separate families or separate types so we could get different keynote values.

If we create four or five unique keynote entries we can apply them to the data outlet according to their use as User Keynotes. The keynote legend would display the information for each condition on the sheet and/or in the master keynote legend. The same information could be displayed using a tag showing a custom instance parameter but not summarized in a list on the side of the sheet as easily. Nor could we avoid different values being entered by different people.

An example User Keynote might be:

"Kiosk mounted data receptacles are to be mounted at 12" above counter surface. Provide one extra run of CAT 6 cable without terminations, for future expansion."

The same device could also have a User Keynote that says:

"Data faceplate color selection must be coordinated with interior design final material and color selections with owner."

In the plan view we'd see one device and two keynote tags with different numbers adjacent to each other. If I needed to do the same thing for other receptacles I'd have to create new types every time I needed a keynote to say something even slightly different.

Keynotes as a practice is derived from the desire to reduce clutter on the sheet and reduce the chance of writing instructions differently on different sheets. Using types to control the information is still risky because we could type different information in different types and in different families. If we are going to supply instance parameter values routinely we run the risk of similar mistakes while trying to be consistent. Since User Keynotes are pulled from the same source, as long as we all click on the same keynote the information will be the same everywhere.

Keynotes - Files, Tags and Legends

Here are a few quirky "gotcha" items you can encounter when you get serious about using the keynoting tools.

If you apply User Keynotes and then change the number values (the Key Value parameter) for them in your keynote file they don't change in the Revit project to reflect the new numbers, even after you Reload the file. That strikes me as undesirable but I believe I understand why. There is no GUID to keep track of. I'm wrong, actually there is one, it's the Key Value parameter but it isn't effective as one. When you change it...Revit can no longer reference it in the project. In order for Revit to update the Key Value too there would need to be a separate GUID (that we can't change), so it could keep track of them.

When this happens Revit keeps the old value intact. You'll have to select the keynote tag and redirect it to the correct value. You can also type in the correct value in the Properties Palette. Yet another way to manage this issue (in a project) is to have a master User Keynote legend (drafting or legend view). Place an array of a small detail component (not grouped and associated though) and apply each User Keynote to them so you end up with one keynote for each unique one you plan to use throughout the project. This view serves as your master "fixer" view. You can go through them all in this one view and fix any that need to be updated. All the others that have been placed throughout the project will inherit the change...change in one place...changes it everywhere else, phew.

Does that make sense? How or why would this even happen? Need a practical example? Let's say you create your own keynotes for architectural finishes that use the numbering scheme A200 and there are values that run from A201-225. You apply keynotes to a lot of stuff. During a design review the project manager decides that we should revise our existing A200 series to AW200 (wood finishes) and create a new AM200 series for metal finishes. Never question the pm :)

When you renumber the A200 series and reload the keynote file into the project the existing numbers in the keynote tags don't change. If you click on the tag and then the keynote value Revit will open the keynote file but it won't expand the list to show it is associated with the correct keynote, you'll have to do that. As I mentioned before you can just select the keynote tag and in the properties palette type in the new value, inserting the new "W" in the number. That will fix it and when you open the keynote file to check it will work correctly. Not a big deal for one or two or ten. Hundreds is another story.

Another item is that keynotes will still show up in a legend (on the sheet) even if the item that has been tagged isn't visible in the view. For example, if you apply a keynote tag to an element and then use Visibility/Graphics to turn that category off, the keynote legend still sees the keynote tag...and it shows up in the list.

Yet another item is that keynote tags that are in Legend Views aren't included (selected) when you use the Select all Instances option In Entire project.

If, for some reason, you decide you want to use that to delete all the keynotes you won't get the ones in Legend views. You'll have to open those views to track down any refugees. If you want to test it out yourself just add some keynotes to elements in the project. Also add a keynote to something in a legend view. Go back to the other project view(s), right click on a keynote tag and use Select all Instances - In Entire Project, then Delete them. Now visit the project browser and try to delete the keynote tag there. You'll get an error message telling you there is still a keynote tag in the project, like this message.

Unsolicited plug, if you do anything with keynotes at all, are you using Steve Faust's Keynote Manager (Revolution Design)? Why not? I really can't imagine spending any time dealing with keynotes without it, seriously.

Seriously nice little application. I should mention it supports multi-user editing and it creates backup files. That saved me and my recent client some heartache a few weeks ago. A quick search of the backups and back in business we were.