I am currently facing an issue while developing a custom widget in Tulip and would greatly appreciate your insights and advice.
I am attempting to create a custom input box widget that, when clicked, displays a dropdown menu with several options for the user to pick from. The challenge I am encountering is related to the size constraints of the dropdown menu. Specifically, Tulip requires that the size of the dropdown menu be defined within the borders of the widget itself.
However, I have noticed that this limitation does not apply to certain pre-built widgets provided by Tulip, such as the Date and Time Picker. In these cases, the widget’s size is defined by the input box, but when clicked, the calendar dropdown opens and extends beyond the widget’s boundaries, maintaining a consistent size regardless of the input box dimensions.
I want to achieve the same functionality with my custom widget, where the dropdown menu can “leak” outside of the widget’s boundaries and display at a consistent size, regardless of the size of the input box.
Is there a way to implement this behavior for custom widgets in Tulip?
Any examples or documentation that could guide me through this process would be highly appreciated.
I totally agree, that this is a big limitation of custom widgets.
I often felt the need to expand the area of the widget temporarily.
Unfortunately this is not possible yet.
The reason is, that custom widgets are embedded in an iframe. This is for security reasons, so they are not able to influence the original page more, than the boundaries allow (the own sandbox). It can also not read and wirte variables, as long as they are not provided by the App (parameters).
If you want to provide more space, you can oversize the iframe, however you have to decide, if it is in front or behind other widgets around. It can not overlap any inputs or buttons, because they are no longer usable then.
I would love if someone proves me wrong and finds a solution
@Horesh : If i understand you correctly you can simple use your custom widget as separate layer. For example drag your widget at the full size of your app page and then set the tulip fields at the widget. I have tested your behavior in my pdfwidget : set this as background, add tulip fields and use both type of fields. @thorsten.langner : in my test the custom widget the tulip fields are completly usable.
This only applies, when the custom widget is behind the TULIP Widgets. If a TULIP Button is behind the custom widget, it will not be clickable… (the custom widget overlaps it always, also if it is “empty”)
e.g. you can not make a modal as custom widget, because:
if the reserved space for the custom widget is in front, everything behind it is never usable
if the custom widget is in the back, the modal will be behind the widgets and not readable (and it will not block the access to the widgets)
if the custom widget is to small, the modal will not appear fully…
Okay but why can’t you set the widget behind the tulip widgets?
" * if the custom widget is in the back, the modal will be behind the widgets and not readable (and it will not block the access to the widgets)" What do you mean with that?, i thought your origin question was about a dropdown menu innerhit in your tulip app… so whats the issue?, if i set up my widget behind the tulip widgets and i define a for example clicklistener for my custom widget i can trigger this and the tulip widgets are placed on another room at the custom widget… or did is miss something?
If you want to achieve the second screenshot, it will ALWAYS overlap the inputs, also, if the dropdown is collapsed. (The iframe will still be there). So you can not type in your name…
The Idea is, to have a widget, that only overlaps the other space, if needed (e.g. activated or expandet…)
It’s simple datalist instead of select i guess…
<datalist id="preQuestions">
<option value="Was soll ich als nächstes tun?"></option>
<option value="Welche Meilensteine erfordern meine Aufmerksamkeit?"></option>
<option
value="Gibt es Risiken oder Probleme, die ich ĂĽbersehen habe?"
></option>
<option
value="Wie kann ich die Teamleistung verbessern oder motivieren?"
></option>
<option
value="Welche Best Practices gibt es fĂĽr ein Projekt wie dieses?"
></option>
<option
value="Wie kann ich sicherstellen, dass das Projekt im Zeitplan und Budget bleibt?"
></option>
</datalist>
I tested also a standard select… it works also in tulip player…weird. both type of “Options” should be available in all browsers… we use edge what do you use?
You are right,
html-elements with inherent spill (tooltips and selects) seem to have the ability to overflow the iFrame, I guess it would even overflow the player window border…
But as soon as you build something by yourself, and you want to hide and display it, you will come in trouble (as with the standard widgets as well.)
Hi, I’ve created a custom widget with specific behavior, but I’m facing an issue with overlapping elements in Tulip. When the custom widget is placed in the front, it blocks access to buttons or elements behind it. However, if I place the custom widget in the back, its options or data become inaccessible. Could you suggest a way to resolve this?
The overlapping behavior you are seeing is to be expected, as the Custom Widget is an iFrame and there is current no way to conditionally expand iFrames or be able to be “click through” them.
As mentioned on this thread, Custom Widgets with built-in HTML drop down selectors should correctly “pop-over” other elements, but that is it.
From a development standpoint, it is technically possible for the Tulip Team to consider allowing trigger logic in Tulip to adjust the dimensions of the iframe or completely hide or disable the iframe, but that kind of flexibility definitely adds complexity to the app editing and app validation experience, and is not something currently being considering in the near future of a priority. However, we will log it as a request in our backlog!
Also, do you mind sharing what use case your custom widget is solving? Wondering if there is something we could consider adding natively into the platform here as well (as a native widget for example).
The custom widget addresses critical navigation and space management challenges
Use Cases Solved by the Custom Widget
Consistent Navigation Across Steps
Dynamic Content Based on Context
Space Management
Ease of Maintenance
Additional Considerations for Native Integration
Given these use cases, there are a few considerations for integrating a native widget into the platform:
Standardized Navigation: A native widget could offer standardized navigation controls that developers can easily integrate into their apps, ensuring consistency across all applications.
Dynamic Content Handling: Allowing the native widget to handle dynamic content based on app state or step would make it more flexible and useful.
Customization Options: While keeping it simple to use, providing some level of customization (e.g., choosing which options to include in the menu) would increase its adaptability.
Space Efficiency: A collapsible menu or dropdown style widget that can hold multiple navigation options would help manage space efficiently, particularly in apps with limited header space.
Providing a detailed explanation to the user about the requirements for resolving the issue with overlapping elements in Tulip,
Requirement Explanation
Custom Widget Behavior:
The custom widget which developed has a specific functionality that is essential for my application. It needs to be interactable and visible to the users when required. However, due to its placement, it is creating a conflict with other UI elements in the Tulip interface.
Overlapping Issue:
When the custom widget is placed in the front layer of the interface, it obstructs other interactive elements such as buttons or input fields. This makes it difficult or impossible for users to interact with those elements, leading to a poor user experience.
Conversely, placing the custom widget in the back layer ensures that other elements remain accessible, but this action renders the widget itself non-functional or inaccessible, defeating its purpose.
Need for a Balanced Solution:
The goal is to find a solution where the custom widget can coexist with other UI elements without hindering their functionality or accessibility. It should maintain its visibility and interactivity without blocking essential elements in the interface.
Possible Approaches:
Dynamic Visibility: Implementing a system where the widget becomes visible and interactive only when needed (e.g., on specific user actions like hover or click), ensuring that it doesn’t obstruct other elements by default.
Layering Control: Using z-index or similar methods to dynamically adjust the layer position of the widget based on user interactions, allowing it to move to the foreground or background as necessary.
Transparent or Click-Through Areas: Designing the widget with areas that are transparent or allow clicks to pass through to underlying elements, thus preserving the functionality of both the widget and the elements behind it.
Positioning Flexibility: Allowing the widget to be draggable or resizable so that users can reposition it as needed, keeping other elements accessible.
Modal or Pop-Up Usage: Utilizing modals or pop-up windows for the widget’s detailed options or data, which can overlay the main interface temporarily without permanently blocking other elements.
This is a standard tulip dropdown. The custom widget contains only a button as i got from your example.
The custom widget button covers and blocks only a small amount of the tulip dropdown so this would be a ux question about place the widgets in the right order.
If you were interested in custom widget dropdowns there are plenty of samples… such as standard, fieldset, datalist etc…
