Replace contextual toolbars with contextual drawers

[YuriSizov]

Describe the project you are working on

Godot editor

Describe the problem or limitation you are having in your project

It's been a long standing issue that the toolbar row on top of the editor viewports is very crowded when it comes to contextual tools. Not only does it create a lot of clutter for users to untangle reducing productivity, but it also prevents us from comfortably supporting PCs and laptops with smaller displays. This segment of users is very important for us, as a lot of Godot users work from smaller laptops with limited screen space.

But even for people with huge monitors (like myself) the amount of icons on the toolbar can become overwhelming depending on context of selected nodes. While we do some work to move tools away from that panel (https://github.com/godotengine/godot/pull/54342), we also introduce new tools that are important to people who work visually (https://github.com/godotengine/godot/pull/54372). There is also an argument to be made that the toolbar row loses its purpose when we start adding more and more functionality to it, sometimes not even strictly "tool" functionality.

For a better perspective on what areas of the engine it affects see multiple linked issues in https://github.com/godotengine/godot/issues/31133.

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

One of the proposed solutions was to create an overflow for the toolbar and automatically hide excessive elements there. But this doesn't really solve the problem with over-crowdedness and only partially improves usability on smaller screens as users are unable to pick the tools that would go off-screen.

My idea would be to use the space inside of the viewport, and give users a chance to pick. Enter "tool drawers". The concept is similar to Blender's tool panels to the left and right of the viewport. They are hidden, but can slide over the viewport area and provide additional tools, including contextually relevant tools, without a strict limitation for the horizontal space. This allows to better explain what the tools do with labels and titles instead of relying exclusively on pictograms and tooltips.

The ability to select specific sections of the drawers gives users a way to only see the instruments they currently need, while still having access to the tools they may use another time. And while space over the viewport is not exactly free real estate, it can be a decent compromise when the need to use a contextual tool arises.

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

I have a basic prototype done, and moved a couple of control-related contextual toolbars to the drawers. Here's how it works:

https://user-images.githubusercontent.com/11782833/141829169-ed66309c-987b-4808-8da3-ce6561817b33.mp4

Also look at how tiny and cute the editor can go!

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

This is about the editor usability.

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

See above.

[knil79]

I think this is great!

It Makes it super clear that the tools are contextual! I had real trouble finding tools in the beginning since it didn't feel intuitive to look in that bar. I thought the bar always had the same tools. It never occurred to me that new ones could be added based on context!

Questions:

• will your code work for all contextual tools in any node?
• Does it work in 2D and 3D?
• can it be backported to the 3.x branch?

Great work!

[YuriSizov]

@knil79 Yes, the idea would be for all contextual toolbars to be replaced by this. Unless there are exceptions that shouldn't be moved, of course. I'll migrate all 2D and 3D toolbars that I'm aware of.

I've also been asked to provide this as a drop-in solution for some visual script cases. And it should likely have an API exposed for user-created editor plugins.

PS. Ah, and yes, it can be backported. But we would first need to stabilize it for master. I'll port everything I can to 3.x from all my current work.

[knil79]

I'll migrate all 2D and 3D toolbars that I'm aware of.

And if there is a tool that you missed it will be fallback and put on the old bar right?

I've also been asked to provide this as a drop-in solution for some visual script cases. And it should likely have an API exposed for user-created editor plugins.

VERY nice!

PS. Ah, and yes, it can be backported. But we would first need to stabilize it for master. I'll port everything I can to 3.x from all my current work.

Music to my ears!

[Zireael07]

One potential use I see for this is the web/Android build of the editor <3

[YuriSizov]

And if there is a tool that you missed it will be fallback and put on the old bar right?

Well, it's all a manual process to change the UI. If I don't change it, it will remain in the toolbar. 🙃

Hopefully, we'll remember everything during the PR review process. If not, feel free to drop an issue report in the main repo afterwards.

[AaronRecord]

See also https://github.com/godotengine/godot-proposals/issues/3112, https://github.com/godotengine/godot/pull/35891, https://github.com/godotengine/godot-proposals/issues/386, https://github.com/godotengine/godot-proposals/issues/14, and probably more

[fire-forge]

This looks great!

I think it needs some new EditorPlugin APIs to go with it, so plugins can add drawers.

Also, there is a small horizontal offset here between the section header text and the button text. I think the spacing should either be increased so that it is more noticeable or the offset should be removed.

[WolfgangSenff]

This is great - looking forward to be able to add drawers to my Firebase plugin to make it easier to configure without having a huge list of properties in the topmost node. This will really help that!

[NathanLovato]

This is an excellent idea to me, a solid solution to the toolbar getting more and more stuff and preventing us to resize the editor.

[reduz]

What needs to be defined about this is how it works in 3D, given you can split the viewports there. This is the main reason why we did not implement something like this before.

[phelioz]

Looks nice but couldn’t we just move it to the inspector instead of having like a little popup. But maybe the inspector gets to crowded then?

Not sure I like how much of the viewport it takes up when the menu is expanded. And there will be a extra click to click it and also a extra click to hide the expanded menu.

Should at least I think auto close when you click somewhere in the viewport (outside of the expanded menu)

[NathanLovato]

What needs to be defined about this is how it works in 3D, given you can split the viewports there

I see mainly three options:

1. Blender has the drawers available per view. You typically use the drawer in a single viewport.
2. Have the drawers to the right of all viewports and reduce the viewports' width when expanding the drawers.
3. Have the drawers draw over the viewports when necessary. Say you have 4 viewports, the drawer could overlay over the 2 on the right.

I think 2. wouldn't feel too good as toggling the drawers would change the viewports' size. And 3 may look off.

And there will be a extra click to click it and also a extra click to hide the expanded menu.

That's similar to clicks in the Inspector to expand categories. You also often need to scroll or search often already. I don't think it would take more time with drawers.

The idea also seems to give you simpler, contextual options to set up nodes, like with the label's example here. So the purpose isn't the same as the inspector: it's a replacement for "contextual toolbars" (which are currently very limited as there's limited space available in the toolbar).

