Sounds great and for now I’ll just use a full-sized rectangle with my chosen background color and set it invisible before saving for external use. 
1 Like
babylon.js is a great Web 3D engine. Thank you for your contribution.
For interactive suggestions, I hope that related tools will have a unified interaction design standard before the new Babylon.js version is released.
-Compact and sharp UI, because screen space is precious
-Monospaced fonts are great, artistic fonts are not conducive to reading in large areas
-Quick description prompts instead of slow waiting
-You can scroll/drag to adjust the form values
-There is a color picker where the color is entered
Such a UI is very good
1 Like
Is there a way to add margin between controls? I tried using the margin properties, but they seem to be creating padding, not margin.
For example, here is a button inside of a stack panel that I’m trying to move 10px down from the top. Since the button is inside of the stack panel, I can’t set its top to 10px (it resets to 0px when I try to set it).
It seems that setting the button’s top margin to 10px should push the button down 10px, but instead it makes the button smaller, which is unwanted.
Or is there any other way to get the button moved down 10px from the top of its parent stack panel?
https://gui.babylonjs.com/#MECG16#1
Thanks! 
1 Like
YEP! This is actually something we will be implementing next. Since this will also be a change to the API for GUI we are working to figure out a way to update the names while still being backwards compatible.
1 Like
Awesome! Maybe container controls like StackPanel and Rectangle could have gutter properties like the CSS grid for specifying the spacing between their child controls? 
That could solve the naming and child spacing issues I think, but would be a diff approach to setting the properties thou…
1 Like
@user2, thank you for your feedback on the tool. Let me share with you our current plans while walking through your suggestions so you know where we are going.
-
As we’ve adding more user-facing GUI-driven tools such as the Node Material Editor, the Particle System Editor, and now the GUI Editor, we are finding requirements in interaction, layout, and design language that may not have been present for earlier tools. We know there has been a divergence in design and interaction across these tools, and do plan to go back and do a unification pass on all GUI elements in the engine, including the inspector. What you are seeing is a transition from an engine that was designed for engineers with any user-facing GUI (i.e. the inspector) serving simply as debug tools to a more user-agnostic approach that enables users to create content interactively without needing to write lots of code over and over. However, we have a small team and weigh our resource capacity when deciding if we are going to spend a release cycle focusing on unification redesign or spanning the gaps we still see that can make the overall utility of the engine better. We all want to do everything, but unfortunately we are limited by the resources we can aim in any direction. Will a design unification for all tools and the inspector come before the 5.0 release? No. But we are actively considering how soon we can take on that work as it is very important to us.
-
We agree with keeping the UI footprint as small as possible to maximize the canvas the user can work on. To that end, we have moved toward icons rather than strings to label parameters, keeping our negative space to only that necessary for comprehension and using condensed typefaces to allow for longer strings in names to still display useful data at a narrow panel width. Switching to icons also allows us the opportunity to be more verbose in the tool tip when hovering the icon without sacrificing the width of the panel.
-
While I agree that monospaced typefaces do help users with readability, especially in small type, the feature of monospaced type that makes it readable also makes the type set with it wider. You can easily spot a monospaced typeface by looking at the lowercase “i” in a word. In a monospaced typeface the width the “i” takes up is the same width as the lowercase “m” so there is a lot of letter space around the “i” to match the width of wider letters. This suggestion seems to go against your last suggestion that we take up as little space as possible. It also does not align with the image you labeled good design because that GUI is not using a monospaced typeface either.
-
I am not sure I follow what you mean here. I think you are saying you would rather see string descriptions instead of icons, but I could be wrong. If you are reacting to the delay in the tool tip appearing on the icons, we can certainly tweak that timing if users feel it is too slow. However, we are also banking on our users learning what these icons mean and not needing the string. In using our inspector with GUI parameters which still use strings to identify the parameters, it can sometimes be hard to quickly find a particular parameter in a list of strings, especially if there are a lot of parameters in a group. When a user picks up a new application for the first time, there is a learning curve to understanding what all the tool icons mean but once they become familiar with them there’s little need for the tooltip anymore. And seeing an icon consistent with other icons helps to shortcut what the parameter does so when context changes, we can draw meaning from the previous context. It gets to a point when something like this:
has enough meaning that you don’t even need the words. As a user, I can assign any name I want to the icon and don’t need to remember terms like “adjustment layer” or “layer style”. This also helps with localization as the icon can take on the same meaning no matter the primary language of the user. -
We have considered this type of interactive value adjustment but have not landed on an implementation for it. We have a simpler form of interactive input in the inspector where you can hold the up/down arrow in a field to change the value. The problem here is what is the scale that we increment by? Is it fractions of a unit? Is it full units? Is it context dependent based on the current unit? What is the speed of the increment? Should the speed of the increment be unit based (faster for pixels and slower for percent as the ranges are very different)? While we are looking at how we can enable users with different preferences to work the way they want (some like interactive creation with their pointer device while others prefer using their keyboard to using their mouse), we also want to make sure that the interaction feels good. This may be one of the features that need to wait for v2 as we also need to nail some bigger interactions still in flight. We want to have everything, but realistically we need to place the cut line somewhere for v1.
-
Invoking a color picker is on the list for v1, it just didn’t make alpha because… alpha.
-
I agree the image you shared is a good design, but I will also point out that it takes up a fair amount of horizontal space. There is a large area of unused real estate next to the checkboxes and all of the strings and wide input fields do add up. This type of design does suffer when the panel is reduced below the optimum width for the panel and you can already see some strings overflowing their text box so you need to make this panel wider to see the information you are missing.
I hope this helps you understand the process we went through and where we are heading with this tool as well as our overall philosophy around our tooling.
5 Likes
@msDestiny14 Im getting the error “advancedTexture2.parseFromSnippetAsync is not a function” in my browser. Do you know how I can fix this?
@Jad_Matta Make sure you are on 5.0 preview. parseFromSnippetAsync was added after 4.2 
Here is how to select it if you are using the playground.
Cool, these changes are great. Very much looking forward to~~
I love Babylon.js
2 Likes
Welp, the forum software is mad because I posted more than 22% of the replies, LOL, but I was wondering if the (border) thickness property could be added to the Rectangle control in the GUI editor please? This is one of the settings that would be very helpful to see in real time IMO.
Hey Blake, ya it’s not a problem to be posting multiple times, sometimes the flags can happen but don’t worry about it. 
As for the border thickness. Do you mean this property? This is the only one that comes to mind?
1 Like
Thanks, that’s exactly what I was looking for (the Rectangle class calls it “thickness”). I must have forget to set the color or something before LOL. 
1 Like
Heya, back again! IDK if this one’s a bug or if I’m doing something wrong, but when I lay my buttons out in the GUI editor, I have them equally spaced apart horizontally (well actually, it’s their text that’s nearly evenly spaced), but on the playground there’s very uneven spacing between them. 
Here’s a screen shot, showing the GUI editor above and the playground below:
And here’s the GUI and PG, any idea what could be causing that big gap in the playground?
GUI: https://gui.babylonjs.com/#A10CSQ#4
PG: https://playground.babylonjs.com/#4RTUCB#31
Hey Blake,
So there is actually a tiny problem with your scene set up. Taking a look at your GUI Editor I noticed that you are using pixel values in a responsive layout. This usually screams some warning flags So I took a look at your playground. What you will actually need to add is after this setting the ideal width and height so we can insure we are using the 512 x 512 that you assigned in the previous lines.
Preformatted textadvancedTexture.renderAtIdealSize = true;`
https://playground.babylonjs.com/#4RTUCB#32
I think we can improve the documentation on this make this super super clear! Let me know if you have any questions.
1 Like
OMG, thanks so much, doing it that way automatically resizes the font too, without any vertical misalignment issues anymore either, and everything looks much nicer and crisper when the window shrinks than the manual resizing I was trying to do before! 
Just one more thing thou 
, is there any way to get it to respond to vertical resizing, as well as horizontal resizing (which it’s doing wonderfully now), and keep everything else the same? It’s sooo close now to what I’ve been after.
So is there a issue with your alignments on the text. I couldn’t quiet figure it out myself. But is this a bug still now?
1 Like
Well, there’s still the bug when a container’s font size is changed, but using renderAtIdealSize eliminated the need for me to change the font size, so is a nice way around the bug and is a better way to do it I think.
The only issue thou, is that it looks perfect when resized horizontally but when it’s resized vertically, then when it gets too wide and short the controls are way too big since they never resize on vertical window resizing…
I think you should try for more responsive layouts and using % more This has better jobs with scaling for different window sizes as well as when you grow and shrink the window. However sometimes it can be trial and error too depending what you need. 
As for the font issue I’m investigating the font size now and honing in on the root cause.
1 Like
Okay, the reason I started using percents thou is because using the stack panel forces me to use pixel values for all of its chid controls. I like the convenience of using the stack panel to position its children, but if it makes creating a responsive layout harder than maybe I’ll use rectangles instead and manually compute the positions. That last part is what I was trying to avoid in using stack panels, but maybe it will be easier than trying to get a nice responsive layout with pixels values.