Redesign concept for Properties Panel of page elements

Feature Request
#20

Well that look great! Seems you solved the problem nicely!

Tabs look also in style :slight_smile:

Only the General / Visual / Dynamic / Static is a bit unclear.

What is the difference between General and Visual? Isn’t it a bit confusing where to find what?
As I understand from the initial post is the Visual is just with the device sizes above, but that is why we have the main device sizes - as you switch to that device and then design everything for it. No need to overwrite it locally, we have done this before and it was only confusing.

Furthermore Dynamic and Static:
We actually have 3 things: Dynamic Attributes, Dynamic Events and Static Events
Static attributes are usually what you see in the General

1 Like
#21

I Like the Add new and Favorite, but I don’t think copy from will be very much used - and copy from what? Other Dynamic Attribute?

I know you keep promoting the idea of more code areas, but the think is that in those data pickers - 99% of the cases you are just picking one dynamic data field and that’s it. Simple direct data binding.
There is almost never need for complex expressions. Highly that you have to add a formatter only.

And in those databinding cases the user only occasionally want only to prefix and suffix the data binding with a string. Like image path prefix.

So this is why we interoduced the buddles - there you can choose data binding and add simple text before or after it. Instead of writing:

some_variable + '/'+othervariable

People can use the picker and just add strings between the bubbles without thinking of quotes and stuff. You don’t know how many users have trouble with simple expressions and they forget quotes all the time - resulting in errors or simply empty data - which is very difficult to track down.

But I do understand then some code savvy users, do like to work more in code view. So maybe we can add that as global option - which view you prefer to be the default design (with expression tags) or code view.

I also understand the need to be more in the inspector directly. I like your toolbar with the pickers - something like this was the idea indeed. Only on UI’s with a lot of inputs - it might be an overkill to place such a toolbar on each input.

2 Likes
My personal impression of Wappler after 2 years
Code First Approach
#22

Awesome! Glad to help.

My initial thought was that Visual tab will scroll you to the first sector, when you configure design. For example, in this case it would be the Spacing sector.

image
image483×582 8.05 KB

But you’re right. There is no much need to separate them, it could be just General.

I must clarify. I suggest that additional panel with device buttons will do exactly the same that current main device buttons do.

Only reason for it is that when you configure some elements that have different visuals for different devices, you need to change the selected device a lot and you want to do it quickly. So if there would be an exact copy of these buttons right here in the properties panel, it would save a lot of time. That’s all.
Yes, shortcuts keys are helpful when you want speed, but buttons will be handy too.

And I assumed that you don’t want to see these buttons always, but only when you are working with “design sectors” of properties (Layout, Spacing, Display, etc). But now I’m not sure, because most of the properties panel is about layout. :slightly_smiling_face:

Maybe call tabs Attributes and Events instead? It even can be just one tab for both of them, I just don’t know how to call it better.

Inicially I had only one purpose about this tabs – to quickly go to the bottom of properties panel, to edit Attributes and Events.
So I just realised, I don’t need a tabs/links actually. :grinning:
I just need one button, that scroll me to the bottom (or the beggining of the dynamic attributes) or back to the top.
I feel that most convenient place for it is here, but it look strange.
image

#23

Yes - we were wondering exactly the same - should those be quick selectors that scroll down to the right section, or content switchers that show the UI content properties for just that category.

The second one seems cleaner - otherwise you still have do do a lot of scrolling in a large list, well you will have the quick navigation on top - but still the list will be long as it is now.

#24

I think it would be best if it would be instant “go to position”, without waiting of automatic scrolling but also without hiding the content of another tab.

That would mean that users can choose: click the tab or scroll manually - based on what is faster and more convenient for them.
Also that would mean that you can still see both dynamic attributes/events and visual properties at the same time. Why force to switch between them when sometimes you can edit all at once right here.

#25

You can’t imagine how happy I would be if it will be implemented!
It would literally give a second breath to my Wappler work.

Not sure about this number. :slightly_smiling_face: In my projects I estimate it maybe at 50%. And for the rest 50% working with it has been a struggle. Too many scrolling, clicks, opening/closing code panel, copy-pasting and other inconveniences.

That is true and it is indeed a comfortable thing to do with bubbles.

I believe you, it must be a real problem for many users indeed. And therefore - real problem for you, as you need to respond to topics caused by this errors and investigate it.
But solving problems by causing problems for other users is not a good way either. There must be a conclusion that is comfortable for everyone.

In fact I didn’t have programming experience and don’t fan of the code at all. :slight_smile:
But most of the expressions I use in my projects are quite simple, like (data.var1 != data.var2) && (data.var3 == data.var4). I found it easy and fast to edit it manually.
Yes, there are some bugs when I forget about quotes or make typos or use some formatter wrong.
But I still think it is more convenient than using the current Visual Expression Editor. (Data Formats)

I agree, it can become visually overloaded.

#26

What I meant here is copy all dynamic attributes (or events) from another element from this page.

Sometimes, I have a group of similar elements on the page.
And then I decided to add a couple of similar dynamic attributes to each of them.
I am configuring it for one element and then I need to copy it for others.

Currently in this case I’m copying attributes by hand through page code.
It would be more safe and easy with a special function for it.

But I agree that it is not especially important. It’s just the idea for the backlog.

#27

Same here.

Example: I might have a mouse click action on an item in a list (a generated table, for example) and want the same action on all the other cells in that row.

#28

Why not apply it on the row then :slight_smile:

#29

It might not be wanted on every cell :wink:

I should have said ‘many of the other cells in that row’.

#30

So how would the copy from menu show it (the td)? Copy from which element exactly, how to identify it? What if you have 100 dynamic events on 100 elements on the page? What if they don’t have ids applied?

#31

Two possible ways…

  1. If you’re in a <td> and you click on ‘Copy from’ you can then select another <td> and copy the code from that
  2. Don’t have a ‘Copy from’ button but, instead, be able to right click on an action to copy it to the clipboard and then go to another element and paste onto it.

I have a feeling both of these are going to have some potentially serious issues so it might actually be that the only way is to edit in code view (as I’m doing now) but it’s worth considering.

#32

I’m personally will be satisfied even with this option.

image

#33

What if an element doesn’t have an id? :slight_smile:

#34

Don’t see a problem for the user to add it if he really wants to make a copy. Small price for this convenient function.

#35

Yes! Please. Thank you :pray:

You should really consider the “build-a-real-app-vacation” after v5. :sweat_smile:

In seriousness, to give it a bit more context: the pickers have been really great (as I have mentioned in few other posts in the past few months). Selecting items and expressions etc has been a bit faster than typing out every single time.
But, this is just when building the expression for the first time. If I want to edit anything, bubbles are a nightmare.
And, for 70% cases pickers works great for complex expressions - no need to go in the code view - unless I need to edit it. Rest 30% - inline flows have been really helpful. But again, they have bubbles, so editing becomes even more difficult in code view.
So, having a direct code view in such right panel and in flow editor etc, would really be appreciated. :slight_smile:

1 Like
#36

The concept looks great. :ok_hand:

But I am not sure if it will be easy to understand… and if it will be even practical to implement - the options like media, input, after etc seems like a lot of work to manage what goes where and how it works in code.
Or Wappler team probably already has that figured out in current implementation.

#37

wow love the concept, I could imagine this is very convenient for non-coder users.

#38
#39

Already coming into life, awesome!

image

Wappler 5.0.0 Beta 4 Released
Also the App Connect components property inspectors are greatly improved by giving you now a quick navigation to the General, Attributes or Events properties!
Now you can just click on the property section you want in the quick navigation and the inspector will automatically scroll to the right section.

2 Likes