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 (godotengine/godot#54342), we also introduce new tools that are important to people who work visually (godotengine/godot#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 godotengine/godot#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:

2021-11-15_20-30-58.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 #3112, godotengine/godot#35891, #386, #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, #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

[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:

2021-09-21_18-33-27.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

2021-11-20.11-33-34.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:

2021-11-20_21-51-24.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.

[YuriSizov]

Hmm, I'm not sure there were a lot of complaints about drawers taking too much space. Most complaints are that they require additional clicks to interact with (toolbars were always visible), that buttons can be too cryptic and require learning what they mean, and that they aren't as flexible as one would hope.

Drawers are opt-in, you have to click the corresponding button for them to show up, so they only take as much space as you need. A shortcut to toggle all of the available drawers on or off at once can be added for convenience, of course. But I'm not sure there was criticism regarding them taking space, so that would solve a different problem.

What does take a lot of space is the toolbars that we have now. That was one of the established problems that this proposal is trying to address.

[winston-yallow]

I think that they do not take too much place. In any way, I would suggest first going with this. Implementing a way to completely hide drawer icons temporarily can always be done later if this really becomes an issue.

In that case I would even suggest that the toggle isn't "hide all drawer" but instead "hide all viewport overlays" which includes the axis orientation thing and the "Perspective" menu and so on... But as I said, something like this can always be added later when it really becomes a problem. Also, there already is the option to enter distraction free mode (Ctrl Shift F11) in order to have a bigger viewport if needed temporarily.

[golddotasksquestions]

@gaudecker

Assuming with "keybindings" you mean "keyboard shortcuts":

These are never a substitute for good UI. They are a vital extension for power users of a particular feature, but not the sole solution to any problem. If your UX depends on keyboard shortcut to be usable or fluid, it sucks big time (yes you Blender).

1. Discoverability is close to 0 if the UX depends on keybindings.
2. Keybindings are impossible to remember for irregular users.
3. It restricts the workflow to a single bottleneck and counter intuitively makes your software hard to configure to user needs (undefined ergonomic keyboard shortcuts is a very sparse resource)

[winston-yallow]

@golddotasksquestions I don't think the suggestion was to make it exclusively possible to only use the key-binding. I think the suggestion was more general to make it possible to hide the drawers completely. The keybinding is more an implementation detail. I agree that only the keybinding would be bad, but usually you would not do that exclusively but instead additionally to a graphical way. In which case keyboard shortcuts are actually good UX and can improve accessibility as not everyone can comfortably use a mouse.

That being said, as I already commented before, I think this could be done at a different time as this is nothing that is necessary for the drawers to work. Especially when one can simply enter the distraction free mode to have more space in the viewport when needed.

[timothyqiu]

I like the Text Properties drawer because it is a dedicated place to inspect & operate things text related.

But I think the Anchors drawer is just a fancy way of providing a bunch of buttons. It constantly takes a lot of screen (although the user can close it manually) and does not provide information. For the anchors preset, I think #3559 is more effective.

[YuriSizov]

does not provide information

It can provide information regarding current settings of the selected node, but this won't work when you select multiple nodes (same limitations apply to the text properties). Container panel is a bit more informative, as it updates depending on what options are available for your current selection.

For the anchors preset, I think #3559 is more effective.

You mean the fact that it's one click less to open, change, and close?

Edit: Note, that the specific functionality for the drawers hasn't been changed much, other than use the available space more efficiently. We definitely don't want to have them in the toolbar, but the functionality of the tools themselves is not the core of this proposal.

[timothyqiu]

It can provide information regarding current settings of the selected node

I know that the similar buttons in the Container Layout drawer can be used to display current selected mode because these are states. The 4x4 array of anchor preset buttons are commands like the current preset popup menu. I don't think it's always doable to deduce preset from the current anchor settings.

You mean the fact that it's one click less to open, change, and close?

A popup closes immediately.

For me, building a UI scene works like: Add a Control, set the preset, tweak a bunch of properties; Add another, set the preset, tweak a bunch of properties... So basically either it stays open during the whole process, or I have to close it manually everytime a preset is chosen. The former makes the drawer take up quite a lot of space when it's not needed, while the latter will quickly get annoying.

Maybe it's just me that need to adapt to a new workflow :) I'm not against the drawer proposal.

[YuriSizov]

I don't think it's always doable to deduce preset from the current anchor settings.

Well, we already do it in the new inspector layout section 🙂 It can, of course, not match any preset as well.

A popup closes immediately.

Yeah, that's what I meant. I can see how this can be annoying with the flow that you describe. I think an adjustment period is always required when the UI/UX changes in any application. It's often hard to tell if the current flow is what is most comfortable and what should be supported, or if it's just how we adapt and adjust to the thing and make the best of it. On the flip side, toolbars can still exist if we find that they serve some purpose better. And nothing about drawers is set in stone, on the contrary, I want to get it in alphas as soon as possible to see how users find them.