Merge App Structure and DOM views

Feature Request
#1

Would it be possible for the tree to recognize all elements even if it doesn’t translate to a pre-defined Wappler element.

I assume that you guys are working hard to try to add as many as possible. But sometimes there are so many custom options.

I would be happy with just a generic node that allows minimum customization like id and class.

Say I have a generic body(app) and and three nested divs inside the body like this.

Body(app) -> Div(empty) -> Div(custom class) -> Div(Wappler container)

It would be great to see in the tree the following

App
|_ Div (generic)
|_ Div (generic)
|_ Container

And when clicking on the generic div I am able to view/change the class/id from the properties panel.

Same to the rest of html elements that are not recognised as Wappler elements

Div (generic)
Input (generic)
Form (generic)

Also scripts, css, etc.

To summarize. It would be nice to see absolutely all elements that belong to the page in the tree so we don’t have to jump so much into the code view.

It would facilitate also the conversion of templates for wappler use. Seeing at a glance the elements that need conversion would be a time saver.

Using readymade Bootstrap themes?
Keep focus on parent app-tree element, when visually choosing an enclosed child dom-tree element
#2

Everything on your page should be selectable in the DOM Panel? Unless I don’t quite understand your request.

#3

Hi @JonL
As Brad points, the DOM panel does exactly this :slight_smile:
App Structure only shows the app connect and Bootstrap 4 components in your page.

#4

I believe I made an awful job at explaining myself. I will come back at this when I get home to my computer :slight_smile:

1 Like
#5

OK. I’ve changed the name of the feature request.

Basically I would love to work in a single view with all properties available. I don’t want to be switching panels.

Some App structure components properties are not available in the DOM view and some DOM properties are not available in the App Structure view so I end up clicking too much between them. Also if you are working with the App Structure view and have selected an item if you go into the DOM view it will not remember your selection and you have to look for it. Not that I’m raising this as a bug because I believe from a UX perspective a merge between both views would be the way to go in the future.

Maybe that view is too advanced for some users so I would add a small header in the panel that has a dropdown with some filters that can be un/checked. i.e “Only Components” and another hide/show filter for the properties sections. So people less advanced don’t get bloated with options.

Maybe also add a small icon before the element also for App Connect components or BS4 components.

I know this is not a quick thing that can be done, but it would be great for a future review of the properties panel.

To summarize: A single tree of truth as right now we have 2 trees of half truths. Bonus: Several filters that allow the tree to be as simple as possible for basic users or bloated for advanced users.

6 Likes
#6

+1 one view would be great! Maybe with the ability to hide/show the DOM elements?

2 Likes
#7

If you just stay in the DOM view don’t you have the same access as showing everything? I find I almost never have to switch to DOM view unless I have to fix something I screwed up. Just curious.

1 Like
#8

I am afraid you don’t have the same access.

#9

There is a very strong choice to separate App Structure from the DOM from the beginning of Wappler.
It was based on all our experience in components design and building and the feedback we got in during the initial beta.

App Structure is a high level overview of your component hierarchy and major building blocks. It that gives you a great overview of your app and its functionality.

Each component in it has its own properties - just like any component building system.

The exact DOM on the other side, altought it has some similarities, is just a detailed implementation.
When dealing with high level over view you don’t want to be bothered with 20 nested DIV’s, you want to see the single component. and that is what App Structure is.

For all the detailed underground work, you switch to DOM panel. But that is a bit more like looking at separate bolts instead of the engine and the whole car :slight_smile:

So when you want and need the details, you go to the DOM panel. But normally you will just stick to the App Structure as you are not much concerned about the details, but just want a higher level view of all the components, working and hierarchy.

1 Like
#10

I imagine there was a huge design decision behind that. That is why I mentioned that I knew that it wasn’t an easy change. To sell and to implement.

I do feel however that a single view with appropriate filters could accomplish the same but giving the flexibility of not having to break focus to move to another view.

In my case I work always with split view, App Structure and DOM view.

That means that I have 2 sets of 3 views:

