Engine UX/UI redesign (Mock-up)

[BeattieCameron]

Describe the project you are working on

This feature is a general-purpose feature that will be helpful to all developers.

Describe the problem or limitation you are having in your project

I've been working on a project in Godot for a little while now and as I've gotten more used to the engine, some UX problems have begun to stand out to me. To be clear I really like Godot and its UI is not bad, especially compared to some other game engines out there, but there's also a lot of room for improvement in both the UX and UI departments. There's a very informative post in the Godot discussions repository detailing some people's complaints with inconsistencies in the UX/UI of Godot. I've also seen others discussing their frustration with the UX on reddit or other places online, so I'm confident this is something that's applicable to a sizeable portion of the community.

I know I could make an individual proposal for each change that I'm about to bring up but there are a lot of changes that are related to each other and if each had its own proposal, some might get lost in the crowd so to speak. More importantly, I think some of the problems with Godot's UX actually stem from the fact that each feature has its own proposal, as there's no overarching vision for how Godot's workflow is meant to be structured or how different features are meant to work together.

I also think this proposal will be much easier to follow if I bring up each problem and solution together as we go, so that's how it will be structured.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I've created a mock-up for a full redesign of Godot's UX/UI that should alleviate some problems that I've noticed myself and discussed with others online.

I will describe the solutions in more detail in the mock-ups section, but here are my design goals for the redesign:

Design Goals

1. Clarify inconsistencies in the way different elements are treated within the engine.

A large portion of my complaints and complaints I've seen online come from certain elements being treated inconsistently, which ends up being confusing. For example, the middle 2 panels of the editor (main panel and bottom panel) are treated very differently from the other panels and sometimes this leads to confusing behavior (like scene tabs not really doing anything to the main panel if you're in scripting mode, or the bottom panel changing what's displayed when the user clicks on something unrelated to the bottom panel). Ideally, we can clarify these inconsistencies without losing any functionality that this sort of "special treatment" was designed to enable.

2. Declutter the UI

This one might be more personal and controversial, but I feel Godot's current UI has too many unnecessary borders and lines which adds a lot of visual noise. I struggle with ADHD and personally find visual noise very distracting. It's much easier for me to work with software that doesn't bombard me with unnecessary information at all times. UI is often a tradeoff between visual noise and visual clarity, so striking the proper balance is key. Ideally, we can make the UI less noisy while losing little to no functionality (and of course, there should still be lots of options like extra borders for those who prefer that or need it in order to differentiate between elements, which Godot already supports to some extent). Also important to note: the more space that is taken up by icons and borders, the less space we have to display important information such as the viewport, nodes in the scene tree, files in the file system, or logs in the output panel, so maximizing the utilization of space is another key consideration.

3. Stay true to Godot's visual theming and design philosophy

While this is meant to be a redesign, the goal is not to throw absolutely everything out and start from scratch. The current layout works fairly well for the most part, and many people are already used to their current workflow, changes that are too drastic would be jarring and confusing for veteran developers. We want to build upon the good things while eliminating the bad. It should still be recognizable as Godot, both from a UX and theming standpoint, even after the redesign.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Let's start with an overview of the entire redesign. Here is the current editor as of the Godot 4.2 beta:

And here is a mockup made in Figma of how I propose we redesign the engine:

There's also an alternate extra flat version for those who enjoy extreme simplicity:

