Some ideas for the front-end app structure panel

I have seen that the Wappler team is working on a redesign of the graphical interface in many areas and it occurred to me to see that the front end part has not received some love for a long time, so I bring some ideas to the table that may be of interest.
I don’t really have much time these days so sorry I didn’t use any professional tools to make the image, which I did in 15 minutes using an iPad, but I think it serves to represent the idea in general.

  1. The first thing I thought was important to add was a search field, sometimes we have many columns, forms, etc. on our site and it becomes a bit tedious to search with the mouse or in the code view. Personally, I am working both in code and using the visual interface of Wappler depending on the time I have.

  2. Perhaps the most profound change in my proposal is to separate what are items that correspond to data, components, framework and personally I would also add variables, in this way I think we can order better and when editing we can access more fast. At this moment I usually use sections to separate one from the other and put for example all the server connects together. Next to the search field I put two buttons that are used to expand or compress all branches and sub-branches.

  3. Another change that I propose would be to color the icons as it was done with those of server connect, it may not be a very important change but I think it could help, for example, to find a table or a form more quickly.

Please feel free to constructively criticize this proposal and suggest other changes that you deem necessary. My idea is not to criticize the application but to help everyone to use Wappler in a better and efficient way.

1 and 3 would be good additions.

With this one I wouldn’t separate. The components should stay in their place inside the tree because that is where they actually are and they might have direct relation with the parent, sibling or child node so I want to have easy access to family nodes.

On the other side, instead of separating and removing them from the tree I would suggest adding them as a direct link that takes the user to the specific node.

But users should still be able to navigate their tree and find their components because that is where and how they created them ergo that is where they would expect to find them.

4 Likes

This would certainly be very useful. I think it could work in two ways.

It would be very useful if the search term would highlight the matching component(s) in the tree, and refine the filtering as more is typed.

Alternatively, or ideally, additionally, the search could work in the same way as the current filtering works for Available Actions, where only matching items appear. This is an excellent implementation - eg I can search for the all server connection actions or specific actions:

image

1 Like

Full solidarity with this. Sometimes the element tree grows so large that referencing certain elements might solve the problem.

It is worth noting that the tree of elements is one of the strongest advantages of Wappler. It is due to it that it is possible to quickly navigate the project and effectively build app the structure. Therefore, I agree that it is worth upgrading it very carefully. But it makes sense to improve the tree navigation tools, it would give a very strong increase in efficiency.

One of the oldest requests to improve navigation was a request to add a search bar and the collapse / expand tree buttons that are in the binding window:
41

To the main panel:
42

This is the simplest improvement, which would allow for a huge improvement in tree navigation. Especially buttons for collapsing / unfolding the tree. Very often (unbearably often) the tree opens up so much that it takes an incredibly long time to scroll through it to find the right element. The simplest folding of the tree would solve this problem, but this function is only available in the binding window…

3 Likes

As for the search bar, I personally would prefer a tree element filter. It works very simply and clearly: select the modal window in the filter and only the modal windows remain. We select the forms and only the forms remain. Personally, I think it would work much better than search. Faster, more reliable, and very flexible.

+1 for a search tool.

May not be a popular suggestion but I’d love to see the Dynamic & static events/attributes perhaps as tabs at the top of the properties window rather than hidden as a expand/close list near the bottom. I loath having to scroll down every time to reach those.

I already do something similar to that by simply using sections and giving them an id.

Screen Shot 2021-06-07 at 9.03.21 AM

1 Like

I used to do that too, but then I refused. This is bad practice, I think. The “Section” element is a full-fledged html tag, with all the ensuing consequences - it gets into the DOM and also into the route path to the nested elements when the binding is done.

This question was also raised quite a long time ago and an excellent proposal was formulated to add a new element to the AC side, which would allow grouping elements in the tree (as shown in the screenshot above), but at the same time, which did not create absolutely no problems for the code. The implementation is extremely simple - this element would be an ordinary comment in the code, with special marks that the Wappler would recognize and display it in the tree visually.

The idea was supported by everyone. George confirmed that this is quite simple to implement. Implementation was hindered, apparently, by more serious tasks. It would be great to revisit this idea again.

An element for grouping in a tree, which would be a regular comment in the code, would be an amazing tool for improving navigation in the tree and increasing the order in the structure of the application.

2 Likes
1 Like