Should at least I think auto close when you click somewhere in the viewport (outside of the expanded menu)

To me, no, you want to control that. You'll often want to tweak options in the drawer, move the view, tweak again... repeatedly. You don't want to take that control away from the user, that'd be really frustrating.

[YuriSizov]

@reduz Yes, jfons mentioned that yesterday, and it is quite a problem. The main issue would be that the context for those tools is never related to the viewport. It's either the open bottom panel editor, or currently selected nodes. Technically, I can duplicate drawer panels between all the viewports, but they would still share all the context.

If that's not a good idea, then we would need to introduce some per-viewport contexts for selected nodes and whatnot. In that case, I think we should be okay to implement this proposal in a straight-forward way, and then work on per-viewport contexts and do the necessary changes there. My main goal here is not to move toolbars into the viewport, like it was proposed before, but to solve the current usability limitation. So I'd start there.

[YuriSizov]

@phelioz

Looks nice but couldn’t we just move it to the inspector instead of having like a little popup. But maybe the inspector gets to crowded then?

All this functionality is already available in the inspector. The point of the toolbars always was to give quick access to some specialized functions depending on the context. Nothing changes here. In fact, this proposal doesn't add any new functionality, it just moves the tools from the toolbar to the drawer, so that the toolbar is no longer overcrowded.

Not sure I like how much of the viewport it takes up when the menu is expanded. And there will be a extra click to click it and also a extra click to hide the expanded menu.

It needs to be over the viewport, or beside it. Like I've mentioned before, it's not new or unique functionality. Those toolbars only contain quick access items for otherwise accessible tools. They are required by people working from the viewport as opposed to people working off the inspector or script. It does take some space, but it's a decent compromise to have only the tools you need handy and to make them appear near the relevant context (the viewport).

Should at least I think auto close when you click somewhere in the viewport (outside of the expanded menu)

When you click somewhere in the viewport, you deselect the nodes, so those panel will disappear. But overall the purpose is the opposite — to have them open as long as the user needs them, not close them like they are context menu. This design is inspired by a similar system in Blender where user fully controls when they want the panels visible and when they don't.

[Nodragem]

In blender, they have their tool options in 1) the toolbar of the viewport, 2) in the tool drawer of the viewport and 3) a tab in the property editor.

Solution 1 is what we have currently in Godot, and solution 2 is what pycbouh is proposing. Solution 3 is almost what phelioz suggested, except that the tool options would not be part of the inspector, they would be in their own tab.

What I mean by tab? In Godot, there is the Inspector tab, File System tab, the Scene tab, the Import tab, Node tab, etc… the tool properties could be a new Tool tab.

that might also save the issue of multiple viewports?

[golddotasksquestions]

I'm sorry to say, but as someone who works on a Laptop with 1080p and a UI zoom of 125%: This is a horrible idea.

One of the worst design decisions Adobe did was to implement exactly this in Photoshop CS6. It is absolutly the worst ever for being productive. The only thing that saved Adobe is that Photoshop allows users to also snap those panels out as permanently floating panels or docking panels.

The solution to overflowing toolbar is to prioritize or increase vertical space of the toolbar and allow users to detach toolbar as a free floating panel. (and bottom panel as well).

The solution to generally better UI are workspaces: "Magnetic docking", detached free floating panels, allowing user to save positions as custom workspaces, providing a hand full of sensible default workspaces. Have panel items with priority, so when the user decides to minimize the panel, only high priority things are shown.

The solution to better UI is NOT to have users click even more e-v-e-r-y t-i-m-e they need to do the most basic tasks!

Godot UI flow already has a problem with nesting important regulary properties deep in the UI to mimic the OPP class principle instead of providing the user the functionality when and where it is needed the most. This is making just it worse by forcing the user to click yet another thing before they can access context relevant settings.

