Today, we are introducing a simple yet powerful quality-of-life improvement to the Properties Panel.
The change
When entering a property value in the properties pane, you previously had to type the property value in exactly the right format for the properties panel to accept it, otherwise it would be ignored. Now, the properties panel will do its best to interpret your input rather than giving up.
Here’s a few examples of how an input is interpreted into a sensible value:
Vector3 property 100 → 100, 100, 100
Color3 property FFF → 255, 255, 255
Color3 property 0.5 → 127, 127, 127
UDim2 property 0.5 → {0.5, 0}, {0.5, 0}
UDim2 property 50 → {0, 50}, {0, 50}
UDim2 property 0.5, 42 → {0.5, 0}, {0, 42}
any property, input 0 → zeroed out
Please let us know if you think of any useful cases we didn’t include.
Aside: Don’t hesitate to send feature requests
This change is a nice demonstration of the power of feature requests.
In total this change only took about a day of work to implement, test, and release. However it will likely save the community countless hours in improved flow of using the properties panel, I even look forwards to taking advantage of it in my own work! So why didn’t we implement this earlier?
Nobody thought to do it. We were too used to the status quo of painstakingly typing out the full property value to imagine that there might be a significant easy improvement there. However all it took to break that status quo was some creative thinking from the right person.
We’re absolutely interested in doing these small quality of life improvements. Some things which seem to be easy quality of life improvements do end up being harder than they should be for technical reasons and not worth doing, but for every one of those there’s undoubtedly other easy highly impactful changes like this one… out there just waiting to be identified and implemented.
Never stop keeping your eye out for these and suggesting them!
I really enjoy using text boxes responsive to user input.
I’ve always tried typing 0.5, 0.5 to frames and it just never did what I wanted. With this update it does it perfectly and I don’t have to put the squiggly brackets no more!
Would love to see more random quality of life improvements!(can’t think of any as of this moment to suggest lol)
FFF in that context is treated as a short-form hex code, with each of the hex digits representing one color component. For example, F08 → 255, 0, 136. That format is relatively common in HTML.
Feature requests are essentially useless. Most feature requests and bug reports go completely ignored 90% of the time. Is there any reason to why this is? Or any plans to change this?
What you might be seeing here is the time factor, which is an interesting one: Paradoxically things which have been broken for a very long time become harder to fix and sometimes continue to remain unfixed as a result.
The reason for that is that when you go to fix very old bugs you have to carefully evaluate whether developers have actually come to depend on the broken behavior as the new expected behavior and what to do about that if they have.
Thank you for your explanation. With that in mind, another quality of life improvement related to this would be this: Color3 property (#)FF0000 → 255, 0, 0
It has always bothered me how when I go to copy and paste a UDIM2 value, it results in {0, 10},{0,10}, which isn’t a viable input when using Udim2.new(), resulting in me having to remove the brackets, etc… Any intentions of changing this?