we have API that have quite extensive nesting - we need to increase the width to be able to read the APIs better and not have to scroll horz too much - just vertically.
if it stacks horz on increasing width - it will be difficult and painful to adapt to this change.
This is the critical for me personally. I donât feel the tree needs any updating, but obviously others do, so being able to maintain the current tree experience is great.
The regular tree will stay as it is now.
George, thanks for sharing with us. I like the new design! Definitely more clear and accurate.
I was working with a new panel a bit. And I have to say, even in its current form, I like it much more than the old version.
Only struggle I have is âelseâ boxes, hiding somewhere in the right part of the screen.
Everybody already talked about it, so I will not be original.
I certainly wonât use horizontal block placement. At the same time, I work on a 1920px monitor and I like to set a large panel width. I would prefer if at any width the blocks and nodes do not go to the right, but remain under each other.
Of course, Iâm not against the horizontal layout option, if itâs convenient for someone. But we definitely need a setting / button that turns it off for the user entirely.
I am still not sure about the additional arrows near the âexecâ, âthenâ etc labels. The collapse/expand function can be performed by clicking on the label itself. I understand that it is more obvious with those arrows, but visually they are distracting. Maybe if you donât want to remove them, then at least make them gray?
Also I am worrying about how the announced âswitch caseâ would be implemented in this design? I mean, it would be strange to move âexecâ, âthenâ to the vertical labels and then later on change it back to the horizontal nodes. So maybe we should already consider it (and other future stuff) in the design layout.
Also, wanna point out some tiny design issues, just in case.
Vertical alignment
Margins
Space beetween cube icon and label text
Way of connecting âthenâ and âelseâ blocks.
(I know it is on purpose. I just think It better another way. IMHO)
Thanks for all your feedback 
Weâve simplified and improved the design in the latest update, make sure to check it
We got rid of the boxed design, based on users feedback.
We got rid of all steps nodes in the tree. Also added a left border for the selected steps there for easier navigation.
Before:
After:
We styled and optimized the arrows and other icons in the tree.
We added new options in the context menu (@sid) , such as: duplicate, delete, enable and disable steps and output, collapse and expand all child nodes:
Also, an empty else is step is no longer added by default. Now you can add it using the context menu if/when needed:
I feel very sad that the new boxed design was revoked. 
It seems like the community agreed that it is the right direction. That just needed a little more tuning.
I worked with it for a while and began to love it even in the current form.
The boxed solution looked very nice in the examples you provided I must admit. But when we started to work with them in our real case scenarios it was too much. Instead of helping readability it was hindering it by bloating the UI. Our brains were processing too much info.
I agree, I was feeling too much comfortable with boxed design, and now with new update I just feel like if I were in an outdated version.
Please keep in mind that this Wappler project is actually VISUAL, LOW CODE, so the visual is the most important part of all this.
I really donât understand why you guys took a step back.
Maybe for complicated scenarios many users were confusing, but the readability with not big projects were just perfect!.
Please considering again the switch.
I agree with you. For non complex api it is nice design.
Switch would be appreciated.
I just wonder why the properties panel is still not 100% width:
It would help a lot if the fields would be wider.
That context menu implementation is at par with what weâve come to expect with Wapplerâs powerful visual and open development workflow. Great work guys. 
I agree, the context menu is super useful and leaving out an empty else is great. It would be even better, though, if an elseif could be added to the context menu to satisfy the switch type usage.
Thatâs coming as well We just couldnât make it for this weekâs update.
Iâm also a little disappointed the new design has been shelved. I think the idea went off at a bit of a tangent with the horizontal boxes; perhaps this has resulted in abandonding the ideas.
Having said that, Iâm very grateful to @nickneustroev for all his work on this and his inspiring ideas. Also, I donât think these efforts were wasted. While the main ideas have not been implemented, some critical ones have been and some really useful improvements have resulted - in particular the reduction in unnecessary clutter from the SC editor and the right-click options.
Perhaps more changes inspired by this thread will follow in due course.
Well lets do a poll:
0 voters
As referred in Blocks design and toggle option
Maybe the âExecâ step in the Repeat action is also as redundant as âstepsâ was. I canât remember if the While action also has the âExecâ.
I voted to just leave the improved tree. Having two versions would make tutorials very confusing.
Yep. I voted that for the same reason and not personal preference. I think the team could be shooting their toes here if they add the two options.
I do see a full redesign as to how we build server actions and the UI in the future with the flow libraries I mentioned before. Something for Wappler 6 or 7. That would make the whole thing more visual and would be very appealing to nocoders.
But if we are keeping the good olâ way of presenting the flow as an indented tree(same as any code view) they should focus on giving the best experience in that area.
