Do you think if we put in a small delay to when the placeholders appear, perhaps also base it on how far a panel is dragged, that would be less annoying?
The result would be you could quickly move your floating panel around and never see the placeholders unless you’re holding the panel for more than a few seconds.
Respectfully, I have no idea who thought this was good UX and ready for release.
I cannot help but feel that docking continues to get worse over time. I drag a single window and my studio explodes into “docking spaces.” What was wrong with the previous system? This feels like a “quick fix” to previous UX issues.
Not to mention that the actual issues with docking and studio layout don’t actually get looked at. I still cannot get studio to save my layouts consistently.
No. In fact, I wouldn’t be surprised if that was even more annoying, as one could start the drag process, and get everything shifted around mid drag.
The issue here is that you’re approaching this with the wrong fix. Placeholders which themselves take up significant room are terrible UX.
The problem seemed to have fixed itself already, my layout only got reset ~4 times yesterday and exactly 0 times today.
You guys probably feel great taking this out of beta with this many issues.
The layout resetting is actually worse now then it was before. Every 3 - 4 studio sessions my layout resets and its infuriating.
Also theres the annoying problem with random widgets opening during playtesting. Doesnt matter if Ive closed them every time they will always pop up.
And lord why does the terrain editor always open when i start a session, without fail.
They force you with big widgets like the terain editor
Would be nice if they came up while holding the widget + holding a key and have it be just that.
I assure you this was not a quick fix without a lot of consideration. Believe it or not, there’s been at least 1 engineer working full time on docking for the past year and often times 3 or more.
I’ve told the story in various details before but it never hurts to tell it once more I guess:
The docking system when released in late 2022 was plagued by multiple issues that we never saw with numerous rounds of internal testing. But out in production, people were reporting corrupt window issues — often the Viewport was simply disappearing during Play Testing. We had all hands on deck to try and reproduce the issues internally based on information from the community. To those that gave us logs, videos, and screenshots: thank you!
While we tried everything we could think of to reproduce it, we noticed that running Reset View would resolve the issue. We put in logic to detect the corruptions, still not knowing the actual cause yet, and automatically reset the view. Originally we tried to pop up a dialog to encourage users to reset their layout but almost everyone ignored that popup and kept complaining about their issues. So we switched to automatic resets… which is not my first choice by a long shot but it did help keep people working on their projects.
There was no simple regression to patch but we did try a couple of speculative fixes that didn’t pan out. Our only other option at the time was to completely disable any docking capabilities and force everyone to single layout of our own design. So in reality we had no quick, simple options.
FINALLY we got a reproducible case to work with. It only appeared on one particular laptop we had and we could only get it to occur with multiple hours of dock layout thrashing. We treated that laptop like a fragile glass sculpture and we were eventually able to root cause the issue: depending on a bunch of variables (working style, plugins utilized, window layout, OS) the underlying OS kernel would just start spitting out bad data. No errors — just invalid native window handle values that look totally normal but poisoned the layout data.
Because this didn’t affect all creators, we spent time exploring every possible option to resolve this without changing functionality. During this time, we were still getting frequent angry reports about disappearing Viewports, reset views, and various other related problems. But since the issues were widely varied in how they manifested, we needed a solution that would definitively fix it today and going forward.
Of all the things in play (user behavior, docking system, and OS) the only thing we had the most control over was the docking system. The other thing we learned during all of this was the corruption conditions were related to deep window hierarchies that were possible by allowing infinite and arbitrary layout combinations. We took more time to investigate what type of layouts most people utilized. We determined that a fixed set of “regions” with some reasonable splitting limits/conditions would work with most layouts.
At this point we are several months into the issue. We figured out how to wrestle the docking system into respecting these new rules. Docking is at the heart of our window/widget management and making such a serious change required several rounds of testing and bug fixing before we could even get it out as a Beta.
Adding to the “fun”, we also had to change the data saving part of the new layout system. Which meant old layouts could not be migrated over and anyone that got switched over to the new system would get a freshly reset layout. So we couldn’t roll this out as an A/B or even your typical Beta feature. But we did finally get a Beta feature out in December that required explicit opt-in even if you have auto enroll turned on.
We ran the Beta through the holiday season, got some excellent feedback from this group on how to improve the docking rules to support more layouts. In April after we fixed the last of the known crashing issues, we flipped off the explicit opt-in which automatically switched more people over and we saw an immediate decline in corruption issues.
Having to rollout a change that affects all users to solve several “moving target” issues is a big product challenge. On the UX, we came up with the best solution we could within the constraints. There’s not a lot of choices on how to show where available docking areas are when they are empty. That said, I do think there’s some improvements we could make: adjusting the rules to support more layouts, make the placeholder panels smaller, and introduce a delay so they don’t appear during quick adjustments. So I’ll be trying to get those through but it’s going to take some time.
If you’ve read this far into Grandpa Paul’s story time, thank you! 
Honestly this isn’t even all of the story but hopefully this gives some insight on how much effort and thought we’ve put in here. This has been a tough one to work through but we will keep iterating and trying to find ways to make this better (with your help!)
That’s an interesting idea. But we still have the challenge of teaching folks that the modifier key exists. Maybe we could show a hint in some way.
We are actively trying to track down layout resets because they shouldn’t be happening at all with the new layout system (beyond the initial reset when you’re switched over). If you customize your layout and then see it reset again, logs would be really helpful. You can DM them to me if you’d like.
OK. Any non-terrible suggestions on how we could present available docking areas when they are empty?
Still concerning it happened more than once but I’m glad to hear it’s stabilized for you. If it suddenly happens again, logs would be really helpful!
Yes, this is a good idea, but a even better solution would be to make a setting which turns off this feature so if someone finds it annoying, he can just easily google the problem and turn off the setting. That way new and experienced developers would be satisfied. ( You can still leave the docking feature on by default, just make an option to turn it off)
Hmmm… this has me wondering if we should consider an “Edit Layout” mode that you have to explicitly switch into and maybe there’s the hotkey someone else suggested. This would also make sense in the longer term where you can save and switch into multiple, preset layouts… which is something we want to support but it’s not prioritized currently.
Or the opposite idea: a “Lock Layout” toggle/option
Please, tell me there is an option to TURN OFF new docking system, because these are all over my screen. It’s much worse which I can’t work properly and have fun when “new docking system” is so broken. Would be nice to see to turn off this thing, because it’s not really necessary. Old docking system was to be honest much better.
Its a good idea to make the platform more versatile but I think that many developers stick to one layout so it wouldnt be as useful for many. However, if you are a UI designer this would probably be a blessing for you as you need as much of the screen as possible to get to how the GUI of the game would look the players perspective (as UI in studio looks differently to the UI in the game).
So anyway, I would like to hear your ideas about making it possible to turn off the docking feature. Im sure it wouldnt take much to do that and would get rid of at least one reasons why developers are complaining.
Not sure if it’s related to @yourcomputerhasdied’s problem but my layout will occasionally reset, but only in Play Solo mode. All the plugins that I had closed will open into their default position. It’s been happening multiple times a day recently.
When you leave Play Test, does your layout restore? This sounds like the “Faster Play Solo” behavior where we don’t load plugins during play mode. This is a Beta feature you can disable to test.
