Description
Just writing down some notes and ideas we had during a discussion on the readability of Bonsai Harp operators during Bonsai DCM 2026-07-30.
The initial question was about word and character limits for Bonsai operator names and readability problems for devices with especially long device names or registers. For instance, for operators from the Harp.TimestampGeneratorGen3 package, the device name essentially fills the entire text box, making it impossible to read the register names (these are two different messages: BatteryThresholdLow and BatteryThresholdHigh).
Admittedly, this is quite a rare edge case, and the Timestamp Generator Gen3 has the longest device name currently. However, the current labelling pattern of DeviceName.Register for most of the operators also poses other readability problems. For instance, these four different operators (FilterRegister, CreateMessage, Format, Parse) are named the same.
People experienced with Bonsai and Harp learn to use either the surrounding nodes or the colours to disambiguate these different operators, but it can be quite unintuitive for newcomers and also a bit hard to follow along with for tutorials (the name of the operator as it appears in the example workflow image is different from how it appears in the toolbox).
Proposals
We discussed various ideas to address these issues:
- Adding an extra line to the operator textbox to display longer names or additional prefix/suffixes.
- Changing the icons (not sure what this covers, device specific icons?)
- Surfacing the fully qualified name of the operator on hover or somewhere else
- Dropping the
DeviceName prefix and adding the operator class instead.
Surfacing the fully qualified name of the operator would also solve other readability issues for Bonsai operators in general, so I will raise a separate proposal for that.
I did a quick mock-up of the last option; this is how a CreateMessage for Harp SoundCard currently appears:
And if we replace the prefix:
Additional Context
One reason why the DeviceName was added to the operator label was that it does not show up if you click on the operator and check the property panel description, so if we drop it from the label we need to add it there:
Also worth noting that the GroupByRegister and GetDeviceMetadata operators omit the DeviceName from the label; it only appears in the description.
Description
Just writing down some notes and ideas we had during a discussion on the readability of Bonsai Harp operators during Bonsai DCM 2026-07-30.
The initial question was about word and character limits for Bonsai operator names and readability problems for devices with especially long device names or registers. For instance, for operators from the
Harp.TimestampGeneratorGen3package, the device name essentially fills the entire text box, making it impossible to read the register names (these are two different messages:BatteryThresholdLowandBatteryThresholdHigh).Admittedly, this is quite a rare edge case, and the Timestamp Generator Gen3 has the longest device name currently. However, the current labelling pattern of
DeviceName.Registerfor most of the operators also poses other readability problems. For instance, these four different operators (FilterRegister,CreateMessage,Format,Parse) are named the same.People experienced with Bonsai and Harp learn to use either the surrounding nodes or the colours to disambiguate these different operators, but it can be quite unintuitive for newcomers and also a bit hard to follow along with for tutorials (the name of the operator as it appears in the example workflow image is different from how it appears in the toolbox).
Proposals
We discussed various ideas to address these issues:
DeviceNameprefix and adding the operator class instead.Surfacing the fully qualified name of the operator would also solve other readability issues for Bonsai operators in general, so I will raise a separate proposal for that.
I did a quick mock-up of the last option; this is how a
CreateMessagefor Harp SoundCard currently appears:And if we replace the prefix:
Additional Context
One reason why the
DeviceNamewas added to the operator label was that it does not show up if you click on the operator and check the property panel description, so if we drop it from the label we need to add it there:Also worth noting that the
GroupByRegisterandGetDeviceMetadataoperators omit theDeviceNamefrom the label; it only appears in the description.