- Issue created by @lauriii
- Assigned to lauriii
- 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
Fascinating! 🤔
So, do I understand correctly that component instances should not only have a uniquely identifying UUID, but also optionally a user-defined label/contextualization/badge?
If so, important consequences:
- when using asymmetric translation (see 📌 Allow Experience Builder fields to support Asymmetric and Symmetric translations Needs review ), that badge would not be showing up in the same language as neither the UI nor the content being edited, but in the original language. Unless the badges themselves would be translatable too. But if that's translatable, that would complicate the UX?
- AFAICT the badge makes sense based on the location in the tree more so than the contents of the components? If so, then the badge should be stored as part of the tree structure (
tree
→\Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure
). Or … if it depends on the contents, then it should be stored as part of the props values for each component in the tree (props
→\Drupal\experience_builder\Plugin\DataType\ComponentPropsValues
)
IOW: this triggered new data model questions 🤓
- Assigned to Wim Leers
- 🇫🇮Finland lauriii Finland
Unless the badges themselves would be translatable too. But if that's translatable, that would complicate the UX?
We could make the label translatable. I would imagine the translation would be added just by editing the label within the translation so I'm not sure how that would complicate the UX?
AFAICT the badge makes sense based on the location in the tree more so than the contents of the components? If so, then the badge should be stored as part of the tree structure (tree → \Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure). Or … if it depends on the contents, then it should be stored as part of the props values for each component in the tree (props → \Drupal\experience_builder\Plugin\DataType\ComponentPropsValues)
I'm not sure I understand what would be the implications of storing this in one or another. Could you elaborate on that? 😇
- Assigned to lauriii
- 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
so I'm not sure how that would complicate the UX?
It'd mean this metadata (it's not actual content) would have to be translated too.
The complication is that the UX would have to design/signal in some way that a component badge is not yet translated, and should nudge the content creator to translate it.
I'm not sure I understand what would be the implications of storing this in one or another. Could you elaborate on that? 😇
I was actually only talking about semantics, not implications.
The implications would depend on what choice the Site Builder made wrt translation, see 📌 Allow Experience Builder fields to support Asymmetric and Symmetric translations Needs review . Asymetric translation would mean the components would be different per translation, which would mean there is no need to translate then the component badge.
- Assigned to Wim Leers
- 🇫🇮Finland lauriii Finland
It'd mean this metadata (it's not actual content) would have to be translated too.
The complication is that the UX would have to design/signal in some way that a component badge is not yet translated, and should nudge the content creator to translate it.
Why do you think there would have to be a nudge to translate it? I see the label merely an enhancement for content authoring. I wouldn't consider it a big deal if it's not translated to the target language because it's not presented to the end-user. However, they should have the option to do that. If a designer created Figma files for different languages, I doubt that they would translate the layer names unless there was a good reason to do so.
- Issue was unassigned.
- 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
I see the label merely an enhancement for content authoring.
I'd find it jarring if everything was in Dutch but the label/badge was in French. Especially if it wasn't marked in a way.
- 🇫🇮Finland lauriii Finland
There could be an alternative approach which is to just not display the original label and expect it would have to be set again in the new language. The reason I'd consider this inferior is because if you see the original language, at least you can put it in a translator and come up with a translation.
- Assigned to lauriii
- Status changed to Active
about 1 month ago 1:18pm 8 August 2024 - 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
AFAICT this was blocked on ✨ Component name badge above component preview Active . But I don't think it's blocked on … anything else? 🤔 Except for design!
So: assigning to @lauriii for visibility.
- 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
A flaw in the current implementation (which dates back to May, around the very start of the
0.x
branch, when there were zero designs still — so it's SUPER COOL that you anticipated this, @jessebaker! 😄) is that it basically reservesname
SDC prop name. That means no SDC that usesname
as the prop name can work — becausename
is stored alongside the values for SDC props in themodel
that is sent to the server for previewing etc.As of 📌 Create an Open API spec for the current mock HTTP responses Fixed , this problem is also clearly present in the sample response that is in
/openapi.yml
— the full shape ofmodel
is not yet defined in there 😅@lauriii, when designs are available, please assign this to @jessebaker so he can articulate how he wants to deal with 👆
- 🇫🇮Finland lauriii Finland
Discussed with @balintbrews and agreed that we can work on this without designs based on the assumption that the name will be edited inline in place of where the label would be displayed. This can be triggered by double clicking the label, or by choosing "Rename" action from the contextual menu (which is behind right click).
Some screenshots for inspiration:
- Issue was unassigned.
- 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
#10 sounds great! 🤩
Is this in scope for 🌱 Milestone 0.1.0: Experience Builder Demo Active ? If so, please mark it 🙏
- Assigned to Utkarsh_33
- Merge request !240Resolve #3460958 : Allow Content Creator to name component instances for the specific context → (Open) created by Utkarsh_33
- Status changed to Needs work
6 days ago 11:19am 2 September 2024 - 🇭🇺Hungary balintk
We discussed with @utkarsh_33 that we could enhance this by adding the rename functionality to two more places:
- As a menu item in the context menu (when you right-click the name tag);
- The layers list in the left sidebar — with the same double click interaction.
- 🇬🇧United Kingdom jessebaker
Minor thing, but as per https://www.drupal.org/project/experience_builder/issues/3459249 📌 Allow opening the contextual menu by right clicking a component Needs work it should be possible to right click directly on a component, not just its name label.
- Issue was unassigned.
- Status changed to Needs review
5 days ago 8:03am 3 September 2024 I am not sure who is the right person to review this as this is not a priority but it now takes care of
The layers list in the left sidebar — with the same double click interaction.
.
I also added the test for the above scenario.I think this could still be optimised by moving the common logic between the two components ie:-
NameTag
andTreeNode
and i tried that as well but there was problem when i was editing the name in menubar content.If we need to do that then i might dig more into the problem but if we are ok with the current implementation then it's ready for an initial round of review.- Status changed to Needs work
3 days ago 1:49pm 4 September 2024