Keynotes vs. Properties vs. Simple Text

[Chris Grantham]

So now that is has been out for over a year, I am thinking hard about going full gas into use of the keynote feature. The trouble is, so much of our template also uses classifications and properties that are baked into elements or revised on the fly, but still displayed elsewhere in the form of schedules and/or labels. I started to put together a document to outline when it is appropriate to use keynotes vs properties. I also need to outline what information should be displayed using a keynote at different scales, but that is a different discussion. I am curious how others are resolving this feature that is not very BIM, but feels very handy. Any thoughts? Attaching my progress on keynoting rules here.

Operating system used: Mac Apple Silicon 26 Tahoe

[Marc H]

Hi Chris - Disclosure - I have not yet pushed into v28 as my current work is in v27.  Likely to get current in the next month or so.

Meanwhile, I have reviewed several online resources to evaluate if translating the work into v28 would greatly benefit from the keynotes feature.  So far, I'm not seeing the benefit. To the limited extent that I understand it so far, the keynote feature is trying to replicate the legacy drawing notes method.

I, too, have extended properties for all the model elements, and one of them is a keynote option set.  It took some effort to set up, but I find the direct relationship between the element and the property based keynote content being present on the relevant sheets a very effective and flexible solution. 

[Erwin Edel]

I did not understand the benefit of setting up a 2nd system of information completely disconnected from element properties either. It seems to have a high potential of user error.

[Antonio_ClavelArqu]

We are currently considering upgrading from 27 to 29 and have some questions about it as well.

We have three options on the table:

A. Properties. (our current system)

• We use properties with expressions that separate the codes and descriptions for plans from the names of compounds/surfaces.

Pros:

• We can use the element tables to create legends and include the same overwrites as the plan.
• The information remains 100% linked between the model and the documentation.

Cons:

• Length limitation in compound names, complex profiles, and surfaces (which is where the source information is stored).

B. Tables with 2D text in a specific plan for this purpose (iceberg model)

• We draw the tables with elements from the model on a specific floor plan and use labels for the codes (as in method A) with a handwritten description.

Pros:

• Content flexibility, as we can mix different types of elements in each table or incorporate 2D details into each one.
• Serves as a catalog of solutions from which to select elements for the project (we do not use favorites in the office).
• We use the same naming scheme for compounds, surfaces, and complex profiles with a code and a description. In this case, the description is simple for the job, not for the plan. E.g.: P03-Wet partition for sliding door. Instead of:

P03-PYL partition, Knauf W112 system. 90 mm galvanized steel vertical studs, standard double plate (A) 2x12.5 mm on one side and double wet plate (H) 2x12.5 mm on the other side. Thermal insulation using rigid rock wool panel e: 80 mm (70 kg/m³, 0.04 W/m.ºK). Includes galvanized U-channels and C-studs, 100 mm wide acoustic tape, Perlfix powder for possible direct cladding, paper tape for joints, UniK 1H jointing compound, screws, and fasteners. (DeepL)

Cons:

• The information between the model and the legend can become uncoordinated if the description does not correspond to the model.
• When exporting IFC, this information is not transferred to the model.

C. Key notes.

• Use key notes that contain the information from the legends.

Pros:

• Use Excel to edit the information from the legends externally.
• Grouping and structuring of information.
• System designed for this task natively, not a workaround.

Cons:

• The information is not linked to the model at any time.
• The labels do not refer to the labeled model; they are placed manually. The other methods allow you to select all the elements and label them at once with Alt+T.

Conclusions

We are proposing method B as the most viable given the length limitation on the names of compounds/surfaces/compound profiles.

Ideally, we would have properties in the complex compounds/surfaces/profiles or even be able to link Keynotes directly to these elements. This way, in addition to linking descriptions, we could assign measurement items or other characteristics specific to the compounds instead of assigning them element by element. Fire resistance, weight, cost...

This would eliminate the need to manually place labels, and the elements would have that information linked in exports.

Currently, we do not find the Keynotes system included in Archicad to be practical. We understand that it is a tool that is still in beta and needs a lot of development before it can be truly useful.

Translated with DeepL.com (free version)

[Jp1138]

Are keynotes useful? Yes, you can easily get nice formatted tables and enter information. But they are just centralized dumb text.

Using them feels like giving up on having a "real" BIM model.

It´s imperative that some kind of connection exists between the keynotes and the modeled elements.

[figge]

Strongly agree with Jp1138 , great potential but we don't find it the slightest useful, unless its directly connected with the object/element properties. It feels like we would be doubling up on the system and therefor asking for errors. Instead of controlling element information from a single point we would have to change multiple instances and easily end up with inconsistencies/discrepancies.

I like how it works as a feature in itself and it has a fantastic potential, but until element properties are implemented (hopefully on graphisoft schedule) it's off limits for our workflow.

[Marc H]

Hi Antonio,

In my thinking, working directly in the dataset (as in your Option A approach) is where you can best leverage AC.  Even with my limited construction document work this year (much of my work is front-end planning and pre-design), I was able to work out a keynotes schema with two custom properties in combination with a group of schedule schemes.

With the advanced skills you outline above, I believe you can assemble a robust solution for your practice.

[Antonio_ClavelArqu]

Hello Marc H.

System A is very robust. The information is 100% linked to the model and everything is stored in compounds/profiles/surfaces.

The only limitation is the maximum length of 255 characters for the names of these elements.

For an Construction Documents phase, it is very limited in terms of being able to prepare the documentation correctly.

[Marc H]

Hi Antonio,

If I understand correctly from your example, in that particular case your keynotes are acting as a wall type legend.  If so, it’s slightly different than the more traditional approach I use.
In my work, the wall type legend is on its own layout. I put segments of them under their wall-type IDs and attach a simple text label onto the segment to display the composition description.
Separately, the element keynotes across the various drawings briefly describe the work effort involved for all the individual elements (walls included).  The keynotes are referenced by the element ID, which follow a project level naming convention.  
I guess it’s a little slight-of-hand in that the wall-type ID is generic with the keynotes leading off with their ID as a prefix, but the keynote itself is specific to that particular element (or across a group if sharing the same ID).

[Davor P]

To use properties more extensively, Building materials, Surfaces, Composites and Profiles would need to have more more information attached to them so we don't have to store everything in the name. Like many other things, there are workarounds to this. In case you only need to show additional information in one place, you can even simply schedule some of these and add custom fields. Issue is that this info can't be reused then.
Other options to extend beyond the limit of the 255 characters in name would be a macro object where you match additional info to your attribute code or external text file that GDL can read.
Or you might even use project info to define more information and with a few string operations (LEFT, LEN, FIND) you can match the attribute code with additional data.
Hope we can see a link between keynotes and attributes - there is lots of potential, but just remember python and paramo. My impression is that most of these new features in Archicad have served their purpose as soon as GS marketing no longer has use for them.