New Design for Server Connect and App Flows Editors

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.

1 Like

Also, wanna point out some tiny design issues, just in case.

  1. Vertical alignment

  2. Margins

  3. Space beetween cube icon and label text

  4. 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 :slight_smile: 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.



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:

Screenshot 2021-10-28 at 19.41.56

Also, an empty else is step is no longer added by default. Now you can add it using the context menu if/when needed:

Screenshot 2021-10-28 at 20.24.55


I feel very sad that the new boxed design was revoked. :disappointed:

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. :+1:t3::blush:

1 Like

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 :slight_smile: 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:

  • Leave just the improved tree design only
  • Add an option to toggle view to blocks design
  • Completely replace tree design with blocks design

0 voters

As referred in Blocks design and toggle option

1 Like

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”.


Aggreed @JonL!

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.