The goal should be to remove clicks for the most common UI flows and make most common contextual setting most visible, not to add clicks and hide common contextual settings even more.

This PR proposal is incredibly disappointing.

[MewPurPur]

The goal should be to remove clicks for the most common UI flows and make most common contextual setting most visible, not to add clicks and hide common contextual settings even more.

I think this is fundamentally unsolvable.

• Making tools more descriptive greatly improves their discoverability, but takes more space.
• Adding more common tools improves convenience, but takes a lot of space and reduces discoverability.
• Showing the context greatly helps with discoverability and space, but reduces convenience.

Ultimately it's about striking a good balance between these and I think this PR does that: Space is solved, discoverability is much better, and even convenience isn't that much worse as overflow means an extra click anyway, and a click is a fair tradeoff for knowing exactly where to find contextual settings.

If you have an idea that strikes an even better balance in your opinion, it would be nice to share a proposal or to chat specifics.

[MewPurPur]

To comment on the PR itself, and address the concern about convenience. There needs to be a way to pin these menus and maybe even move them around.

With something like adding points on Line2D, I would often need to switch between modes like adding or deleting points. If the menu hides when I click somewhere in the editor, my productivity would plummet.

[YuriSizov]

With something like adding points on Line2D, I would often need to switch between modes like adding or deleting points. If the menu hides when I click somewhere in the editor, my productivity would plummet.

That's exactly why I proposed drawers instead of context menus or automatic overflow buttons. These panels will stay open as long as it is relevant for them to stay open, or until the user hides them. They appear and disappear exactly like the toolbars currently do. Some react on what nodes are currently selected, and some - on what bottom editor is open.

I.e. if you select your path node, the button will appear. You click on it, the panel will expand. You work with your path and change tool modes or snapping rules, it still stays. You deselect the path node, it disappears, both panel and button. You select it again and the button appears again, and if the panel was open before it also appears immediately.

There will also be a setting, for people with bigger screens, to forgo the buttons and just always open the panels. We can also add a button and a shortcut to expand or hide all tool drawers at once, if there are many.

Finally, we do want to find a solution for the buttons being nameless. We can do the same Blender does for teaching its left-hand sidebar and allow to expand the buttons to show labels (and do so by default).

[golddotasksquestions]

@ MewPurPur

I think this is fundamentally unsolvable.

Making tools more descriptive greatly improves their discoverability, but takes more space.
Adding more common tools improves convenience, but takes a lot of space and reduces discoverability.
Showing the context greatly helps with discoverability and space, but reduces convenience.

Of course it's solvable:

You need a prominent designated place where you put the most important context related settings.

For this you must prioritize and also allow the user to make individual adjustments (changing priority, all panels free floating, all panels magnetic docking, predefined and user defined workspaces) Just like in many editors of all kinds this area is around the center at the top of the screen.

Coincidentally this is exactly what (or rather where) the toolbar panel currently is.

Instead of streamlining and improving it, this PR removes an intuitive prominent feature drastically and reduces discoverability by hiding it behind yet another button at a much less prominent location, under a graphical symbol unknown to the general user.

This PR is not striking a balance. It's the equivalent of avoiding a problem you have with good organization by stuffing all your mess into an unlabeled drawer, behind a cupboard and under the rug, just before the guests arrive.

It's making UI UX worse (more clicks, hurts discoverability), and on top removing one of the few good and working UI features, instead of trying to solve Godots underlying fundamental UI UX problem.

[Zireael07]

The problem with the current toolbar panel is, it can take too much space for some toolbars and/or stretches the editor.

[golddotasksquestions]

The problem with the current toolbar panel is, it can take too much space for some toolbars and/or stretches the editor.

Hot fix: Add another line to the toolbar. Proper fix:

• Prioritize settings,
• make highest priority settings flow contextually to a designated default panel at the prominent central top panel location,
• allow customization by giving the user tools to set priority to settings and create new user defined panels,
• free floating panels,
• magnetically docking panels,
• custom and user defined workspaces (panel arrangements and panel settings)

[YuriSizov]

@golddotasksquestions What I can take from your responses is that a) this proposal somehow makes the usability worse, and b) there is some fundamental UX problem with the Godot editor. The latter is too vague, up to individual taste and highly debatable to even start discussing, and is not even a part of this proposal, so I won't refer to those points.

The former, however, makes me curious. Everything that you attribute to this idea making worse, the toolbars fail to solve as well.

1. Toolbars have poor discoverability. You don't just need to learn a couple of buttons and their meaning. You need to learn about a whole bunch of them. You have to hover the tooltips for every one of the toolbar actions until you memorize them or after you've not used them for awhile. Some actions are described by the text, but not all. And neither can they all be described by text due to a constricted space available on the toolbar.

