The ability to use layers when editing/creating application steps, as you would in Photoshop or other image/video editing software, would greatly improve development of our more complex applications.
For instance, we might put all of our menu/toolbar buttons on a layer, another group of widgets on a different layer, and GUI elements on a third layer.
This is a great idea! I’ll share this with the product team.
Thanks for your suggestion,
Great idea! Anything to make building complex applications with fewer clicks is a win.
This would be a relatively large impact. It can get really messy on a step with a lot of features/objects. It could potentially eliminate for temporary resizing or moving of an object, accidental hiding of invisible buttons, etc. This could naturally help improve object snapping/alignment consistency and accuracy (less mess on a single layer). It would allow users to better organize features from an architectural standpoint but also from a maintenance/update viewpoint. It would be nice to lock layers and freeze objects without affecting their function. I would agree that a Photoshop-like layering system would be ideal. Having good visibility to the relationship of objects to layers would be nice (i.e. visual indicator on objects showing which layer it’s on) and layer management at a higher level would be essential (i.e. shuffling/moving layers or (sub-)layer groups around).
Hey Alex, thanks for sharing these ideas. I am thinking of ways to solve this because there are multiple possibilities.
What are some elements that you frequently stack? Is it just invisible buttons on top of things, or are there other ideas?
It varies of course but the more you can make it intuitive yet flexible enough for user to decide what/how to layer that would be best end-user experience I think. Grouping invisible buttons is definitely a good thing but I see grouping variables, inputs, outputs, text and really anything else as being beneficial.
Let me know if you need further assistance and insight on this!
Having better control of buttons (invisibility being the main use case) would be the most helpful, next most helpful would probably be text/input widgets. To clarify: being able to temporarily lock out everything but the aforementioned items. Master layout is great for locking shapes and such, but when you add other shapes as backgrounds to buttons/text/etc on other steps, mis-clicking on the background shapes can be annoying.
As the OP mentioned in '19, a “photoshop-style” layer manager in the app editor UI would significantly improve UI development of apps within Tulip by reducing the time wasted constantly moving widgets to access those behind them, and the overhandling and risk of error when moving well-placed widgets back to their original positions. For our development efforts I think the most useful elements of a layer manager would include (in order of priority):
- In its most basic form, a list of all widgets present on a step, sorted by z-index descending. Widgets are selectable from this list (to access widget properties on the right sidebar) and can be given human-readable names. The list can be filtered by data-type (ex. callout, button, table, variable_formattable) to narrow the list down on busy steps. Master layout steps are hidden from the list by default, or the option exists to exclude them from the list.
- Widgets on this list can be moved up or down in z-index (vs. current ability to just set to max or min z-index with “forward” and “back” buttons).
- Widgets on this list can be locked and unlocked (As schexb mentioned) to prevent moving them when not intended, exactly as current master layout widgets behave.
- Widgets on this list can be shown or hidden, to allow work on ex. background elements that are obscured by foreground widgets without moving them and having to put them back.
- Widgets can be grouped into folders to help organize apps with large numbers of widgets. Folders can be named and manipulated by the user just as widgets outlined in items 2,3, and 4.
- Widget Hide/Show behavior as outlined in item 4 carries over to Tulip Player and can be manipulated by Tulip triggers (I realize this is more of its own feature request, but if the functionality described in items 1 and 4 existed, it would open the door for this ability).
As we are getting better at Tulip and our apps become much more complex this feature is becoming less of a want and more of a need. Could we get and idea of whether this is on the radar?
At long last, this is being addressed. You may have noticed in r230/LTS8 you can now see widgets in the step tree for each step. Very very soon renaming and grouping these widgets will be coming!
I came from a Tulip customer who had app steps with 400+ widgets in a single step, I feel your pain! We are hyper-focused on making the app building experience less painful right now! Should continue to see usability changes rolling out thru the end of the year.
Keep the good ideas coming! They aren’t falling on def ears.
Great news! Thanks for updating us, glad to hear this has made it into production. Really looking forward to being able to use layers.
Will we be able to copy/paste entire layers?
Hey @Dan -
Thats the thought exactly. Take 5 inputs, group them together, rename the 5, copy all 5 from 1 step to another, use them in another app. We don’t want you to have to duplicate the same works step after step to build a simple application.
All of this functionality will continue to come in phases as the engineering work is executed on, so I can’t give a firm release number just yet on the grouping of widgets, but it should be some of the next new features you see come to the app editor.