The new Cross-platform development , Adaptive Design , and Accessibility Guidelines articles disappoint me because they fail to include any real information about how Offset works and why its use should be preferred over Scale.
Staff has spoken on the forum about this before, it’s silly that you guys haven’t included this information in the official documentation. (See quotes below.)
In addition, with the release of the new ViewportDisplaySize property, I find myself wondering what general metrics I should associate with a particular size. For example, what TextSize should I use on a Small device vs a Large device? But this kind of information has also been omitted from the articles. It would be helpful even to just know the thresholds, like “Small is when the size is larger than X device-independent pixels per inch” etc. etc.
Having that information is important for getting the right outcomes, especially on devices which I do not own to test with (for example I don’t have a TV and console, so I can’t test what my UI looks like on console from an appropriate viewing distance).
This :
If you design a UI based entirely around scale sizing, then you’ll run into issues where the UI will be unreadably small on mobile because the display is smaller. You should build your UIs around building the “content” (images, text, etc.) at fixed offset sizes, and then reflow the top level UI to fit this content into the available space. This can mean overflowing into scrolling frames, or moving portions of the UI.
For example, text that’s 1% of the height of the screen might look fine on PC, but would be something like 3 pixels high on a mobile device.
Building your UI entirely around scale sizing has more problems as well:
Scale sizing is, by far , the easiest way to make a UI that will only work on your own computer. It’s way too easy to combine sizing values in a way that cause elements to be in the wrong position at different resolutions.
It’s hard to make UI that handles differing aspect ratios gracefully when using scale sizing, and the size constraint property is frequently misunderstood by developers. Especially consider portrait mode on mobile, where the aspect ratio is less than 1.
You’re forced to use TextScaled for sizing all of your text, which has no way to be consistent between multiple TextLabels. It looks absolutely awful when you have a tab bar and every entry is a different size. On top of that, TextScaled=true has 10x worse performance than TextScaled=false.
You should always test your UI in the device emulator. It will show you what I’ve described in an intuitive fashion, and let you find bugs in your UI.
Instead of rendering UIs tiny on mobile (which would happen if Offset values mapped 1:1 to “native” pixels), we render them larger but with more crisp text and images. If your image assets are larger resolution than your offset values (2x is a good value to shoot for), then they will just automatically look better on mobile. My hack week project this year was to bring this crispness of UI to PCs and laptops with high-density displays (such as 4k displays).
In case you still need further examples, you should look at all of the Roblox-designed UI such as the core UI, chat, humanoid name tags, and the Lua-based group chat function built into the iOS app. All of these are designed with fixed offset values. The topbar is always exactly 36 pixels high.
The one exception to all of this is Xbox. This device is exposed as having a 1080p resolution. In order for text to be readable on this device, text needs to be larger than would be considered small but readable for PC or mobile. If it had been up to me, I would have done the same type of scaling we do on mobile for Xbox.
and this :
The mobile resolution scaling is there specifically so that you can use offset without worrying about high-DPI devices. It guarantees that a pixel is mostly the same physical size across all devices. This means that you can use the same font size both on PC and mobile and it will be legible.
In Lua, you have no way to tell that any scaling is going on. The AbsoluteSize of the ScreenGui is what you get.
If it wasn’t for this, you would have ridiculously tiny UI on almost any modern phone if you used Offset at all and designed it for PC first. A real phone pixel is roughly 1/4th the size compared to that of the average PC monitor. This scaling means you don’t have to worry about that.
and this :
In case darthskrill’s explanation didn’t come across, the idea is that: If you have a 2436x1125 iPhone X with a 5.8" display (462.63 dpi), we won’t actually set the AbsoluteSize of ScreenGui to 2436x1125, instead we’ll set it to a value of 812x375 (a 3x smaller number).
Other than bugs, and some minor information leaks, there’s no way to tell that the device is actually 3x more pixels than we say it is. When we go to render your UI, we will actually render it 3x larger, so that it looks sharp and crisp on the device. For example, if you make a 1 “pixel” line, it will be 3 native pixels wide on this device. If you render TextSize=20 text, we actually render TextSize=60 text. If you render an ImageLabel with an image in it, we upscale that image (unless it’s from the content folder and has an @2x or @3x version).
The main reason we do this is so that UIs will be readable no matter how detailed the device is. All of the other applications on your phone do this as well, including web browsers. We try to normalize for a value of around 160 dpi, which means that a TextSize of 20 is always hopefully physically at least an eighth of an inch high. Any smaller and it’s unlikely to be a good player experience.
In the Web world, these “Roblox pixels” are usually called “device independent pixels” shortened to “dp”.
If your UI looks wrong on a high DPI device because of the device being high DPI, that’s probably a bug. However, if your UI still looks wrong when you load your UI into the Studio emulator, it’s most likely a bug in your UI, not on our end.
I recommend always testing your UIs with a wide range of screen resolutions to make sure that they don’t break when scaled down to a mobile device.
8 Likes