On top of that, several people across different comment sections have commented that they didn't realize (at all or for some time) there were contextual toolbars to begin with! Sure, Calinou's fix to highlight them helps in that regard, but that's only a small patch that only recently became available to users. So for most people's experience with Godot toolbars were a poorly discoverable feature.

2. Toolbars lack any priority between them. They are contextually but unconditionally added to the common list in the order of the plugins being registered. They lack any meaningful separation apart from the new highlight that was just added, but even with the highlight all the contextual toolbars are displayed grouped together. And we can't really use titles in there, because, once again, we simply don't have space in there.

It gets even worse if we consider one of the previously suggested solutions to introduce an automatic overflow menu. Such menu would act as a normal context menu (i.e. only appear when you click on the button and disappear after you select the action), and it would take the buttons that were unlucky to be at the end of the row. This would make the life so much harder for people who specifically need those buttons and don't need the buttons which are permanently visible instead.

3. Adding a second row of the toolbar completely fails to solve the problem of people with smaller screens. This way we, once again unconditionally, take valuable vertical space away from their viewport. If we strive to provide one unified interface that covers the cases of most people, this is completely not an option.

---

Comparatively, with this proposal we'd have:

1. Only a few buttons to learn with an extended and more verbose menu options below it. And this is just for now, as we are still looking into options of making buttons have labels and be more noticeable overall, when it's needed. But even in the prototype form we already ask users to remember way less information to use the UI efficiently.

2. Users decide on what is important to them in the moment by only toggling the panels that they want. We don't make any assumptions, don't do "clever" automation, just leave it to the users to configure the panels as they want them. It's important to remember that there is normally no universally useful priority with contextual tools. You may want one thing now, and another later. So it's important to give that moment-to-moment flexibility instead of some complex overarching settings to tune one and only way to sort and prioritize.

3. Instead of taking valuable vertical space we opt to use the more generously available horizontal space, the sides of the viewport. These menus are contextual, so they don't fit into the docks (that would lead to very poor usability and even worse discoverability if we were to add contextual docks). They need to be around the viewport area to be useful. If you want them somewhere else, you already can do everything from the inspector or the bottom editors.

On top of that, nothing prevents us to make these new drawers into detachable and completely adjustable panels that can be relocated within the viewport area, like a floating dock. If there is actually a demand for it.

And that's the problem. While you call it "one of the few good and working UI features", toolbars don't actually work for a lot of people. You can look at the linked issues with technical problems that make toolbars or the entire editor unusable, and you can also look at the proposals linked by LightningAA. Notably one of the most requested proposals in Godot at the moment, https://github.com/godotengine/godot-proposals/issues/14, which this solution partially covers in a similar way.

[bruvzg]

Group titles seem to take a bit too big and visually non-distinct, something like collapsible inspector categories is a bit better (with different background color and smaller margins). Also, separators probably aren't necessary, it's good for toolbar, but here it's just a waste of space.

[AaronRecord]

This PR is incredibly disappointing I think this PR does that To comment on the PR itself this PR removes an intuitive prominent feature This PR is not striking a balance

... this isn't a PR (pull request), this is a proposal 😄

[golddotasksquestions]

Thanks for your response @pycbouh, I appreciate it!

and b) there is some fundamental UX problem with the Godot editor. The latter is too vague, up to individual taste and highly debatable to even start discussing

It's not vague or subjective or debatable at all: You don't need to be a behavior scientist to know how for settings the user has to access very often, highly nesting them or hiding behind obscure button symbols is hurting discoverability and UX flow. Neither do you have to be a scientist to realize how Godots workspace is incredibly rigid and limited in it's ability to be easily user defined or customized compared to countless other even much simpler editors. Combine those two and you end up with an already bad UI system that gets worse the more you add for a greater variety of users.

Allowing more user control, detaching free floating and docking panels has been regularly asked countless times on the community channels as well as here for over many years. When combined with the ability to save as workspaces and having default workspaces, it is a minimum requisite to allow a general purpose editor like Godot to cater to all those different individual usecases and users a multi-purpose editor like Godot has.

Because the only other alternative is only more nesting, deeper menus, and therefore longer click-chains and therefore worse flow and worse discoverability and a harder time for people trying to learn and teach this software.

I mentioned these things because when I asked about the contextual toolbar on Reddit, you rightfully said "that's a multistep process, we need to improve the toolbars first" ... which to me means as much you don't just want to dynamically add additional lines to the toolbar when needed (hot fix), but you want to solve this properly, which I totally agree support. However removing the contextual content from the toolbar where it is most prominent and stuffing it inside a obscure button with even more things and even more nested options, is not solving anything properly, and certainly not improving it! It's making UI UX flow factually worse than it currently is in Godot 3.x making click chains even longer and prominent settings even more nested.

Toolbars have poor discoverability.

Are we talking about the same thing? (Rhetorical question to express what you are saying makes no sense to me what so ever) "Poor discoverability" is when you hide things inside camouflaged Russian dolls like much of Godot current nested UI. "Good discoverability" is when you position a hand full of duplicates of the most used settings in current context in the top area at the center of the screen. Which is exactly what the current contextual part of the toolbar is (supposed to be) doing.

