Stop constantly rearranging properties and categories in the Properties window

As a Roblox developer, it is very frustrating to deal with Roblox updates suddenly changing the order of properties in the Properties window. This has been happening since earlier this year when properties such as CanCollide and Size were suddenly rearranged.

Just today I got this week’s release build and the categories were rearranged yet again, greatly disrupting the workflow I’ve gotten used to for as long as I know, making it take longer for me to do what I wanted to do. I understand how it’s likely better to have the Data properties such as Name at the top for consistency, but having Appearance pushed below Transform makes no sense to me since I think most of us are editing properties such as Anchored much more than Position. I have been used to properties (most of the time) being sorted alphabetically.

If Roblox is able to address this issue, it would improve my experience as I wouldn’t have to keep getting used to new changes like these, however insignificant they might seem on the surface, has a lot of impact for developers who avidly use the Properties window and expect properties to be in the exact same place they were in before.


This is likely just a growing pain. This feature request is not very useful because these properties are all going to be moved around for only a short period of time, and then they will stay where they are for a long time.

I’m annoyed now that I have to relearn some muscle memory, but I think a more intuitive order will be better long term despite the disruption.

I would personally like to see appearance properties above transform however. I don’t go to the properties panel to change the transform of baseparts much at all.

Turns out this is unintentional, but I fully support future reordering of properties to be less of a nuisance to access.


Letting us drag the categories so we can arrange them to our liking would seem like a good solution to this.

Edit: found feature request


The recent change was unintentional, and introduced thanks to the old method through which the categories were ordered not being very stable (adding new Instance types / members could occasionally cause a change in the category order).

We’re going to fix this as soon as possible, and we’re making the changes is a way where this won’t happen again.


We’ve submitted a fix to make property order more stable for the common categories (Appearance, Data, Transform, Pivot, Behavior, Collision, and Part: in that order. This is the previous order prior to the new property which moved Data to the top) with the rest sorted alphabetically beneath them (so at least there is some sanity to how they are sorted instead of having to hunt around for arbitrarily ordered categories). This is live now if you restart & update Studio.

For context, ever since the Properties widget was introduced over a decade ago, it has sorted categories by the depth-first order their classes/properties appeared in the API dump. This would lead to an occasional reshuffle of categories as new properties were introduced, but usually the common categories remained in the same order. They were not immune however, and until the introduction of the Accoutrement class a few years ago, Appearance was not the topmost category. We recognized this as a problem, but left the sorting alone as to not upset the expected order developers had grown accustomed to (e.g. by sorting alphabetically). However, obviously now this attempt to preserve category order led to it changing.

We can’t promise the category & property order will not change again, as there are still large gaps where they don’t really make sense (e.g. GuiObject::BackgroundColor is in Data, and TextColor is all the way at the bottom of Properties). In the future we will make another, more holistic change to how categories/properties are laid out in Properties to make that saner, but that should be the last. With that will also come strict internal guidelines on which properties are allowed in which categories, when new categories are able to be introduced, etc to eliminate this problem permanently. We also completely agree with the feature request for draggable categories with user-defined sort order.