Right now the only way to preview GUIs without jumping into play solo is to put them in the StarterGui. This causes a few problems:
If you want to work on a GUI in a team create place while someone else is working on another GUI, you can’t because both of your GUIs will be showing in the StarterGui and will overlap/etc
On a constant basis it results in unfinished UI cluttering your screen when you go into play solo since it was in the StarterGui even though it isn’t ready to be used, and needs to be deleted in the explorer in order for you to test.
You have to mess with your GUI’s states (e.g. make it visible when it should be invisible just so you can see what you’re editing) in order to modify it, which can cause problems when you go to test
It’d be awesome if previewing GUIs was changed so that none of the above were issues anymore.
Yeah, I keep my GUIs in a folder so they can be cloned in later.
Currently, to edit them, I have to cut and paste them to screengui and back.
I dont like doing that because it feels risky (as the gui doesnt even exist under datamodel for the duration that Im moving it from A to B, and I have to do that twice every time). Of course wastes time too…
Just a checkbox on screenguis to display in studio, OR always automatically display currently selected gui regardless of location if not already visible (preferably even if it isnt inside a screengui - I have some guis that are just frames and will later be cloned into an actual screengui)
Personally I don’t see why this is necessary. What’s wrong with simply toggling the Visible property on GUIs? Also, for Team Create, you can just open a new/blank place and edit it there.
Here’s a trick that I do: I separate different aspects of my UI into full-screen transparent frames. That way I can toggle then on/off simply with the Visible setting. For instance, all my Menu UI is within a single frame, and my in-game UI is in another. I can just toggle one or the other that I need to work on. I don’t see why there should be another way to preview UIs as the current method works just fine.
Say for example I make the big shop GUI visible to tweak it. I forget to hide it and go into play solo, and there it is, taking up the entire screen. I can close it if it’s finished, but if it’s in the process of being made, I may have to go into the explorer+properties and toggle visibility that way. In the team create place I’m working in right now, I’ve dealt with so many GUIs left half-created or modified and accidentally left visible causing issues when I go into play solo.
Why should I have to open a new place to create something for the existing place I’m working on? I don’t even know of anything else I’d have to do that for. I should be able to design GUIs in the place they’re going to be used in where I have access to all of the modules/etc I need without having to copy/paste them into a new place.
Not sure your workflow for designing UIs can speak for all people who work with UI on ROBLOX. Even in the case that I did do what you suggested, it suffers the same issues that accompany toggling visibility that I mentioned earlier.
What would you propose to change exactly then? Your original post simply says that you don’t want the listed items to be a problem. What would be your solution?
I’d suggest that a new service be created, similarly to StarterGui, but specifically for creating GUIs under Team Create situations. It may cause more clutter, but I think it solves more issues than it creates.
Umm. Any version control software would have you do that if you have a proper work flow.
The problem is that you want a real-time studio, but want people to not see real-time updates for things you dont want to see. Sounds like a heap of mess if you ask me.
Copy the GUI into another place. IE download a local copy and start editing your GUI in that, then put the changes on the live copy.
For a while now, I’ve been thinking of what kind of plugin I could design to resolve this on a personal scale, so I do have some idea of where I’d want GUI development to be, but staff members have expressed concern that they want to overhaul GUIs entirely – I’m not sure if I can suggest something better than what they can come up with knowing where they want to take GUIs on ROBLOX. That being said, here are my thoughts on the plugin I’m conceptualizing:
What I should be able to do:
Preview a hidden frame in the StarterGui without toggling the properties (namely Visible) which might mess up assumed states in scripts
Preview a GUI in any location, even outside of the StarterGui (e.g. ReplicatedStorage)
Preview GUIs without interfering with other people in team create who might also need to design separate UI
My potential plan for a plugin would be clicking a plugin button with any UI element selected to preview them in the CoreGui – optimally this would be part of a context menu if it were a feature. I’m not sure how this would work on a large scale though. I don’t work with UI as much as I do programming/building, so while this may work for what I’ve done up to this point, I may make something in the future where that isn’t good enough. On top of that, other peoples’ workflows might not meld with that painlessly, which is why I didn’t want to suggest it as a solution. ROBLOX engineers know how they want to overhaul UI, and they have more experience in both terms of quantity and diversity, so they’d likely be able to come up with a much better solution.
Yes, that advice holds true in the sense that you shouldn’t push changes to production immediately and are better off testing it in a testing environment (different place in ROBLOX’s case), but not so much for pushing changes to the testing environment. How many testing environments do I need? One to test things before they go into production, one to test things before they go into testing environment 1, one to test things before the go into testing environment 2, etc? I’m already using a testing place before publishing to the production place. Are you telling me I need a third place? There’s a point where testing environments get redundant. The only reason GUIs under development can interfere with the place is because they’re in the StarterGui and get distributed to the player.
Why am I doing development (ShowDevelopmentGui) in the same environment of finalized things? That goes against your advice. The issue is combining development and finished products into a single collection that gets distributed to players – not that I have development GUI in my test place.
The issue isn’t limited to Team Create. All of the issues are present in solo development, but in Team Create, it’s just more present because if you have 3 people working on different UI in the same place at the same time, you have three peoples’ worth of stuff in the StarterGui as opposed to just the thing you are working on.
I’m not a fan of this because it still results in not being able to develop UI at the same time as someone else in Team Create and leaves the following issue unresolved: local gui = script:FindFirstChild("Gui") or game.GuiPreviewService.Gui
Previewing GUIs shouldn’t be tied to any sort of parent.
Production environments = Only stable changes
Test environment = All the changes you’ve made since production
Feature addition = The little place you are building your new GUI
Its fairly standard in any company to use at least 3 environments for a feature.
ROBLOX development teams aren’t companies. The development tools are completely different, and “cause companies do it” isn’t necessarily applicable. On ROBLOX, a third place is unnecessary and dumb. When building, you can build things off to the side away from map. I don’t see why it should be any different with UI. There is no arguable case for developing UI in your ROBLOX test environment interfering with other parts of the game (need for different test environments) aside from the requirement to put them in the StarterGui, but that’s the fault of the StarterGui and not developing UI in the test environment.
Ok, so lets all not do good practice because Roblox dev teams aren’t a company. If you’re going solo, you can go build off to the side or use StarterGui for GUI development because you dont affect anyone else. Team create is different and you are advised to use it as a test environment. By having feature addition environments, you can effectively sandbox your change so that you don’t affect others while you’re putting in debug messages and playing around with design, which may take longer than a day. Once complete, they can put the relevant changes to your test environment and everyone can see it in real-time.
I think team create was made more for collaborating on building rather than scripting or GUI work. IE Many builders can work on 1 map, but only 1 scripter for 1 section of code and 1 person for a GUI (which should be done in feature addition).
By having something on the screen in studio, you expect it to be there in game. Would lead to confusion if we see things that wont be visible in game right?
No. I have a large number of plugin GUIs to help me with development that I don’t expect to be in-game at all. GUIs I’m developing aren’t far off from plugin GUIs in what I expect to be in-game.
I think you’ve missed the many times I’ve mentioned that the primary issue has nothing to do with multiple people, and that multiple people only makes it more noticeable since you’re dealing with multiple peoples’ work at once.
Hi. Bumping this because I still want this feature. Here’s my updated feature request.
Preview guis being edited when selected!
As a Roblox developer, it is currently too hard to preview GUIs that are not in a screen gui in StarterGui, underneath a screenGui. I often have Guis not there, like in a billboard, or as a template.
Right now, it’s really hard to see what is going on. I want Roblox to identify the top-level GUI, and preview it on the screen in the correct aspect ratio.
If Roblox is able to address this issue, it would improve my development experience because I wouldn’t have to drag my GUIs around.