Granted there could be a lot of improvement (see my previous comment about setting prioritization and customization, meaning rethinking what ends up showing up there in the first place), but hiding it away is working directly against it's sole UX purpose. You just create another nested tree users have to memorize and click through.

On top of that, several people across different comment sections have commented that they didn't realize (at all or for some time) there were contextual toolbars to begin with!

And it's hardly a surprise. Even with the most brilliant feature, if you make it inconsistent, confusing because you mix it with other things, and make it appear only some of the time, but with no apparent logic either, of course people will train to set their attention else where.

• The separation to the non contextual selection and transform tools is practically non existent.
• There is no clear declaration in which context the user is currently at.
• Contextual features appear only in some contexts not all contexts
• When contextual features appear, they are hardly ever the most useful or commonly needed features in this context.

There is no doubt the contextual toolbar desperately needs and UI UX overhaul and a lot of love and attention to make this whole area a lot clearer (in purpose and design, I don't mean "empty").

Btw I'm just calling it "toolbar" because that's the official name for this central panel. However this name alone is a contributing a lot to the UX catastrophe. It's not just tools in there. Even more so the word "Toolbar" obscures the contextual functionality.

It's really no wonder people don't know what's up there. But that's not "bad discoverability", that just bad inconsistent and unfocused UX design. Bad design decisions, which I thought you set out to improve, not put in a box.

automatic overflow menu. Such menu would act as a normal context menu (i.e. only appear when you click on the button and disappear after you select the action)

Yes, that would be a hot fix. Definitely better than nothing, but also definitely not my preferred solution. A better hot fix would be to add additional lines reserved only for contextual things. Still a hot fix though that does not address the underlying rigid UI structure and lack of consistency clarity etc which is the cause for these problems ...

Adding a second row of the toolbar completely fails to solve the problem of people with smaller screens.

I work with Godot daily full-time on such a smaller screen. You have to draw the line somewhere. People can't expect to full productivity of a full blown general purpose game engine capable of next gen graphics with all it's bells and whistles on a 13 inch screen and 720p.

If you design for that you cutting your own flesh.

However having said that there always will be productivity concessions for user who decided to work in this environment, we could still do a lot to make Godot more useable on such devices. How? Surprisingly (or not) the same as for power users: Free floating, magnetically dockable panels, custom and default workspaces, a panel with contextual priorities settings ... much more freedom for users to close/minimize and customize their workspace and panels easily directly in the editor without having to write any scripts, just via drag and drop.

[MewPurPur]

highly nesting them or hiding behind obscure button symbols is hurting discoverability and UX flow.

But you only need to remember one thing: "This little square that appears on the viewport with the node's icon, has contextual settings for that node." It's so basic I can imagine it explained in a Part 1 of a How to Use Godot tutorial

[NathanLovato]

hiding behind obscure button symbols

This is an early prototype, a small proof of concept. A. toolbars are full of icons, and B. you can add labels, that would address this specific issue.

---

Now, how about prototyping the thing and giving it to the users?

That's how you do UX design. Put the changes in the hands of people, have them test the before and after, and say if it works better for them or not. You can poll that, get both quantitative and qualitative feedback then based on how it works in their hands.

I think people need that to decide if it's an improvement or not, because, in this discussion, there are quite a few details of this early, far from complete proof of concept that become a big thing although there's nothing set in stone yet.

[golddotasksquestions]

@MewPurPur It still defeats the purpose of providing easy unhindered, direct access to what the user is currently working on. Someone still has to tell you where to find those "now" settings. Setting which are most important right now, settings the user most likely will want to have direct access to, right here, right now. Not after clicking yet another obscure button thing. If you work with a software for years, every click is sacred. Unnecessary clicks on things you commonly use accumulate to months of pointless wasted energy, longer production cycles and generally less user and beginner friendly experience.

[Zireael07]

@golddotasksquestions: It's NOT possible to have

easy unhindered direct access

to everything a user might need. This is what the current toolbars tried to achieve, and failed because they take up too much space on smaller screens.

[golddotasksquestions]

Exactly. That's why Godot needs to prioritize and give the user means to customize.

For example properties could have a 4 star UI priority rating for contextual UI: 0 stars means no prioirty: Won't show up in the contextual Toolbar panel 1 Stars: low priority, will be the last to show up 2 Stars: mid priority, will show up always before 1 star rated properties 3 Stars: highest priority, will show up before 2 star and 1 star properties.

We have a couple of default ratings of thing we know users will want to have direct access to, the fast majority is unrated. Users can change rating any time, just hover over a property an click and drag. In the Editor Settings there is an option to save or reset to the defaults.

Default example: Any text label: Font: 3 stars, Font tsize also 3 Stars Meshinstance Albedo: 3 Stars (Meshinstances need default material if they don't already come with one imported imho, clicking on Albedo if there is no material assigned should automatically create a StandardMaterial) Same as for shader: Sprite: shader 3 stars. (Also clicking here on the property should immediately create a new Shader for the sprite if empty with a single click. = sensible defaults)

[silverkorn]

Would it be too time consuming making it available in both ways and defaulting to drawers?

First, you create the drawers component which would have typically the same kind of behaviours as a toolbar contextual menu. Then, you make another component which is an hybrid of both that will change depending on user's editor configuration? (Which you would replace to in the end)

I kind of get what @golddotasksquestions is saying that it might be preferable in some cases/setups.

[YuriSizov]

@silverkorn

Would it be too time consuming making it available in both ways and defaulting to drawers?

The main problem is that making systems too flexible costs in maintenance, not development time. Such costs are hard to justify when we don't have any analytical data of how much users will actually use that setting. So it's preferable to look for solutions that would make sense for the majority of users.

You can't satisfy everyone anyway, and UX often comes to personal comforts and preferences. I also appreciate that it's scary to experience a major overhaul with something you don't believe to be broken. But that shouldn't stop us from experimenting and making improvements that are needed by large portions of users. I think this proposal has sufficient links to issues and suggestions that show that a lot of people want and even need this. We just need to tune the idea and get it into a shape that solves most of the concerns.

---

Besides, as I've mentioned before, there will be a setting available to always display the drawers and forgo the buttons. This effectively makes them almost like the old toolbars, but to the side instead of on top, and with more verbose and explicit actions instead of blank icons and tooltips. Which, IMO, a clear benefit as users won't have to remember what every icon means, especially if they don't use layout or animation tools often.

[NathanLovato]

Having workspaces and strong customization, while it is an idea well worth discussing, is way beyond the scope of this proposal. It would be a much larger project.

It's off-topic here and would better fit a separate proposal. Isn't there a proposal dedicated to those ideas yet? If not, you could consider writing one for a focused and productive discussion on that topic.

[christinoleo]

This proposal's idea is quite interesting, so thanks @pycbouh for the effort. I agree with most points within the discussion, even the diverging ones, which shows how hard a UI/UX decision really is. Therefore, a prototype would go a long way, so as @NathanLovato said .Probably we will only find the real issues once we try using it for real.

Personally I dislike the design of blender's floating tooltips and usually take way too long to find the info I wish to because of all the button clicking (note: I am a blender noob), so I agree with @golddotasksquestions that all the clicks are bad for discoverability (worse than just making the current tooltip dock bigger), however I have a video showcasing the upcoming godot4 features to edit armature bones and such, which has a very poor UX due to the seemingly infinite hierarchy in the tooltip, so indeed the current way is not good enough.

Therefore, may I propose to test out the current idea (floating tooltip) vs a breadcrumbs solution over the current tooltip dock? I did a fast photoshop here just to exemplify. And either a popup appears (similar to the current proposal), or tooltip itself contextualizes, or, similar toTileMaps/GridMaps, it opens a contextualized "side-dock" with the context clicked on the breadcrumbs. Well, even if it is a bad idea or if my scketch is badly done, its at least something to consider :)

[YuriSizov]

@christinoleo I'm not completely sure what you call "tooltip" in your suggestion (seems to refer to several different things), so sorry if I miss some points.

worse than just making the current tooltip dock bigger

If you speak about the toolbar panel above the viewport, making it bigger is not an option. There is no horizontal space for it to get bigger, and making second/third/forth row of it appear depending on a context not only eats the valuable vertical space, but will also be extremely obnoxious to the user.

Therefore, may I propose to test out the current idea (floating tooltip) vs a breadcrumbs solution over the current tooltip dock? I did a fast photoshop here just to exemplify. And either a popup appears (similar to the current proposal), or tooltip itself contextualizes, or, similar toTileMaps/GridMaps, it opens a contextualized "side-dock" with the context clicked on the breadcrumbs.

Putting any of those buttons into the Inspector dock defeats the purpose of the controls. You can already access all those properties in the inspector, or in the bottom panel editor. If we put the buttons there, then users might just as well use the inspector instead. The point of having toolbars or tool drawers is to have them handy while working in the viewport, to minimize distraction and mouse movement, and to provide quick access to the most useful actions within a context. Docks break the flow in all of this.

The side panel that appears with tile and grid maps does not provide good experience generally. It takes the entire vertical space, whereas drawers only take what they need and you can still use the viewport below them. This can be very important for some drawers that would need to go wider than others, as wider they go, the more space they would eat. Which is why, for example, the tile map editor no longer uses the side panel in Godot 4. That also goes for inspector too, really — it has limited space.

---

And ultimately, I'm not sure how your suggestion changes the status quo. You say you agree that additional clicks are not desired (though there will only be one additional click, once). But options that you propose still rely on additional clicks.

[christinoleo]

Sorry @pycbouh . I guess in my haste, I was not very informative. By tooltip, I mean the inspector (all inspectors in all softwares I call tooltip, so sorry for the confusion).

Putting any of those buttons into the Inspector dock defeats the purpose of the controls. You can already access all those properties in the inspector, or in the bottom panel editor. If we put the buttons there, then users might just as well use the inspector instead. The point of having toolbars or tool drawers is to have them handy while working in the viewport, to minimize distraction and mouse movement, and to provide quick access to the most useful actions within a context. Docks break the flow in all of this.

Yeah, this is kind of the goal with what I said. Since there is already an inspector with the same things as the new proposed "floating tooltip" (or floating inspector?), the idea of what I said is to use the space of the inspector a little better. What I have in mind is: if the same icon-buttons you proposed were in the inspector, they could act like a filter mechanism of the inspector, so at first the inspector would show everything, which we agree can be too much if there is too much information to be shown, but I can choose to focus on parts of it only by using the buttons you proposed (but in the inspector dock instead of the floating window), and therefore the inspector can be contextualised to what you wish to edit. Since the inspector already has all the information, we don't force extra clicks, but give the option to users to click the filter buttons for a better UX if they choose to do so. In parallel, less viewport realstate is used by the floating tooltip, which helps users with lower resolution screens, such as @golddotasksquestions 's argument. The main downside is that the inspector will be contextualized after clicking the buttons, which is a different UX of the current godot. And another note: just as your poposal, these buttons are (1) in breadcrub format and (2) they are like checkboxes which adds the contextualized portion of each button to the inspector (e.g. layout and label, similar to your video example).

Of course, this is just one possibility. If the side-docks are being deprecated, then the other possibility is a popup which opens when you click the button in the inspector dock. This would be very similar to your proposal and use realstate of the viewport to show a "floating tooltip". However, with the buttons on the inspector, less space is used for the floating tooltip overall (helps with smaller resolution screen) and since the info in this popup is (or maybe is) already in the inspector too, this shows the context that these buttons are "narrowd-down version of the inspector" (if I understood the proposal wrong here, feel free to correct me).

I don't argue my solution is better then yours, though. But since it is UI/UX, I personally believe it is worthwhile to consider and test them out (if possible) before discarding any idea.

[YuriSizov]

@christinoleo Thanks, I can see what your idea is about now. However, I don't believe it serves the same purpose. It can be an interesting avenue to explore on its own. In fact, I had a similar experiment a few months ago:

https://user-images.githubusercontent.com/11782833/142266308-df4924f2-306b-45eb-8dbf-36939a8913c3.mp4

But that's not what we are trying to solve here. We don't need to remove toolbars, we just need to make them more flexible and allow users to pick and choose the tools they presently need. My proposal doesn't change any fundamental principle of the toolbars we currently have, it just makes them better fitted in the working area, a bit more customizable, and more verbose. It may look like a radical change, but that's just a small step really.

[Zireael07]

Kind of related (I mean as far as floating, dockable tabs are concerned): #1890

[Jummit]

I don't think this is an improvement; I find the icon-only buttons cryptic and hard to notice as they're floating above the game background. In the toolbar it had a clear label which said what you where configuring:

This change is putting the button in a location which is easier to miss and is removing vital information.

I agree that the toolbar is cluttered, but that can be fixed in other ways:

1. Move the "Lock Objects" and "Make children not selectable" to the node context menu.
2. Unify the Perspective, Transform and View buttons somehow
3. Move the camera override to the Play buttons
4. Move the more obscure options like the "Skeleton Options" in a dropdown.

(Green highlighted things could be removed from the bar)

If that doesn't make enough space, I think the inspector would be a better place to put these context-aware options, as that's where your configuring the selected node.

[HungryProton]

Personally, I think this proposal would be a great improvement. Overlaying contextual tools on the viewport:

• Makes them easy to discover.
• Easy to access.
• There's plenty of space to use without being a distraction or sacrificing viewport size.

(On the last point, maybe that's just my personal preference, but I find it better to have a few buttons spaced apart over the viewport rather than an extra solid toolbar)

---

The main point of contention here seems to be the extra clicks necessary to get to some options that were previously accessible in a single click. For options that are frequently used, I can see how annoying it could become, but that could be solved in two ways:

1. Let the frequently used buttons accessible in one click
2. Create a space on the viewport where users can pin any actions

Solution two would probably require its own proposal. Solution one could be solved the way I did it in my Scatter add-on:

---

When developing Scatter, this is what the toolbar originally looked like:

Sure, I could have saved space in two ways:

• Rely on cryptic icons without text
• Put everything in a dropdown menu

The first one doesn't help new users. The second one adds an extra click for an often used function, assuming the user even notice my dropdown to begin with.

Then I had even more things to expose to the end user and the toolbar was already full (and I'm using an ultrawide monitor). So I put everything in a drawer:

Notice that the two most used buttons are still one click away The extra parameters only show when you click on it. And because the box is semi transparent, you don't feel like you've been robbed of viewport space.

Now, my design has its own issues too, it's only there as an example. I like the way things are presented in the original post, having the drawer enabled by a single button that doesn't take a full 200 * 150 pixels like on my screenshot. Maybe we could do something like this mockup? (Ignore the icons I used, I just grabbed the first things I found)

The original drawer button would be the top one, in black, and the most common used buttons would appear in the gray area below. Clicking the top button would open the drawer just like in the original post. What do you think?

---

About the cryptic buttons, we already have plenty of these in the editor, and this is an opportunity to improve on it. Here we could completely copy what blender does:

• Instant tooltips
• Resizing the drawers shows their name

https://user-images.githubusercontent.com/52043844/142724039-2c0185d8-5883-47ae-9ff6-19fa6f29bf4e.mp4

[NathanLovato]

@Jummit the idea is to have labels by default, with tooltips, with the ability to fold the labels as @HungryProton presented. That itself would already be better than the toolbar which has many icons without labels due to the lack of space.

Again, the video in the first post is just a small proof of concept to get the discussion started.

Part of what the proposal is about is having quick access to the most important features for a node, for example, for UI design. The inspector is very crowded for that purpose. We're working on an app made with Godot, and at least I have to scroll the inspector up and down and use the search bar all the time already.

It would also allow you, as a designer, to work in distraction-free mode (Ctrl-Shift F11). I'd very much like to see more of that in Godot for level and UI design. It's a nice side bonus for addressing a more prominent issue with the toolbar.

[YuriSizov]

I've been experimenting a bit — with the overall look&feel for drawers, and features of those particular GUI-related tools, and here's what I have at the moment:

https://user-images.githubusercontent.com/11782833/142738378-eb7bf355-26c5-401b-9b8f-3f6f62060c9f.mp4

[fire-forge]

@pycbouh Looks great (especially the anchor selector)! I have only a few minor suggestions for it:

1. Fix the gaps in the control anchor selector
2. Use an arrow icon instead of ... for dropdowns. Here is my 3 second mockup of how it would look: This is the same way the inspector does it, for comparison:
3. Only show the borders while the button is active. Having an accent colored border to show which drawers are active is good, but when the button isn't selected I think it should just be one solid color.

[fire-forge]

Also, we should be able to customize which corner of the viewport the drawers are at. This could be done in a similar way to dock panels, with a popup to select which corner of the viewport you want the drawers to be at or by dragging it.

[winston-yallow]

I wonder if a small space between the separate drawers could make the interface easier to use as it would be better visible which part is toggled by which button (easier to see "ah this is the second part from the top").

Quick mockup:

Overall I think this PR is very good, it will allow me to use Godot more efficiently on my small laptop where the toolbar regularly overflows. With how the editor currently works, this seems like a really good solution.

I like the idea of fire540 to allow customization of which corner the drawers are in. Maybe even something like dragging them around (when a modifier key is pressed)? That would be awesome as you can quickly rearrange them to adjust to what you are currently working on. Maybe even that the editor remembers this on a per scene or per node basis. However, I see this as an improvement that could be done at some point on top of this PR, not necessarily something that must be done immediately.

Regarding the 3D view, I think it would be best if the drawers existed kinda in their own overlay above all 3D views. Sure, there can be multiple views, but we will never have different tools for different views. The drawers are coupled to what is selected, not to the view. So I think having them once as an overlay above everything should be fine. The expanded drawers would then overfloat the 3D views if necessary. This could potentially overlap the 3D-Axis-Orientation-Thing that is in the top right corner of each 3D view. I don't think that is too bad. The alternatives would be:

• not overflowing the top right viewport, meaning more scrolling is needed to reach the thing you need in the drawer
• overflowing, but moving the 3d orientation thing. Would look weird and probably also harder to implement as the 3D views would need to be aware of the drawer state

I don't like either option. Instead, I think it is perfectly fine if the 3D orientation thing is hidden under some drawers as you can always either collapse the drawers to reach it or use keyboard controls to achieve the same as clicking the 3d orientation thing.

[YuriSizov]

@fire540 I've addressed this suggestion before: while I don't have anything against that idea, other corners are already taken by other stuff (3d view has a whole menu to the left, bottom sides in viewports can host debug information). This was the only free corner.

So for this suggestion to be implemented, we'd need to allow moving all of that stuff around. Which may be worth it, but also probably something to do outside of this proposal.

[gaudecker]

Upon reading this thread, it seems most (if not all) of the criticism boils down to the drawer taking too much space.

Here's an obvious idea: why not add a keybinding to toggle (or hold to show/hide) its visibility? 🤔

[YuriSizov]

@gaudecker I’m sorry, to “what” taking too much space?

[gaudecker]

@pycbouh I'm sorry. I meant the contextual drawer.