(this loses any visual separation between the tops of panels and their contents, I don't personally mind but some people may prefer having a stronger sense of hierarchy)

In general, I've removed a lot of (in my opinion) unnecessary borders and lines to get a much cleaner look. This ended up making elements look a lot flatter so I've added a subtle drop shadow to each panel to help them stand out from the background which is most noticeable with the top elements. I've also done my best to keep with Godot's current color palette but I had to shift some things for contrast purposes since, without the heavy use of borders, this version depends more heavily on contrast between regions.

I've also received feedback that the corners are too round for some people. That's fine! I like rounded borders and I think they fit the playfulness of the Godot engine but there should absolutely be an option to tune the roundness to your liking. In fact there already is a setting for this in Godot, but the maximum corner radius is currently 6, which is quite low in my opinion and I'd like to be able to turn it up a bit more. The corner radius option also does not affect tabs or some other UI elements, which appear rounded in this mockup so it would be nice if the corner radius option was more flexible.

Some disclaimers: I have not yet designed any submenus and I've also yet to design many of the panels (such as the scripting panel or import panel). This redesign has already been a lot of work so I'd like to at least see if other members of the community would be interested in helping to implement these changes before going in and doing all of the nitty-gritty design work.

With that out of the way, there's obviously a lot to go over so I'm just going to go section by section and explain why I made each change.

Top Left Menu

current:

proposed:

'Project' is the largest element within a project, many scenes can exist within a project but there can only be one project. Therefore it makes the most hierarchical sense for it to be the leftmost element, rather than scene like how it is currently. This is consistent with how most software is structured and what most people are used to (with 'file' in most other software being the equivalent to Godot's 'project'). The same logic applies to the 'Editor' tab, it should be hierarchically more significant than 'Scene' and less than Project (though you could argue 'editor' is even higher than 'project'. It's kind of a tossup but to me 'project' feels bigger). I've also seen some people mention that there should be a universal 'edit' panel, with options for copying, pasting, deleting, etc., so that there is a consistent way to access these actions rather than it being dependent upon which panel you are currently in, so I've added an 'edit' button here.

Bottom Panel

current:

proposed:

First, the search bar is already quite long and does not necessarily need that much space, so we can utilize the space more effectively by moving the icons to be in line with it. I pretty much kept the exact same icons across the entire redesign except for right here because I figured I could use the space more effectively if I condensed the error/output message buttons into smaller icons. I also changed the icon for the standard output messages from an exclamation mark to a different icon that already exists within Godot to avoid overlapping with the warnings icon, which is also an exclamation mark. It's a different color but for accessibility purposes, it's best to rely on more than just color. It's also a different shape, but there's nothing that really differentiates between a square with an exclamation mark and a circle with an exclamation mark, both could communicate the same thing.

I've also moved the search icon from the right side of the search bar to the left and darkened it a bit. This is to clarify that the search icon is not a pressable button, which is a bit ambiguous right now since in the current editor it looks pretty much exactly the same as many of the pressable icons in the editor. I've also added an icon for modifying/filtering search results to the right of the search bar (options like sorting by newest vs oldest or other potential filters). This search bar design is carried through to the rest of the search bars as well.

I've also removed 2 icons. The first removal is the button for hiding the search bar, which has been replaced with the little down arrow on the far right, which I think more effectively communicates its purpose than the magnifying glass icon does in the current design. The second removal is the copy button. Pretty much everyone knows how to ctrl+c, or right click -> copy, I don't think we need a dedicated button for it, plus we've added a new dedicated way to copy with the new 'edit' button in the top right of the editor. In this redesign, I've put a lot of work into retaining all of the functionality of the current editor, just in cleaner ways, but this is the only icon/button that I think is worth just completely removing.

Finally the most important part. Tabs! The bottom panel now uses tabs the same way the side panels all use a tab structure. The current bottom panel basically already works like this and just pretends not to by having its tabs not look like tabs, but they function almost exactly like tabs except:

1. They aren't rearrangeable within their own tab bar
2. They can't be moved to other panels
3. Some actions change which tab is displayed
4. The currently active tab can be clicked to minimize the bottom panel

1 - 3 are problems. If the developer wants to swap their debug tab and shader tab, they should be able to. If they want to put their output panel on one of the side panels, they should be able to. If they want to add their file system tab to the bottom panel, they should be able to. Developers should be able to customize the engine to their liking as much as possible in order to suit their workflow. This, I think, fits well with Godot's design philosophy. The engine is very flexible and allows for a lot of creativity, so the editor should be designed with the same flexibility in mind. All tabs should be treated equally.

The engine should also avoid making assumptions about what the developer wants displayed at any given time. If the developer has a tab open, generally it should stay open until they change it manually. The editor should not change it for them if they do something seemingly unrelated. I often work in the shader editor, then launch the game to see how the shaders look, and then come back to the editor to find the bottom panel's active tab has been changed from the shader editor to the output panel. It's a minor inconvenience for me to have to re-open the shader editor, but the editor should not make these kinds of assumptions in the first place. Another one is editing a UI theme. If you are editing a UI theme in the bottom panel, and then click on a node in the scene tree to potentially look at some properties, the bottom panel will close what you were working on. Again, the editor should not make these kinds of assumptions, if the user wants to close a panel, they can close it themself. It's extremely important to make the developer feel in control and to not change things without at least asking them first.

Number 4 is a great space-saving feature; if the bottom panel isn't currently relevant, just minimize it! It's quick and easy, and it can always be brought back just as quickly with a single click if you need the bottom panel again. But there is nothing about this feature that requires the bottom panel to not be made of tabs like the rest of the panels are. In fact, if it's such a useful feature, why not just give it to every tab across the editor? Clicking a tab that is currently open, for instance, the FileSystem tab, will minimize the attached panel like so:

If all panels that form a column are minimized then the whole column will be minimized to the side:

Wow! look at all that extra space!

Just like the way the bottom panel works now, any panel should be re-openable with a single click on whichever tab the user wishes to open.

So to review, we now have a bottom panel that not only has all the same functionality as before, but is more customizable as it can be re-arranged and added to at will, plus a new space-saving measure for all of the other panels!

Main Panel

current:

proposed:

Simplest things first. Rather than having an opaque bar at the top of the viewport, we can simply overlay the icons over the viewport with a semi-transparent background to help them stand out, while making sure they don't obstruct too much. This helps us maximize our use of space as I mentioned in design goal 2

I've also separated some elements to different sides of the viewport and removed or condensed others. The 'group selected nodes' and 'lock selected nodes' buttons have both been removed. To me, these actions should be attached to the scene tree, not the 3D viewport. The tools of the 3D viewport should be for navigating and manipulating 3D, changing positions of nodes, playing with rendering, and seeing data visualized in 3D. Locking and grouping nodes are functions that help manage nodes, which is what the scene tree is for, so it should be there, not here.

The 'Transfrom' button has been changed to be a drop down menu next to the select/move/rotate/scale buttons since the transform menu essentially just modifies what those buttons do. (we could also put 'configure snap' which is inside the 'Transform' menu into its own drop-down next to the snapping button which would make more logical sense, but this approach felt a bit cleaner).

from:

to:

similarly the Icon has been changed to be a dropdown next to the light and environment buttons, since it is used to customize what those buttons do:

The 'View' menu next to the 'Transform' menu has been moved to the in the top right corner since it's used to customize the viewport itself. I also think the 'perspective' button that was previously displayed in the top left of the viewport can be folded into this corner button, as the elements in both of these menus are somewhat related and aren't accessed very often.

Next, buttons for moving/manipulating/selecting objects in 3D space have been moved to the left side of the viewport, and buttons related to the way the 3D space is displayed/rendered have been moved to the right. Separating the elements in this way helps communicate their purpose to beginners, and also makes the top bar less cluttered/visually overwhelming with all of the icons just lined up next to each other.

The 3D gizmo has been moved to the bottom right to make room for the other icons but otherwise hasn't changed.

For the purposes of this mockup I've only done the 3D viewport but I'm sure the 2D viewport could make use of many of the same optimizations.

Finally for the elephant in the room, the tabs. This is a pretty big change but it makes a lot of sense.

current:

proposed:

The current scene tabs actually affect 3 panels, not one. If you switch to a new scene, not only will the viewport change but the scene tree will change, and as a result, the inspector will change as well. Also, if you switch to a new scene while in scripting mode or asset library mode, nothing changes in those panels at all because they have nothing to do with which scene is currently open. For these reasons, it feels a little weird to attach the scene tabs to a panel that they might not always be relevant to when they also affect multiple other panels. One could even argue they are tied more closely to the scene tree than the viewport.

We also can't hide the scene tabs while in scripting/asset lib mode because they need to be visible at all times since you usually switch between scenes very frequently. They also affect the scene tree and inspector, which you often need to see while scripting. This point is where I think #7233 stumbles, because it locks the different scenes behind which editor tab is currently open, making it difficult to switch scenes quickly and easily. It's also unclear how one would open scenes that are based on nodes that don't explicitly fall under the 2D or 3D categories like UI elements or base nodes, since the scene tabs are tied to the individual viewports in the #7233 mockup. It also makes the top of the editor more cluttered for little benefit in my opinion (they have still done some great work and their proposal is worth checking out, especially since they made an actual semi-functional prototype).

This also plays into some of the issues I mentioned with the bottom panel. The main panel is treated very differently from the rest of the panels, which can be confusing for beginners and frustrating for veterans. For instance, unlike the side tabs, the 2D/3D viewport, as well as the scripting panel and asset lib, are all locked to the center of the screen since they don't have tabs you can drag around like the other panels do. Being able to move scene panels around individually would make the project messy and it wouldn't really make sense to have multiple scenes open at once because of the way the scene tree works (what would be displayed in the scene tree if there were two open scenes on different parts of the screen? Also, do we just have multiple duplicate panels if the developer enters scripting/asset lib mode?).

Generally, if something modifies multiple different panels across the project, it should be centralized rather than attached to a single panel (though many different things affect the inspector, but that's kind of the point of the inspector so it can be a special case). So we centralize the scene tabs at the top and make each viewport, as well as the scripting panel and the asset lib, their own dedicated panels that can be tabbed through and moved around/docked in different areas, making it more consistent with the rest of the editor and fulfilling number 1 in our design goals. This is really how it should work anyway; the viewports are just ways of displaying data held within a scene, just like the scene tree is another way of displaying data held in a scene, it doesn't really make sense to attach the scene tabs to one and not the other. And there's no reason to have an entire dedicated editor mode for scripting or the asset lib when they could just be their own panels.

This means we can have the script panel open side by side with the viewport if we wish, or we can have both 2D and 3D viewports open at once for projects that regularly switch between the two, or we could put the shader editor or scene tree in the middle if we want, or any other layout configuration the developer prefers. Ultimately it just makes the editor more flexible for more setups without losing any functionality, just like our changes to the bottom panel which we went over earlier.

In keeping with the theme of centralization, I've also moved the forward and back buttons from the inspector to the top of the editor:

current:

proposed:

Admittedly this might feel a bit counterintuitive to some, and I think this is one of the more likely ideas to get cut. The problem with the inspector forward and back buttons is that they don't just affect the inspector, they also affect which nodes are selected in the scene tree, and they can sometimes open new tabs or close tabs in the bottom panel. Ideally, the changes to the bottom panel that we talked about would restrict the editor's ability to open/close tabs all willy-nilly (there could be exceptions when it makes sense) generally keeping tabs open until they are intentionally closed, which would help with the opening and closing of tabs.

The forward and back buttons should be detached from the inspector and instead navigate back and forth to any time any panel is changed. Whether it's selecting a new node which changes the inspector, or a different tab being opened on the bottom panel or a side panel, or even navigating between different scenes, which isn't possible with the current inspector forward and back buttons. This might restrict some functionality that is currently possible, I'm not quite sure if this would be too much of a trade-off, but I am open to feedback.

The changes I've mentioned so far, especially the bottom and main panels, are by far the most important and do most of the heavy lifting toward fulfilling design goal number 1. The rest of the changes are primarily concerned with design goal number 2 of decluttering the different editor panels. Only 3 panels left! And these ones are a lot simpler so they should be easier to explain.

Scene Panel

current:

proposed:

The main difference in the Scene panel is that the attach script button has been removed, and I've implemented the same search bar changes that I made for the bottom panel. Instead of having the search icon on the right, it's on the left and it's darker to clearly communicate that it's not a pressable button. The three dots icon (the lower one) is a button for filtering search results, so I've changed it to the filter icon and placed it inside the search bar, which makes it clearer that it's related to searching, and makes better use of the space.

If we are removing the 'attach script' button, where does that functionality go? Well, we can make some nice 'on hover' functionality for it. This is nice because the icon will only be visible when it is immediately relevant: when you have a node selected or when you're hovering over a node. It also means we can attach a script with only a single click rather than having to first select a node and then click the attach script button like we do currently. We can also use this for the locking nodes functionality we removed from the 3D viewport earlier. This might look something like this:

Note how we can also add this functionality to the selected node if we wish. If a node already has a script we can replace the attach script with the detach script button as well:

In this example, I've also moved the lock icon over to the left side of the scene tree instead of the right which is how it works currently. This is to prevent accidental locking/unlocking since we are adding a new icon to the right side with the new on-hover functionality. If the lock was also on the right side then suddenly there could potentially be 4 icons all right next to each other which might get a little hard to click the correct icon, and we don't want people accidentally detaching scripts. Moving the visibility button over to the left might help with this as well since it would split it up to have 2 icons on each side.

You may have also noticed I've removed the panel menu in the top right:

This holds a menu for where to dock the currently selected tab. The problem with this menu is that it's not clear at a glance that it actually relates to the currently selected tab because it's the same color/brightness as the unselected tabs, rather than the currently selected one, nor does the icon communicate what exactly the menu is supposed to contain. Since you can click and drag tabs around, you shouldn't really need this menu in the first place, but right now it's necessary because it's the only way to open a new docking area.

In a perfect world, we would have better and more flexible docking functionality, which would allow you to drag a tab over to the edge of the editor in order to open a new dock there, separate from any current docks. Or maybe even stretch some panels across multiple docking regions. There is in fact already a pull request relating to this here #4565. Until that functionality is implemented, this menu could easily be moved to be accessible by right-clicking on a tab. This way we can declutter and it also means you can access the docking menu with a single click for tabs that aren't currently selected, which takes 2 clicks in the current editor.

This change is also made across the rest of the panels for the same reasons.

I've also removed the hierarchy lines (I already have them turned off in the current editor) as well as the thin lines that run horizontally across the scene tree. This makes it feel a lot cleaner and less noisy to me. Some may protest that it's difficult to see which nodes are related to which script icons, I personally don't struggle with this and feel indentation is more than enough for me to see where nodes are in relation to each other, but for those who want it there should be an option to highlight alternating nodes which is done in blender and unreal engine:
Blender:

Unreal:

Or we could simply retain the current method of having thin lines to separate elements. The thin lines look very noisy to me but I'm happy to allow people to keep using them if they like them, as long as there's an option to remove the lines.

It's not depicted in the mockup but we should add the ability to group or lock multiple nodes at once in the right-click menu in the scene tree.

FileSystem Panel

current:

proposed:

The FileSystem panel is similar to the scene tree. I've removed some of the lines separating elements (with the same caveats as mentioned with the scene tree), I've removed one icon, and I've combined the search bar with the filter button.

The one removal is a layout-altering button. This button is useful as it allows you to change the way the FileSystem is displayed, but I think it's the kind of thing most people will only use once and then forget about. As such, it doesn't need to have its own dedicated button that is always on screen and could easily be hidden behind a right-click on the FileSystem tab or in the editor settings. It could also be combined with the filter button but that might be too much functionality for one button, and it's a bit of a stretch to say that the two are related.

Finally, I've moved the search bar and the path bar to be in line with each other to better utilize the vertical space. This leaves more room for viewing files. I don't think either the search bar or the file path bar really need as much space as they're given in the original design, but if we really want to maximize space, we could instead condense the search bar into a button and only expand it to be a full bar when it's actively in use.

Search bar not in use:

While in use:

Since we have a little extra space, we could add the layout button back in if we wanted to as well.

I've also made it so the scroll bar is now floating rather than attached to another second bar/rail, which just feels a bit cleaner.

Inspector

current:

proposed:

The inspector is almost exactly the same as before, as it already does a pretty great job at maximizing its usage of space.

Like I mentioned before, I've moved the back and forward buttons to the top of the editor, outside of the inspector. I've also converted the wrench icon to the filter icon, as it is related to filtering through the inspector, and placed it inside the search bar, similar to the other search bars. This menu is more about hiding certain elements though so I could see a case for keeping it separate from the search bar.

The only other change is I've changed the drop-down for selecting sub-resources into a button. This looks a lot cleaner since the name of the currently selected node is always centered at the very top of the inspector, which allows it to function as a sort of label for the inspector. It maximizes our usage of vertical space, since it eliminates an entire row at the top of the inspector, leaving more room for important node properties. My only concern is that it might not be immediately apparent that it's a clickable button, but that would have to be tested. If we need, we can always add the drop-down arrow back in.

Top right menu

current:

proposed:

This one is functionally identical to the current version, I just made sure it kept the same visual theme as the mockup

Please give feedback

All of this is subject to change based on what the community prefers. UI can be quite subjective so I think it's important to have a flexible set of options when it comes to corner radius, extra borders, margin width, and colors. Godot already offers options in these regards but I think we could potentially expand these as well. That's probably a topic for another day though.

I want to be clear that I'm not familiar with Godot's codebase and I don't really have time to implement all of these features myself (assuming people even want to implement them) so I would need someone who is technically proficient in Godot's engine code to handle the implementation. But I would be happy to make more mockups for other panels like the script panel or node panel and work together with programmers to get things implemented!

I'd also really appreciate any feedback you have!

If this enhancement will not be used often, can it be worked around with a few lines of script?

It is a core part of the engine.

Is there a reason why this should be core and not an add-on in the asset library?

Some of this, like removing borders and making things look visually cleaner, could potentially be done with an editor theme, but the larger features like reworking how certain panels work/are laid out would be quite difficult to turn into an addon, plus this benefits the entire community.

[Zireael07]

Minor changes such as the ones proposed to top left menu are likely to wreak havoc on people's muscle memory.

That said, I like making the sections collapsible and I like the proposed bottom panel changes

[Calinou]

Thanks for submitting a thorough and detailed proposal!

'Project' is the largest element within a project, many scenes can exist within a project but there can only be one project.

Unfortunately, this is subject to controversy and probably can't be changed by now: godotengine/godot#60083

[BeattieCameron]

Unfortunately, this is subject to controversy and probably can't be changed by now: godotengine/godot#60083

Ah I see, that's completely reasonable!

[AnidemDex]

I like the inspector and filesystem simplification. There's a lot of wasted space on those docks that can be grouped like you did

[YuriSizov]

There's a lot of wasted space on those docks that can be grouped like you did

I'm not sure how you can say that when Inspector is one of the busiest widgets in the editor, and this proposal even has to remove part of its functionality to make things fit in a more compact way. (It also makes it wider in the example, to appear less crowded).

[BeattieCameron]

I do not know if I understood correctly, but from what I could get, this appears to have a similar issue as a recent proposal.

If I'm in the script tab, and I click another scene. What happens?

Do I lose my context and have to find it again because it is now showing some other thing that was previously selected in the other scene context? A VERY common workflow that I find using all the time is switching scenes just to see the Scene tree structure, so I can make a decision and continue my implementation. If the script panel loses its context, it just breaks the line of thought. Having the Script panel fixed and unaffected by scene changes is a must for me. Detaching it is not a solution as I like to have everything on a single monitor.

Sorry if it's not clear in the initial proposal, allow me to clarify. In my proposal If you are in the script tab and you click on another scene, nothing will change within the script tab and you will not lose context in the script tab, but the scene tree and inspector will change to reflect which scene has been selected.

In my proposed implementation, the script panel is fixed and unaffected by scene changes just as you wish. I realize this is important as it’s a workflow that’s very common among people I’ve discussed this with.

In fact, a primary goal of this redesign is to decouple the script tab and the viewports from the scene tabs, because in the current editor, the scene tabs are attached to the main panel in a way that's unintuitive.

The scene tabs themselves will actually function essentially identically to how they currently work in the editor. Detaching them from the main panel and swapping them with the 2D/3D/script/assetlib simply allows us to keep all the functionality we currently have, while also allowing the viewports, script panel, and asset lib to be moved around and rearranged like the other tabs in the editor.

Hope this helps clarify any miscommunication!

[BeattieCameron]

There's a lot of wasted space on those docks that can be grouped like you did

I'm not sure how you can say that when Inspector is one of the busiest widgets in the editor, and this proposal even has to remove part of its functionality to make things fit in a more compact way. (It also makes it wider in the example, to appear less crowded).

The making it wider was not intentional, in Figma they are laid out to be more or less the same width. They ended up being different sizes due to my sloppy screenshotting. I absolutely intended for it to be a fair comparison.

That said I'm not sure what you mean but "removed part of its functionality". I've moved the forward and back arrows to a different part of the editor, and the drop-down menu for selecting sub-resources has been changed visually to look like a button, but it would have the same functionality as before. No part of the functionality of the inspector is straight-up removed.

The inspector is also a tricky one. It is, like you say, one of the busiest areas of the editor, but sometimes the job of the inspector is to display a lot of information all at once; that is unavoidable to a certain extent. For the most part, I could not think of a way to more simply or elegantly accomplish the goals of the inspector than the current design, which is already pretty effective imo.

[YuriSizov]

I missed it, where did you move the history navigation arrows for inspected objects?

[BeattieCameron]

I missed it, where did you move the history navigation arrows for inspected objects?

The navigation arrows have been moved to the top of the editor:

My reasoning for this is that the inspector forward and back arrows often affect things outside of the inspector. For instance, if you click on the back arrow to go back to a point where you were editing a UI theme, it will open the UI theme in the bottom panel.

It will also select the node that now has focus in the inspector, but it won't deselect the previous node, to me it feels strange and unintuitive to end up with multiple nodes selected in the scene tree just from clicking through the inspector history.

I've also seen some people mention that there is no universal forward and back buttons, so I'm proposing that these forward and back buttons record in their history each time any panel changes focus. Meaning any time you change scenes, any time the inspector changes to a different node or sub-resource, or any time a new tab in a panel gains focus, would be recorded in history and users would be able to use the back arrow to go back to any editor view they had previously.

This makes the forward and back arrows more consistent and predictable, and gives users a universal way to go backwards/forwards in history. Admittedly this does slightly change the functionality we had before, but the goal is still the same, allowing users to go back and forth easily between things they've edited.

I came to the conclusion we needed something like this based on this post

specifically this quote:

It's a reminder that there's no "address bar" or other single thing you can trust to always unambiguously tell you where you are in virtual space and provide a means (even if it's just copy-pasting a URL) to feel confident in your ability to return to places you've been.

I only noticed while I was writing this that the "overpowered" Back/Forward pair hadn't vanished just when I actually needed it, but merely moved from the right end of the main panel's toolbar to the top-right corner of the Inspector... I could have save myself so much mental effort acquiring and clicking "TileMap" in the Scene tree to go one way, then "TileSet" in the inspector to go the other way if I'd noticed that.

(Also, you can't trust that Back/Forward to be overpowered enough because it'll confusingly yank you out of Script into 2D when you click Back but then not put you back into Script when you click Forward.)

As well as this one from a different user:

10. The "navigate back" and "navigate forward" buttons are hidden.

Look at your favorite web browser. The "navigate back" and "navigate forward" buttons are at the top left
Not in Godot. Those two buttons are hidden in the Inspector panel.
This makes it seem like the navigation only applies to what's inside that panel... Which is not true, as those buttons let us navigate what nodes were highlighted in the left panel (scene tree)

Some may find having the arrows attached to the inspector more intuitive and I'm not strongly opposed to keeping them there if people want. I just wanted to show that it's a pain point for some people and there are options for improving it.

[YuriSizov]

For instance, if you click on the back arrow to go back to a point where you were editing a UI theme, it will open the UI theme in the bottom panel.

The theme editor would open because the theme resource is currently being inspected. So this is not a good reason to move buttons elsewhere. Same with everything else. Any other changes that you see in the editor are a reaction to the change of the inspected object. It's consistent whether you use navigation in the inspector dock, or if you open another object for inspection by other means.

Making those buttons float at an arbitrary place breaks any notion of context for them.

I've also seen some people mention that there is no universal forward and back buttons, so I'm proposing that these forward and back buttons record in their history each time any panel changes focus.

That would be completely different functionality, and I'm not even sure what a global history would represent in this case. Besides, giving those buttons different functionality actually does mean that you are removing features from the inspector, despite your claims that you don't.

---

This is actually a problem with this proposal overall. It mixes up a lot of things, most of which can be discussed by targeted proposals. It's hard to discuss such a large document with a bunch of both unrelated and yet interconnected changes. Not to mention all the stylistic changes which serve no practical purpose aside from appealing to your personal tastes.

I recommend trying to work on more focused proposals. And to avoid mixing multiple changes, especially purely stylistic changes, under the same roof. It detracts from your point, and it leads to conversations eventually derailing discussing some particular unrelated details.

[SpaceJellyfishDev]

yea, this would be much better!

I would like the border/line space be further reduced.

In Scene Tree, File System and Inspector, there are still too much unnecessary space between each line of text. In bigger project with thousands of node, thousands of files, or larger node inspector (such as particle system, standard shader) tighter space would fit more information in a window, and give much better efficiency in navigating through them.

An example of Unity's scene, it fits more stuff. I would appreciate an option slider to further reduce line space.

Also having icons at the left side of the text (as shown in Unity's scene tree) would help people with difficulty seeing which nodes are related to which script icons.

If possible, allowing us opening more than one File System will also help.

[AnidemDex]

There's a lot of wasted space on those docks that can be grouped like you did

I'm not sure how you can say that

My screen is small, I always have to decide what space do I need to sacrifice between my docks in order to edit or select something comfortably, editing the layout, editor features and/or modifying "compact" themes to try to have more screen space for the docks (like this theme from @passivestar on X)

Having the docks being more "compact" (somehow, I guess is a valid word) can give you more screen space to distribute between them.

Is not like I can not work with the current theme, is more that takes me more a little bit more time due being resizing and adjusting the whole editor between things that I need to do

Edit: An example of this is this scenario:

[YYF233333]

I recommend trying to work on more focused proposals. And to avoid mixing multiple changes, especially purely stylistic changes, under the same roof. It detracts from your point, and it leads to conversations eventually derailing discussing some particular unrelated details.

@YuriSizov Please read this,

More importantly, I think some of the problems with Godot's UX actually stem from the fact that each feature has its own proposal, as there's no overarching vision for how Godot's workflow is meant to be structured or how different features are meant to work together.

UI is a bunch of correlational components, you cannot expect them to work smoothly together without systematic design.

We are seeing useful advise in this issue like compact elements. Once we reach consensus we could open separated pr for implementation, and finally this one will become a nice tracker to see what we've done as well as ensure all components are consistant with each other.

[Calinou]

Note that ItemList spacing in the editor theme was slightly increased shortly before 4.0: godotengine/godot#65230
I am pondering whether it should be changed back, but keep in mind that more compact spacing will make it harder for users to quickly aim and click at list items (especially with high-sensitivity mice). Design for planes, not helicopters 🙂

We currently have an issue in ItemList where there is a "dead zone" that leads to nowhere if you click it (as shown by the hover feedback that was recently added):

simplescreenrecorder-2023-10-31_08.05.17.mp4

If we fix this issue, it should be possible to have the best of both worlds: more compact ItemList spacing like before 4.0, but the same click area as before. Tree doesn't have this issue.

In that PR, we also discussed the ability to allow the Additional Spacing editor setting to have a negative value, so that you can make things more compact without decreasing the font size or editor scale settings.

[YuriSizov]

@YYF233333 The statement that you've quoted is positively incorrect. There is an overarching design, and this is why we want to consider each suggestion individually. When they are all lumped together, it becomes impossible to discuss them in terms of the current design and how to make them fit it.

Most of this proposal does not require to be discussed together, it's a bunch of individual ideas. And some visual changes based on personal taste which detract from the ideas.

[GrammAcc]

Personally, I don't really care what the engine looks like as long as I have a dark theme (or just not a light theme, the default godot theme is fine for me), but I would really like the ability to collapse entire panels. I code a lot of custom classes and resources in GDScript, so I spend a lot of time in the script editor, and having extra real estate in the main panel without having to maximize it would be awesome.

Also, I think splitting the proposal into usability and visual aspects might be a good idea, but in my experience in web development (not super related, but kind of), visual design is very tightly coupled to accessibility and by extension usability, so it's hard to have a productive discussion about one without the other, but it's also hard to have a productive discussion when trying to solve both problems at the same time. This is one of the reasons why I tend to stick to the backend. 😆

[mrbbbaixue]

To be honst, the most difficult part of Godot's Editor UX overhaul is the workspace(2D 3D Script etc,.) buttons' inrelation to other part than the Scene viewport.

[jinsediaoying]

I think the 2D and 3D tab can be merged into a single Scene tab.
Because when you select a scene, the 2D/3D thing will auto switch, but if you select the 2D/3D tab, you still have to select the scene you want.

[jinsediaoying]

Is it possible to allow open multiple scenes at the same time?
And allow drag the scene tabs to make them a floating window?
And allow the drag the tabs into a floating window to form a tab bar there?

[pesjakves]

You did a great job on tackling some issues that a lot of people apparently have with Godot!

Here are a few notes:

• Godot could definitely use a more proper UX/UI concept - current UI is a set back for newcomers,
• An overall redesign is difficult but it will be neccesary at one point, having some initial ideas like this one is useful,
• For developers, such a complex proposal is scary and difficult to digest (like @YuriSizov mentioned),
• I did something similar for Blender and I have recieved backlash - it is just too big to give constructive feedback, so it is easier for the devs to just flip the table and walk away because the proposal is unrealistic.
• However! I think that Blender 2.8 UI came out of a solid design proposal like this one and it worked great, even though it had some initial backlash, so keep working!

I think you might want to structure your proposal a bit differently.

• suggest a set of rules for designing the UI instead of concrete examples,
• show the example on one or two windows in Godot, explaining its benefits very carefully!
• sometimes, devs will tell you that UI is your personal preference - you should explain reasonings behind the slightest changes in your propsal! I totally understand the reason for a slight change of opacity in a button text or that a removal of an outline helps clerify things but someone who is a programmer probably doesnt. This is not an easy discussion because we are all people with different skillsets and look at things differently. By the way, I think every software is built with a personal preference of somebody ;)
• suggest smaller tasks which could be implemented one by one without breaking functionality of other things

Hope this helps and maybe steers the discussion a bit more!

[YuriSizov]

I totally understand the reason for a slight change of opacity in a button text or that a removal of an outline helps clerify things but someone who is a programmer probably doesnt.

@pesjakves Parts of your comment like this read a bit condescendingly. We are all users of the software we're creating here, and so people who don't like proposed changes do so based on their personal experience and the sense of taste, and not because they don't understand why you might want to do the change in principle. At the end of the day, remember that this is in a large part a software for programmers as well as other creatives in the field.

I do agree wholeheartedly, though, that every software follows someone's personal preference. The key point of this argument would be that suggested changes should not make the tool uncomfortable for existing users, so no matter how objectively better you think some suggestion is, a compromise must be sought if existing users (of which maintainers are some representation) don't find the proposal fitting.

[Pizzaandy]

I'd like to shout out some points from this discussion that should be opened as separate proposals:

• Improve contrast on input elements in default themes
• Add alternating styles for editor lists
• Create a design system or guidelines for editor UI - similar to Unity or Blender

There are widely-accepted best practices for UI/UX like any other field, and I think it's worth opening UI proposals based on those foundations, even if they don't have immediate benefits (discoverability, readability, first-time user experience, etc.).

But there needs to be more to it than "I like it" and "thanks I hate it." Creating an open design system for editor UI is essential to reaching consensus on UI-changing proposals. I would think of it like a code style guide - contributors will disagree on it, but the point is to prevent bikeshedding and provide a sensible default to allow everyone to focus on other things. User feedback should always take precedent over the design system - but having any sort of stated design goal is better than pointing out inconsistencies in every PR and rejecting UI improvements on the basis of "we don't have to change it."

tl;dr let's write down that "overarching design" somewhere so that we can discuss it and contribute to it when UI-related discussions arise.

[MrModez]

Finally some good suggestions. Godot Editor UX is one of the most frustrating parts of the engine. So many weird choices that make you scratch your head in confusion, it's like things weren't actually designed and were just mindlessly added.
My favorite "quirks" of the Editor - shortcuts activating multiple completely unrelated actions at once and panels appearing and hiding on unrelated actions.

[ogapo]

Really like this suggestion overall! I'd like to go further and challenge why we need the "2D/3D/Script" buttons at all. To me it is weird that we have document tabs for scenes but other types of assets (e.g. scripts and shaders) have their own separate mode which, in turn, has it's own list of open documents. Why isn't the tab bar at the top simply "open documents"? If that were the case then the type of view displayed in the central panel could simply change to display the currently selected tab based on the type of document. If you have a 3D scene open, you get the 3D viewer, click on a script tab, see the script editor (with more space due to not needing the script list on the side), click a shader, see the shader editor. The odd man out here is "AssetLib" but I think it probably should just be a bottom-dock panel like Debugger/Output/etc. These have the ability to take over the scene view area already so it would be pretty similar.

Having the Script mode selected and opening scenes and not being able to tell why the tab for the scene was showing but I could still just see my script was personally one of my most frustrating experiences as a new Godot user.

[rossunger]

I think this is a fantastic proposal. I don't agree with all the choices, but I really appreciate the care and detail you put into this. I love the idea of a master-thread for UI redesign/overhaul

If you were to split this into smaller PRs, I would suggest:

• Bottom panel redesign (to match other tabbed panels)
• Bottom panel Output panel redesign
• Search bars redesign across all panels for consistency and clarity.
• Universal forward/back buttons
• Redesign / total overhaul of 2d | 3d | Script menu for decoupling reasons.
• Viewport toolbar redesign
• Scene panel lock button
• Scene panel add script button
• Add editor setting to disable automatic switching of panels (e.g. animation tab, theme editor tab, etc)
• Godot UI Rounded corner editor theme settings changes
• Add Editor theme settings for Scene panel hierarchy lines line_color, thickness, and item_background_color
• Inspector panel UI changes (I couldn't quite figure out how to break these down well)
• File system tab layout changes.

Additional changes that I would propose:

• Move Asset Lib button/window to dock
• put 2d | 3d | Script buttons in the main viewport, maybe top centered
• Add editor theme setting that allow changing the viewport toolbar color (to allow for transparency)
• you didn't account for the fact that the viewport toolbar has a bunch of context dependent extra buttons that appear. There has already been much discussion that perhaps this isn't the right place for them anyway, but I haven't seen any successful proposals for where else these buttons should go. Would love to hear if you have any thoughts about that.
• Since godot themes now have "theme_variations", it would be nice if the editor interface had a separate theme variation for each individual control. This would allow us to customize the editor completely with very little work for godot devs.

Questions for Godot devs:

• is there a reason the tab order in the Scene | Project | Debug | Editor | Help menu can't be an editor theme setting?

[hayahane]

Besides the UI appearance, I think we can learn Blender's workspace design, which Godot's 2D/3D/Script editors has part of it's features.
I've used Unity, UnrealEngine, Blender and Godot Editors for some time, and here are some of my opinions:

• Separated editors are good for cooperation. In the game industry, devs come from different backgrounds. It's best to keep them away from what they aren't familiar with. Therefore, many complicated panels will not bother devs doing their own part.
• Flexibility of tabs matters. Unity and Blender have a very flexible and unified tab system. You can make your own design of the editor. There is a similar proposal. Editor overhaul mockup - ways to add full customizability #7233
  Those 2 above make Blender UI great. Blender uses workspace to store layouts of tabs which enables it to have both separated editors and customizable tabs.
  Currently, Godot has separated editors but they are not easy to customize. If I want a different workflow for the game designers which drive me to make a separate editor, it'll be hard to realize.

[btarg]

I think there is a lot to be taken from Unreal Engine 5's UI, especially its browser-like tabbed interface where different parts of the editor can be turned into separate windows (this would be especially useful for separating the built-in code editor from the main scene editor window, whilst keeping another window for animations, for instance. Hazel Engine has done a great job replicating UE5's user interface whilst simplifying it for a more indie-friendly experience.

[rossunger]

I've been thinking about this more over the past few weeks, and I'm really craving some of these features.

Have you had a chance to open individual proposals/prs for these?

I think we could probably implement some of them as an addon using hacks to demonstrate how great they are (and to use them immediately!). Someone already made one that I just found: https://github.com/rainlizard/ScriptNameOnTop

[Mautar55]

The viewport needs two toolbars because one contains "global" tooling and the other one is per split viewport. Still, I like what you did there, but your design disallows this workflow.

[GrammAcc]

Not strictly related, but I was thinking about the global history feature that was mentioned here, and figured I'd share my thoughts about it.

The global history idea is interesting, but it requires some kind of universal navigation event. In a web browser, that event is a URL change because web browsers were originally implemented to be stateless document viewers. SPA sites that use the javascript History API simulate navigation events by creating unique URLs to represent the state of the page. This is extremely complicated for all but the simplest UIs, and it's very difficult to get right. This is why the back button in a browser can break a lot of modern websites. That being said, I'm not aware of anything in Godot that would be a good candidate for a universal navigation event, so implementing a global back-forward navigation would probably require quite a bit of work under the hood because that underlying event structure would need to be implemented and the user input handling code would need to be updated to modify the history. PubSub is often useful for these kinds of UI features since it allows a particular UI widget to modify the history via message passing without needing to know anything about it. PubSub can be implemented pretty easily using Godot's signals, so this wouldn't be infeasible, but it would still need that preliminary decision about what constitutes a navigation event and how to recreate the state of the editor's UI at any point in time.

If this is a desired feature, it would probably be a good candidate for a separate proposal as @rossunger mentioned in their earlier comment. :)