a) Design, code and App Structure
b) Design, code and Dom Tree

Focus is broken each time I have to move between sets as it’s not only moving the mouse and clicking a tab. It’s moving mouse, clicking tab, look for element, select it, recall information from previous set, make changes, verify by clicking back you recalled correctly, etc

For me it is quite the focus pooper.

I would love to work only with one set that has the single source of truth available at a glance. Design view, code view and tree view. If I click on any element of any view it will highlight the same elements in the other 2 views. And all app connect components and html properties would be available for that element in the properties panel.

The level of detail of the tree and the properties panel could be controlled with filters so nobody(basic, intermediate and advanced users) feels left out.

IMO that would improve building focus.

Anyway this is just me presenting the business case. Deep in my UX/productivity heart I know it is a good one :wink:

2 Likes
#11

I do like the single focus view idea and having some kind of zoom in maybe.

Something what Sketch and Figma (and event photoshop - bah - with their smart components) has with components, that you can break up / zoom in by double clicking on going into a “parts” view.

We were actually thinking of implementing something like this in design view.
As design view is currently actually the other way around :slight_smile: it allows you to click on every detailed DOM element - not only on components.

Keep the ideas coming, we are already gathering ideas and feedback for a larger App Structure rewrite - after we get all the other major parts that we have planned :slight_smile:

2 Likes
#12

Keep App structure separate from DOM view. I’m part of the category of Wapplerions who understand web technologies and how it works, but not good at working at DOM level. What I love about Wappler is staying true to what it claims to be (visual tool)!

I’m not sure how much you gain by merging both these, but you will lose a lot if you do so!

1 Like
#13

Care to expand on this? Why would I lose?

#14

App structure (simple) and DOM (complex) are separate now. Merging them both will make it complex unless the merge still has a way to keep these views separately.

#15

I totally understand your concern.

If you read again my posts you will see that I mention that some kind of level of detail filters would be needed so nobody feels left out.

On the other side I wanted to bring some light about the DOM tree as there seems to be some confusion about it. The DOM view is not complex per se. It is just a view that offers two things mainly:

a) A tree view of all the elements in your page
b) Access to some additional html attributes per element

Those two things are not complex at all. Having access to them might help you when working with 3rd party libraries. But having access to them don’t make things more complex. On the contrary it simplifies the workflow for those that need them.

So lets call it that it might add unneeded information for those that can work just with the App Structure view. And for that I proposed the filters. You can have a simple view or a detailed view.

2 Likes
#16

Thanks for taking the time to explain @JonL. Love your idea, and the Wappler UI will become more simplified for a better ux. Cheers!

2 Likes
#17

The more I delve deep into bootstrap based designing, I find constantly shifting between the app-tree & dom-tree quite tiring as the app-tree keeps on losing focus.

I can now greatly appreciate the need for a better tree-view.

I have also created another related feature request which can be a quick win to solve the app-tree losing focus here until we get a better tree view in wappler.

I literally started exploring other bootstrap visual editors like pinegrow to see if I can design easily there, and use wappler only for app-connect, but came back to wappler with hope!

1 Like
#18

Hi @George,

div & para both are block level containers… div to group elements, para to wrap para text

I was wondering why para is available as a component in app-tree, while div is not? I just wanted to understand the reasoning behind this, just to make sure I’m not missing something…

Wouldn’t it be better to have div as an app-tree component, so that it shows the nested content clearly?

Especially it would be easy to apply all the generic properties like spacing, sizing, border, colour etc? See below sample content under dom-tree vs app-tree, and why it’s not very intuitive

image image
I could understand why span tag & other less-frequently used container tags ended up in the dom-tree, but surprised to see div ended up there!

#19

This has been discussed quite a few times already.
App Structure is NOT a DOM panel and we are not planing on making it a DOM panel, it shows only the App Connect and Bootstrap 4 Components.
A div element is not a Bootstrap 4 component, same as span and many others.

If you want to work with regular HTML elements (not App Structure or BS4 components) just use the DOM panel.

2 Likes
#20

:roll_eyes: