Studio Beta for Experience Controls Available Now

Why haven’t they made a Dev Module that let us create future-proof Topbar buttons so we don’t have to rely on third-party resources like TopbarPlus or UIShelf?

A new future-proof Dev Module that does let us create buttons for the Topbar and if Roblox ever updates the Topbar (again), Roblox should update the Dev Module themselves so we don’t have to manually update the buttons to make it look like the new buttons in the Topbar. I need this kind of thing please.

Also I would like to bump this post below

2 Likes

This is a simple prototype for some custom UI I was experimenting with. It nicely blends the Roblox button into it with some clever tricks, without breaking immersion.

image

But I really don’t know how I’m supposed to work with this:

image

9 Likes

I’m sorry but this doesn’t help at all. All it is doing is reiterating the post

2 Likes

Love and appreciate the spirit of this reply, we want to see more responses like this.

WRT this, I do not agree. There are many situations where having a big button in the corner 100% of the time is not useful and not appreciated: e.g. cutscenes, top-to-bottom menus especially.

If the developer wants to create a bad user experience by hiding this button during the majority of gameplay, that’s their problem. They will suffer the consequences of that themselves.

7 Likes

I appreciate the transparency but you guys look like you are doing serious mental gymnastics about this right side/left side divide. The sentiment here and elsewhere has been anywhere between neutral to resoundingly universally negative as far as I have seen, including in all focus groups and other feedback sessions I have personally attended.

I am very sceptical of the interpretation that has been provided here. I am sceptical of the benefit it provides users, and I am sceptical that it is worth the multitude of problems it creates - especially for experiences dependent on minimising the presence of core UI.

Please justify your working. Where are these statistics coming from? It means nothing when the methodology is hidden.

17 Likes

FWIW we are a community of developers, not players. Players may overwhelmingly prefer it on the right, and we wouldn’t know that, at least not without transparency on the stats Roblox has collected, which is something we’ve been asking for in general on several changes for a while.

I personally understand the justification for it and while it’s a little gross, I’ll tolerate and work around it as I have for the last 6+ years.

For what it’s worth, I do not understand the justification for it at all. Let me explain my reasoning as comprehensively as possible:

Separation of ‘immersive’ / ‘non-immersive’ controls

Roblox broke their own paradigm here by including the Report menu under the ‘immersive’ menu, which kicks you out to the very same Settings menu that they seem otherwise allergic to linking under the collapsible menu. Obviously the inclusion of Report is justified here by other pragmatic concerns, but doesn’t that point to this being unimportant as a point? It clearly does not win out over ergonomics, space efficiency concerns, or immediate access concerns, so I’m confused why it is included at all.

On top of this, I hardly expect users to even think about the correlation - does Roblox have user studies or other data to back up the assertion that users can make this connection, and that they find this property useful? If they do, why not show that information as justification? I would suspect most users actually think of it as a quick access menu, which is to do with timing, not immersion, so I do not agree with this line of reasoning as a whole and don’t see why it should be such a pivotal point in the conversation - it sounds like the project manager’s personal line in the sand rather than anything motivated by actual user experience.

Ergonomics

Roblox’s stated justification is that the left thumb is most often occupied by the movement joystick on mobile. The right thumb, meanwhile, is used for invoking more sporadic actions such as jumping, and is therefore less commonly utilised.

Roblox use this as if it is a decisive justification for making the right thumb responsible for using this interface element. Implicit in this is the assumption that this UI element is so important that the user will want to multi-task and invoke this UI while processing other heavy cognitive loads such as moving around the game world and performing other in-game actions. This seems to me at best a stretch considering the options in the menu itself. Reporting users will not be commonly done simultaneously to focused in-game interaction. Neither will opening a view of your avatar, nor opening the chat window, nor viewing the leaderboard, nor emoting. I have conviction when I say this because, drawing from my own experience as a UX designer, I know that users, especially mobile users, do not multitask except in very specific and contrived scenarios, such as orchestrating a tightly rehearsed set of actions for a fast paced game. Most Roblox games do not incorporate time pressure of that nature, so users will almost never find themselves doing this.

What I would instead suspect user testing to show, would be that mobile users prefer to invoke these core UI actions while not actively doing something else in the meantime. If you are completing an obby, you will not try to do lava jumps at the same time as opening and reading chat, because your focus is elsewhere. Therefore, I believe this discredits the idea that using the right thumb is necessary for this UI to function well. There is no ergonomic downside to switching these functions to the left thumb - it only means that the left thumb will have to be lifted from its previous action to perform the next action, which from all of my lived experience is what mobile users will do anyway.

This is all not even mentioning the elephant in the room here, which is that phone users are a tiny portion of the Roblox user base. Tablets are the dominant form factor, for which these ergonomics arguments make less sense because - especially for a child with small hands - you will be more actively manipulating the posture you are holding the device with in order to reach the buttons at the top of the screen, which therefore makes using any of these buttons at all a more distracting endeavour by default, reducing the multi-tasking value of two-handed usage.

Beyond tablets, there hasn’t even been a whisper about the desktop user base, who remain a significant portion of the overall user base and have historically been shown to be the most sensitive to the nuances of updates.

It’s typical for desktop users to be on monitors of at least 1080p resolution. By artificially separating out the UI to two different corners of the screen horizontally, desktop users now have to travel that full distance if they are moving between the chat window and chat button, which I would wager are the two highest-traffic areas of the core UI. This is actively unergonomic and breaks key proximity principles of good design.

The problem is ridiculously amplified the more mature/power user you go, as higher-end players use higher resolution screens that worsen the problem dramatically. On my own screen, the button and the window are over 3000 pixels apart. That no consideration has been made for desktop users in light of these points is, in my eyes, a glaring oversight, and the fact the follow-up doesn’t even mention this is indicative that desktop is being left out of these design conversations, supported as an afterthought rather than as the culmination of a targeted design process.

Immediate access to controls

This is a point I actually agree with. It makes complete sense to be able to quickly report users, enable mic and camera, open chat, et cetera. This is one of the only points I’m willing to accept wholly.

However, I’m confused why this excludes other designs. Even if all of the controls were to be consolidated on the left, there would be no reason why you could not still immediately access chat, reporting, and mic options in exactly the same number of taps or clicks as before. The only change would be that the lower-traffic Settings screen would not be immediately accessible, requiring that you first open the toolbar to access it. If having control accessibility correlate with usage frequency is so important, why break step for this underutilised option?

It’s inconsistent and sloppy logic that I ultimately cannot agree with.

Loss of valuable space on mobile

This hasn’t been addressed at all here. No assurances have been given by the team.

There are good reasons to improve the mobile UI. I fully support having a better portrait mode core UI, I fully support modernising the design and making sure touch targets are large enough. What I do not agree with is that these changes necessitate such a large land grab by the core UI.

Game UIs already avoid the top-left corner with good clearance, because that is where the existing button is. Games expect the top-right corner to remain free and unobstructed, especially when they request minimal core UI, because real estate on phones is extremely limited elsewhere:

  • Chat window and core UI lives in the top left
  • The bottom left houses the thumbstick
  • The backpack row lives along the bottom edge
  • Jump and contextual buttons live in the bottom right
  • Health and player list live in the top right

There is barely any room to go around, and any UI developer who has ever built for mobile knows exactly this pain. We often intentionally and pragmatically disable and redesign UI all of the time to try and fit everything in.

If Roblox were to merely increase the size of the Roblox button, I doubt this would send many, if any, games into sheer chaos by taking up valuable real estate. Since the entire menu can collapse down to a button of that size, this would not be a problem at all.

What actively would be a problem is taking up previously-promised-free space in a scenario where there is nowhere else for that UI to spill out to. We now either have to unanchor our UIs from the side of the screen (which results in a horribly unsightly margin), vertically compress it (where it is already vertically constrained and it is difficult enough to show enough content) or completely rethink how we are allocating space in general (which should never be mandated platform-wide like this because it is non-trivial to do). Do the prior flimsy justifications really justify this?


I will now throw away all pretense of being some objective viewer on this situation. I would like to talk about a pattern I recognise from previous years where I have interacted with teams who have been unable or unwilling to properly listen to users (and who on occasion have even been cheeky enough to imply that they have the support of them).

I will not mince words. This looks like a baseless, arbitrary, perhaps even petty rejection of the feedback that has already so clearly been given. The follow-up answers none of these concerns, instead choosing to re-iterate what we were already told while not even indicating that any of the actual feedback was sufficiently taken on board or discussed. This feels like talking to a brick wall and it is exactly the sort of behaviour that we criticise other teams for all of the time.

I have no confidence that this feedback will be taken on board because we have been presented with an identical product, with identical reasoning, to supposedly address feedback that has remained unaddressed.

42 Likes

