Feature Request: Add Tagging System for Button References to Ensure Consistency

Is this a feature relevant to companion itself, and not a module?

[x] I believe this to be a feature for companion, not a module

Is there an existing issue for this?

[x] I have searched the existing issues

Describe the feature

Description: In the current Bitfocus Companion setup, referencing a button requires specifying its exact page, column, and row. While this approach works, it creates challenges when buttons are moved or rearranged, as users must update references manually to reflect each new position. This proposal suggests implementing a tagging system that allows users to assign unique, persistent tags to buttons. These tags would follow the button wherever it is moved, providing a stable reference point regardless of layout changes.

Advantages of a Tagging System:

Improved Flexibility for Layout Adjustments: Users can freely reorganize button layouts without worrying about updating every reference to match the new positions. This is particularly useful for users with large, complex configurations, as it drastically reduces the time spent managing and updating button references.

Reduction in Maintenance Efforts: Manual updating of references becomes unnecessary with tags, as the tag remains constant regardless of where the button is placed. For users managing multiple pages or frequently adjusting button layouts, this feature would minimize errors and maintenance needs, making workflows smoother and more reliable.

Enhanced Usability for Complex Setups: For advanced users with intricate workflows that require precise button references across different layouts, the tagging system ensures commands remain accurate and consistent. Tags simplify the process of setting up and modifying configurations, providing a user-friendly experience even for complex setups.

Error Prevention: Since tags maintain consistent references, the risk of broken or incorrect button references is greatly reduced. This minimizes the chances of operational errors, particularly in live settings where accuracy is crucial.

Streamlined Command Logic: With tags, commands and scripts that reference buttons can be set once and remain consistent, making it easier to manage and execute tasks that rely on specific buttons. This also makes it easier to document workflows, as each button’s tag provides a clear, recognizable reference.

Usecases

Dynamic Layouts: Users who frequently reorganize layouts would benefit from tagging, as references would no longer break or require manual updating with each change.
Improved Workflow Management: For users managing complex workflows, the tagging system would streamline updates by ensuring references are consistent, regardless of layout adjustments.
Live Production Settings: In live production environments, where precise control is crucial, a tagging system reduces the risk of incorrect button activation due to layout shifts.
Remote Access: If people have integrated Bitfocus Companion in remote workflows then references through the API mean that if layout changes are made within Bitfocus Companion it doesn't break those remote workflows.

Have a look at #2387 There I go one step further and propose the separation of the button from the actions. When actions are not an integrated part of the button but are in fact called by the button press (or release or whatever), a method of naming the actions and calling them would be needed anyway. So actually I consider your feature request to be a part of #2387 Especially some of your usecases would be streamined even more with a separation, because you would not have one master button and some references but instead one script/action set and call that from different locations.

I don't think this should be considered part of #2387. While it has some overlap, this is a much smaller and well scoped task that I think is a needed follow up to #2438.
The current fallout of #2438 is that I think that reordering pages is pretty dangerous as it will very easily break existing button press references.

There is some overlap with #1676 and #2138.

My question is what we should use as the stable reference: 1) User defined 'tags'

what happens when multiple buttons have the same tag? do we trigger them all? what about for feedbacks, take the first?
should buttons be able to have more than one tag?
this feels slightly tedious/messy to make performant, but doable to make and maintain a reverse lookup map 2) use the existing controlId
user's wouldn't need to see it, anywhere we show it we can do so by translating it to the location of that control (the exception being when reimporting a page, I'm not sure how to handle that case)
when importing a page we would have to fix up the references to match any id changes, and ideally prompt for how to resolve unknowns

I have seen #2387 but wanted to provide something that is more doable in the immediate future.

I totally agree with the idea of creating scripts independent of buttons ... at the moment I am using a button as a kind of script where other buttons set variable state and then that button is the script that executes with the variable state. This means I don't have to create a set of actions for each button. BUT that is another improvement. I still think that my above suggestion is relatively easy to implement with no obvious side effects.

As for Julusian's suggestions ...

I wasn't considering multiple tags unless tags take on another purpose. This is a very specific tag for the purpose of identifying a button and so a button should only have one of these and it should be unique compared to all other buttons on all other pages. This is a reference assist and so it must be unique.

Perhaps tag was a bad choice of words. I thought about label but then that could be confused for the display text. Maybe a user-defined identifier would be a better choice of terms.

bitfocus / companion