This is a problem for most people, no idea why or how, but it is.
This post will go over almost every single instance or scenario that may lead to displeasing UI behaviour.
Introduction
Your interface elements not behaving how you want them to can be due to numerous things; such as utilising offset incorrectly, not being properly organised (within the explorer)- lacking a proper hierarchy.
This post will go over each of those scenarios.
Scale & Offset
This section will explain what each means and the use cases of both.
Roblox’s native UI editor consists of two arguments to the UDim2 property; Scalar and Offset. A representation of this can be shown as {ScalarX, OffsetX}, {ScalarY, OffsetY}; this applies to the Size and Position UDim2 properties of UI elements, as well as a few properties of UI modifiers (that will be discussed further down).
Reference
Offset
The Offset argument will ensure that the dimensions of your interface elements are consistent, no matter the size of the screen they are being viewed on. This means that they will not adapt or be responsive towards changes in device resolution.
This has many uses; a lot of Roblox’s core UI utilise Offset for sizing.
If you wanted to utilise it yourself, here’s an example of how you could- custom topbar elements.
While topbar elements are made to be small while being viewed on a PC/large screen, utilising Scalar for their sizing would simply make them unpleasing and unintuitive for mobile (or smaller screen use). That being said, it would be best to Offset their sizing so that the dimensions do not diminish across different screens.
Scalar
In contrast to Offset, the Scalar argument allows your interface elements to appropriately scale to a percentage of the screen dimensions they are being viewed on (which is why you’ll see decimals with Scalar in use in comparison to Offset; which uses whole numbers. These decimals correlate to percentages; meaning a size of “0.5” would take up 50%).
Adding onto the above explanation of percentages, utilising Scalar for size or position will apply the property to the parent of the object (e.g if the size was set to “0.5”, it would be sized 50% of the parent frame’s size). Similarly, with positions, a position of 0.5,0,0.5,0, as well as an anchor point of 0.5,0.5, would always position the interface in the center of the parent.
With that being said, ensuring an interface’s size and position properties (depending on your use case) do not consist of any offset will always size or position that UI relative to the screen dimension they are being viewed on. The below topic will touch on when or how you can use both.
Using Scalar & Offset Together
While Scalar takes into account the relative dimensions of the screen, and Offset does the opposite, there are certain cases where either one may not fit you- using one entirely may not be the best choice.
Your UI may be too big utilise offset; causing a displeasing experience on certain devices. Your UI may also be too small to utilise Scalar; as on certain devices, it would simply be too small when scaled further down as a percentage of the new small screen.
In the example above, the UI is accessible on a PC device (first image), but too small to a point where while Scalar is being utilised, on mobile devices it is simply too small to be intuitive at all.
With that being said, it is possible to combine the two arguments.
The size property of the frame shown in the example is currently {0.177, 0},{0.204, 0}.
We could, for example, “replace” some of the Scalar values with Offset; let’s say, add 300 pixels of Offset to both dimensions. We would modify the size property to be {0.177, 300},{0.204, 300}, then size it down to the original as it was whilst consisting of entirely scale to reach an end result of {0.083, 300},{0.002, 300}. This frame is now pleasing and accessible to PC users, and at the same time it is also accessible to mobile users. See the reference below.
BillboardGUIs
All of the concepts mentioned above apply 1:1 to BillboardGUI behaviour. If your sizing of BillboardGUI elements consists of Offset, then as the user moves further away from your screen, the elements will appear bigger or smaller.
Utilising Scalar for the BillboardGUI’s size property and the size & position properties for all elements inside will avoid what was mentioned above.
UIGridLayouts, UIListLayout, and other modifiers
For a lot of these modifiers, you will be faced with properties like “CellSize”, “CellPadding”, “Padding”, etc; and often times, all of these properties are a UDim property containing Scalar and Offset arguments.
Example
The behaviour is also 1:1 in terms of how Offset and Scalar work with these modifiers. A UIGridLayout’s CellSize property will mimic how the regular size property of any UI element works; CellPadding or Padding consisting of Offset will not make the padding (distance between elements) responsive to devices.
If you are utilising a ScrollingFrame and your elements are not behaving as expected, make sure that your UIGridLayout (which is presumably being used) is utilising the right portions of Scalar or Offset for the CellSize property.
UI Hierarchy
Apart from scaling your UI, the way you set up the hierarchy of or organise your UI can have a BIG impact on how it behaves.
Initially; Rule of Thumb
As a rule of thumb, elements should never be bare-slapped under a ScreenGui. Instead, you should first create a “Container”; a transparent frame that is directly under your ScreenGui and holds all the elements.
- Create a Frame under your ScreenGUI.
- Name it “Container”
- Set the size to
1,0,1,0 - Make it transparent (BackgroundTransparency = 1)
“Why?”, you must be asking. Having this frame here sized 100% to the user’s screen dimensions also means that any elements inside it now size or position appropriately to the user’s screen size; the AbsoluteSize of the “Container” frame will always be the screen resolution of the player.
With that out of the way, you can continue to the next section.
Hierarchy Crash Course
At the end of the day, all you need to understand UI hierarchy is a functioning brain and the ability to use logic. By hierarchy, I am referring to the layout of your UI in the explorer; how you parent elements, etc.
To further elaborate; here’s your rule of thumb: If an element appears inside of another one visually, it should be structurally put inside it in the explorer.
That’s how hierarchy within UI works; take a look at a below example.
As you can see in the above example, all of my elements are initially under the “Container” frame.
Afterwards, I have them in a frame called “BottomRight” which acts as a container for the elements inside it; this is done for the purpose of the organisation as well as providing some benefit to scaling, the anchor point is set to 1,1 which would anchor the position to the bottom right. Read more about AnchorPoints here, they will help you greatly.
Inside the “BottomRight” frame, there is the “Circle” frame; which is the primary UI element. As I want this perfectly centered within the BottomRight frame, I have the anchorpoint set to 0.5,0.5. Furthermore, the Circle frame contains the “Background” and “Progress” and “GrungeTexture” elements; all of which make up the entire radial UI.
Furthermore, this example below mapping out each element, how it is set up and where it is physically could provide more help:
The Roblox creator document also contains useful information that expands on what I have written here
Conclusion
If your UI is not behaving properly, one of the things mentioned above is probably the reason. If not, or you are still unsure about a few topics, leave a reply below and I’ll do my best to get back to you.
I made an older post on pretty much this same topic a while back (but it got quite outdated), nonetheless, it may contain some extra information that I failed to mention in this post.