How do I get the padding from the top of the screen of the topbar? I’m trying to add a button that blends in seamlessly with the new topbar but the padding is different between mobile and desktop (from testing using the emulator).

On the UI that I’m working on, the button looks fine on phone (IPhone X):

But on desktop the padding is bigger, so it is no longer aligned:
image

3 Likes

OH! I get it now. I’m supposed to position it at {x, x, 1, -2} with an anchorpoint of (x, 1). The bounds of the ScreenGui encompasses the free space of topbar itself, and the buttons are positioned relative to the bottom of the bounds.

2 Likes

You’ve completely changed my mind on understanding their justification, you should have lead with this argument 300 replies ago; this fragile justification for holding us back from a utopia where we have even just one corner of the screen free is silly at best. The footnote as well is definitely a pattern. 6+ years of devforum engagement and it still feels like we are talking to a brick wall.

8 Likes

Even though the new CoreGui design is flawed and somewhat large (as many have said), I like this specific addition to Roblox Studio, as it will automatically resize my topbar background when its size is changed.


However, I’ve noticed odd behavior; Here, I set my topbar background UI to use the new TopBarSafeInsets, which works as expected when testing. However, in the editor, the UI fills the whole screen instead of a specific region near the top of the screen. This is my only GUI that will use this setting, but this could get in other developers’ ways if they used this to position buttons or something less subtle than this pinkish gradient.

1 Like

Yeah much of it is feedback I’ve already given to the team in the different sessions I’ve been to. I probably should have dropped it here too, perhaps notes for next time.

4 Likes

I’m glad cross-platform compatibility is being unified. I teach Roblox summer camps, and most of my students exclusively use mobile devices. Knowing how to adjust layouts on PC to accommodate phones and tablets will streamline our development curriculum.

This doesn’t work for me, I need to be able to move all UI over the left.

It’s very easy to make the argument that the roblox menu button shouldn’t be bigger, more prominent, and more inset than it currently is!

Yes, giving that button literally four times as much surface area is going to make it easier to click. Yes this is probably aligned with some UI standard somewhere.
But this is only a good thing if the roblox home button was an action users wanted to do *all of the time during gameplay, but, it is not.
In fact clicking the roblox home button during gameplay is always accidental - especially on a cramped mobile screen.

9 Likes

I feel like the feedback of devs goes largely ignored in favor of what was already intending to be created. It seems like a reoccurring issue and it’s sad to see.
I hope that Roblox sees the feedback and understands the issues with the intended changes.

3 Likes

I am very disappointed in the choice to put half of this ui on the right, where many developers actively use the space. Here’s a few concerns I have regarding the reasons that were given for this change.

Previously users could disable the 3 dot menu if they wished, however you have made it clear that this will not be the case for these new buttons that now occupy this space.

Which is exactly why this space should be left open for Developers ui.

I personally find it more confusing to be remembering which functions are considered in-experience and which are considered Roblox actions. Anything that isn’t made by the developer of the game I’m playing is simply “roblox stuff” in my mind. Separating it just makes it harder to remember where to go to do things.

All that said, I do really like the new appearance of the UI icons and the escape menu visuals. That’s all nice. I also don’t mind the increase to 58 pixels however I worry it might take up too much of the screen for users on older/smaller phones. It might be worth it to consider making it smaller if the user has a very small screen size.

2 Likes

(PC) Spacing is all weird you have 3 different sets of spacing. Different spacing from the side edge to the buttons (and also different to the chat/leaderboard) and different spacing from the bottom of the buttons to the chat/leaderboard.

Also seems there was no addressing of being able to modify the UI’s color, background transparency, even corner radius.

  • Could have restrictions to how transparent you can get or how different of a color you can do (mainly so you don’t blend the background with the symbols).
  • Ability to change the corner radius from the default all the way down to 0.
    – You also have inconsistent corner radius’s overall with the default UI, the icons, chat, and leaderboard have different ones.
2 Likes

This is a stupid update pushed by some egotistical project manager with nothing better to do.

The current UI is good, and as far as I’m aware no one has problems with it, this update does two things:

  • Creates hours / days of unnecessary work for developers
  • Creates a far uglier interface that will ultimately harm engagement across all games

I want to be proven wrong, and would be glad to, so what I ask is that the AB testing results from this test are made public to create transparency that this is actually a positive change and not an unnecessary one.

Also, there’s are so many longstanding bugs and issues on the platform, mind dealing with those before re-inventing the wheel?

5 Likes

You’ll be fine. TopBarPlus can (and partially has) adapted.