I think that the option to dynamically hide a button/text box/drop down/etc. would be incredibly helpful in Tulip development. It would lessen the duplicate steps you would need to have to have a button in the same place as another button, as well as removing having to redo any work you do to one step and needing to add it to the duplicated step.
The functionality is somewhat there already with the “enabled state” option, it could be reworked to either hide the object entirely or leave it there but not enabled
Also find discusstions here:
Keep custom widget from blocking click when hidden? - Developer - Tulip Community
Hide button on Steps, click on print button - Support, Troubleshooting, & Help - Tulip Community
Hide objects like single select - Support, Troubleshooting, & Help - Tulip Community
Hide button in tulip - General - Tulip Community
This is a frequently discussed feature. I wonder if there is really no request before.
I totally agree and think it could be relatively easy, since we already have the “disabled” on buttons…
3 Likes
This would also allow to create simple “pop up” windows to confirm deletion for example or better dynamic navigations where user would only see relevant buttons. Great idea, it would help a lot!
Hi @Bryce.dahle and others who posted here, thanks for surfacing this request. Would you be able to share some screenshots and explanations on what you would like to dynamically show/hide, under what conditions, and what duplicated steps would be eliminated?
More details around the general use cases would be greatly appreciated and help us build the right feature. Thanks!
Below is a snip of the app I’m currently building for our facility. Having the ability to “Stack” the start and finish buttons that match up would make much more room for other options and make the screen feel far less busy. Currently I have the buttons usable based on the “Scan Status” and every time that the status changes, all of the colors of the buttons and their text is changed based on what they should see for that status. (if status is “Not Started” then only Start button is visible and clickable, if “Started” then Finish, Pause, Send to Third-Party, and Remove from Line buttons are clickable and visible, Etc.)
2 Likes
Hi @shep,
I can’t provide an actual screenshot yet (for several reasons).
But I made a sketch for one of our use cases:
Imagine the blue sections of the step will be always the same. But the green one (execution) is different. This depends on the actual task.
It can be a text input, a number input, multiple number inputs, a checkbox or any combination of these…
It is really pain to copy this whole step 10 times to provide a whole step for each scenario.
This also results in a lot of maintenance ( all triggers in all tables etc., design changes, …).
You could simply hide and unhide the inputs for each task (and they can overlap, if they will never appear together)…
Another use case is to provide a different Button, depended on the logged in user or a previous selection. This button can have the correct label for where it is navigating to. (You can’t change Button descriptions.)
Third Use Case:
Sometimes the space is limited. You could overlap widgets, that are meant to be used one after the other. After the usage of one, it can be hidden and the next one can appear. You could Populate inputs with next and previous buttons on one step, where you don’t need to worry about step level triggers to fire again.
You can switch between hardcoded text widgets, without managing variables to write texts in between them.
You can actually build modals, that appear and disappear
You can build a full screen image in any trigger. Currently you need the image widget, that destroyed the image, because it does not respect its aspect ratio!
You can build a pop up camera widget (button “take picture” unhides a full screen camera widget) without any step navigation (you can place it to still see the context and don’t need to worry about step navigation triggers)…
You can show and hide Storage locations or manufacturing resources as they actually are (full container, empty container, no container)
And I’m sure there is tons of more use cases…
2 Likes
@thorsten.langner @Bryce.dahle thanks so much for providing all this detail around your use cases. Making Apps more dynamic and conditionally based is something we are actively investigating. Our hope is to reduce the redundancy required, such as duplicating steps to achieve the desired behavior. We will keep you posted on this!
2 Likes