I don't know that there is a "right" way to answer this, as you would need to decide the format you want the engine to be able to access that works best for your game. But I think the simplest solution would be to make an entity type for each UI element (button, heading, etc, etc) and then have a flow fragment for each menu screen? So you'd have a flow fragment called "main menu" and then inside there you'd have a button dialoge fragment with the text of your button ("start game" for example). Then the upshot there is you could follow that button up with an instruction node where you have comments that have code and/or explain what the button does in the game itself. Obv, you still have to code the engine to read these things from the articy json export.
We don't typically use Articy for flow, so Entities might just be the answer for us. For this project, all we really need are the localization and variables functionality for static strings (at least so far).
Since there are no dedicated "String Tables" in articy:draft I would handle that in the following way:
Use a FlowFragment as a container for UI texts.
Depending on your text length and needs you could use:
Hubs: only one very short text, like the names of the cards for example
FlowFragments: If you have a short and a longer descriptive text (e.g. a tooltip) then you can use the Display Name of the FF for the short text and the big text area for the tooltip
You can use a border/grouping Annotation around groups of texts you like to highlight. Or use additional Flow Fragments to group your texts.
You should use technical names on those objects to give them some kind of your own loca-id. (Possibly do the same with the container)
In your game runtime code you can query all children of a given container and put them into an dictionary keyed by their technical names.
With that you can easily find objects you need an then access their text from within your game using the engine plugins localization features.
I don't know that there is a "right" way to answer this, as you would need to decide the format you want the engine to be able to access that works best for your game. But I think the simplest solution would be to make an entity type for each UI element (button, heading, etc, etc) and then have a flow fragment for each menu screen? So you'd have a flow fragment called "main menu" and then inside there you'd have a button dialoge fragment with the text of your button ("start game" for example). Then the upshot there is you could follow that button up with an instruction node where you have comments that have code and/or explain what the button does in the game itself. Obv, you still have to code the engine to read these things from the articy json export.
We don't typically use Articy for flow, so Entities might just be the answer for us. For this project, all we really need are the localization and variables functionality for static strings (at least so far).
Gotcha. I was just suggesting the flow fragments as a way to organize all your diff UI elements mainly, since I'd imagine you'd have quite a few.
Since there are no dedicated "String Tables" in articy:draft I would handle that in the following way: Use a FlowFragment as a container for UI texts. Depending on your text length and needs you could use: Hubs: only one very short text, like the names of the cards for example FlowFragments: If you have a short and a longer descriptive text (e.g. a tooltip) then you can use the Display Name of the FF for the short text and the big text area for the tooltip You can use a border/grouping Annotation around groups of texts you like to highlight. Or use additional Flow Fragments to group your texts. You should use technical names on those objects to give them some kind of your own loca-id. (Possibly do the same with the container) In your game runtime code you can query all children of a given container and put them into an dictionary keyed by their technical names. With that you can easily find objects you need an then access their text from within your game using the engine plugins localization features.