topic Re: Keynotes vs. Properties vs. Simple Text in Documentation

Keynotes vs. Properties vs. Simple Text

Chris Grantham — Thu, 09 Oct 2025 14:08:20 GMT

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

Re: Keynotes vs. Properties vs. Simple Text

Marc H — Tue, 04 Nov 2025 05:35:32 GMT

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.

Re: Keynotes vs. Properties vs. Simple Text

Erwin Edel — Tue, 04 Nov 2025 08:17:22 GMT

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.

Re: Keynotes vs. Properties vs. Simple Text

Antonio_ClavelArqu — Tue, 04 Nov 2025 14:37:45 GMT

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)

Re: Keynotes vs. Properties vs. Simple Text

Jp1138 — Tue, 04 Nov 2025 16:59:38 GMT

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.

Re: Keynotes vs. Properties vs. Simple Text

figge — Tue, 04 Nov 2025 20:35:37 GMT

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.

Re: Keynotes vs. Properties vs. Simple Text

Marc H — Wed, 05 Nov 2025 05:07:00 GMT

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.

Re: Keynotes vs. Properties vs. Simple Text

Antonio_ClavelArqu — Wed, 05 Nov 2025 07:46:24 GMT

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.

Re: Keynotes vs. Properties vs. Simple Text

Marc H — Thu, 06 Nov 2025 04:25:59 GMT

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).

Re: Keynotes vs. Properties vs. Simple Text

Davor P — Thu, 06 Nov 2025 05:25:15 GMT

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.

Re: Keynotes vs. Properties vs. Simple Text

Erwin Edel — Thu, 06 Nov 2025 09:07:37 GMT

I agree that things are developed to 'good enough' and rarely see further development.

Re: Keynotes vs. Properties vs. Simple Text

Stefan L_ — Thu, 06 Nov 2025 11:32:27 GMT

@Erwin Edel schrieb:

I agree that things are developed to 'good enough'...

I disagree! 🤣

Re: Keynotes vs. Properties vs. Simple Text

Gabor Szelei — Thu, 06 Nov 2025 12:15:06 GMT

You'll see, everything will be solved, this too... But only in AC31, or later, when only the subscription model will work. Anyone who stops at AC30 will not be able to use it

Re: Keynotes vs. Properties vs. Simple Text

Jp1138 — Fri, 07 Nov 2025 08:31:00 GMT

Then, in Archicad 32, there´s no reason to continue updating the program, as everyone has now lost the luxury of stop paying. Back to just good enough 😅

Re: Keynotes vs. Properties vs. Simple Text

Antonio_ClavelArqu — Fri, 07 Nov 2025 08:37:15 GMT

Hi @Davor P

Thanks for that thread to go on.

With this, we have created an Excel file with the following 3-column format:

COD

_-_

Full description

_-_

Budget item

_-_

We copy and paste everything from Excel to a project info property. We have created one for each category of element: walls, flooring, ceilings, furniture, etc.

We continue to maintain composites, complex profiles, and surfaces with the following format:

COD

_-_

Short description

Finally, some SPLIT expression properties search for that code and return what they find to the right of it (full description).

This way, we can maintain long descriptions, respect line breaks in the source text, and link them to elements in the model.

We use the same method to assign the starting code to each element directly from Excel.

This way, we don't need to reserve all the elements to modify their description or starting code.

Translated with DeepL.com (free version)

Re: Keynotes vs. Properties vs. Simple Text

Davor P — Thu, 13 Nov 2025 04:47:58 GMT

Glad it worked! Project info has been my go to solution for site area calcs - put the overall site area in there and call it to calculate percentages with zone areas.

Re: Keynotes vs. Properties vs. Simple Text

Antonio_ClavelArqu — Fri, 19 Dec 2025 00:06:02 GMT

We have an update on this issue.

When using linked modules, we have detected a problem, It is unable to return information from the linked modules.

We have tried the following options:

Source	Property (expression)	Project Info	Works	Comment
HOTLINK	Hotlink + Host	Hotlink + Host	❌	The properties and parameters in the project info are present in both files and are identical.
HOTLINK	Hotlink + Host	Host	❌	The properties are present in both files and are identical. The parameters in the project info are present in both files, but are only filled in on the host.
HOTLINK	Host	Hotlink + Host	❌	The properties are present in both files and are identical. The parameters in the project info are present in both files, but are only filled in on the host.
HOTLINK	Host	Host	❌	The properties and parameters in the project info are present only in host file.
HOST	Host	Host	✔️	Initial solution, where everything is in a single file.

For clarification purposes, we have modified the properties to use the Primary ID (which does not add the module ID) instead of the element ID.