-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Godot 4.0 - Editor and Inspector UI/UX - Behavior Overhaul #1503
Comments
I agree with all the points but I just want to clarify
you mean on mouse click release
maybe highlight the name of the panel rather then open it, it gives a visual cue without being in the way |
Please open one proposal per feature request. Don't cram multiple feature requests in the same proposal, as this makes them difficult to discuss individually. You can open proposals with individual features after searching for possible duplicates.
There's already an open proposal about this: #28
This is being partially addressed by godotengine/godot#40438.
AudioStreamPlayer nodes are technically not associated with the Audio panel, as that panel is about the "global" audio bus configuration.
You can disable this in the Editor Settings: Run > Output > Always Open Output On Play |
Hi @Calinou! Thanks for your time reading it, sorry for the long post. "Please open one proposal per feature request." There's already an open proposal about this: #28 This is being partially addressed by godotengine/godot#40438. "AudioStreamPlayer nodes are technically not associated with the Audio panel, as that panel is about the "global" audio bus configuration." "You can disable this in the Editor Settings: Run > Output > Always Open Output On Play" |
Yeah! Sure.
I don't even think it's necessary, but would not opposite if it was implemented. |
Describe the project you are working on:
Space Tactical RPG https://twitter.com/ZeroPointGame
Describe the problem or limitation you are having in your project:
Godot editor is far to be bad but could be improved respecting some UI/UX gidelines. Mostly of the old users are used to this but newcomers can have a hard-time with unpredictable behaviors and bad design decisions.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
At first i need to say, this will be a loooong post but i will try to make it as direct as possible. Second I'm not a UI/UX expert. I'm a programmer just like any other with a bit of interest for this topic. As background i'm the developer of many Blender addons. BoolTool is in oficial releases and was the first non destructive Boolean modeling tool for blender. Baketool is a successful comercial addon and try to solve many UI/UX problems of his bake system. Also developed the Graph Theme that was in Blender master until the 2.8 revision in UI. So again, i'm just a programmer and you can take this as a opinion/suggestion post since i will not try to justify with UX principles every single proposal here. That said my design guideline is always based on the Universal Design Principles .
I would like to point some thoughts here first. It's very often in many Open Source projects that when faced with a critic about how something work, core developers and supporters just say "It's our way to do it, there's no problem here" . In Blender it was the "Blender is for blender users" and i would like to say that it's nothing than bullshit. This was the main cause of Blender was a niche program for decades! Bad Design decisions are not good just because people are used to it. Is obvious that people will adapt and ignore problems with time but it's not what anyone should expect from any software. I'm not saying this to shield myself from any argument against my suggestions, you can agree or not with those, i'm saying it because it damage the ecosystem to evolve, push aside new users and start a bubble of self defense. Once blender dropped it, hired a UI team and started to accept that the world is bigger than itself it become the big player it is today, i saw it happening and would not like to see this happening with Godot too. But let's he honest here Godot is light years better in usability than Blender was at that time! It's already quite similar in any aspect to many other engines and jumping from Unity (The most popular indie engine today) like i did in the last 3 months was easy-peasy. I'm daily surprised how good it already is. What the editor lacks is only polishing and my proposals are focused on this aspect.
So what i'm proposing here is some minor changes that would improve Godot UI/UX usability and i think could be done for 4.0 (At least it's the perfect time for those) following the Universal Design Principles. The problems that i identify in Godot currently are from two types: Behavior Design and Visual Design. I will focus here on Behavior Problems and will make another Proposal in future about Visual Design Problems and the controvert Default Theme.
1 - Dragging Float Number Input Fields
Problem: When dragging a number input field in inspector the values seems normalized by type. What it means is that if a field has float values they are always normalized in -1 to 1 and Integer in -1000 to 1000 (Don't know the right values but this is the amplitude of a mouse movement approximately). There's a modifier to allow to decrease the rate of change and it's useful to integers but for float values with large numbers like used in Transform Inspector it is useless. Is currently impracticable to handle float fields that use values > 1 without a tendinitis.
Solution: Normalize the float values the same high numbers it's done with Integers but add a proporcional mouse movement in a way that slow mouse movements will change by 0.1, mid will change by 1.0 and fast will change to 10. That way you can keep the same amplitude of values you have in int number fields and keep the resolution if the user want to change small values. This can also be applied to int unifying the behavior but with another scale 1/10/100 e.g
Keeping the SHIFT modifier also could force the lower change rate independent of the mouse velocity. Also if something is normalized only in small values like 0~1 it would use the slider component anyway. It would fix manipulation in all Transform inspector parameters and exported float fields.
2 - Inconsistent Mouse Events
There's bad inconstancy with the current Mouse Events between the FileSystem and the Scene Panels. Consistency and predictable behaviors is one of the most important UX Principles so this should be fixed if possible.
FileSystem:
Click (Mouse Press) - Select and Show Import Options
Click on Already Selected Element - Do Nothing.
Double Click - Open Asset, Scene, Script etc...
Drag and Drop - Works for Drop files in the Viewport and Inspector as Resources. Should reorder on list but do not work because list is always alphabetical sort.
Scene:
Click (Mouse Press) - Select and Show Inspector/Node Options
Click on Already Selected Element - Rename.
Double Click - Do Nothing.
Drag and Drop - Do Nothing.
The main problem i see here is the Mouse Click event is not correctly used/implemented in Godot.
Don't know the reason but Mouse Press is used as Mouse Click in Godot Editor! It limit how much different events it can handle. Click should be a sequence of Mouse Press - Check Max Threshold Mouse Move - Mouse Release. If Moved too much it's a Drag Event not a Click. The Event should only be accepted as a Click in the Mouse Release not before.
Double Click is a Click - Check time Threshold event. Don't know how it's implemented now.
Solution.
With this new Click event implemented this is my proposal:
FileSystem
Click (Real Click) - Select and Show Import Options
Click on Already Selected Element - Rename. [NEW]
Double Click - Open Asset in Inspector, Scene, Script etc...
Drag and Drop - Works for Drop files in the Viewport and Inspector as Resources.
Scene:
Click (Real Click) - Select and Show Inspector Options
Click on already selected element - Rename
Double Click - Do Nothing.
Drag and Drop - Can Drag and Drop in Exported Notepath fields in Inspector. Since the Click is now a different event of the Drag and Drop it will not change the current Inspector Selected so it will works as should. [NEW]
3 - More Flexibility in the Dock Panels
Problem: Godot has multiple panels each one for a specific task. With the current modular position system you can choose 8 positions that better serves you for each panel. Godot 4 makes it even better with floating panels. It's very useful for multi monitor users (mostly of us right?) since you can detach a panel and send it to another monitor. But there's some big problem here. For some reason you can't detach, change, add or remove the panels from the bottom and up elements. Also you can't detach or change position of the most important panel that would make usage of multi monitors, the Script one. This is related to two principles: Flexibility and Consistency.
2a. Provide choice in methods of use.
3b. Be consistent with user expectations and intuition.
Solution:
Part 1- Bottom and Left Panels
Unify the Panel behavior making all just tabs with the same behavior. So they can be changed position to other docks freely and can be detached as well. Obvious some panels don't quite fit every position well, there's two approaches to it. First you can just let the user do what they want (Blender and Visual Studio approach) and if it's ugly to have the inspector in the Bottom it's ok because they can just change it anyway and it will not be default. There's also a more conservative approach that would be to have a list of allowed docks that way each panel can be attached but i'm not on it, i really would prefer the full customized way. Game developers are power users, let us have agency about our screen setup.
Part 2 - Top Panels
The Top Panel is challenge not only it don't have a clear meaning (2D and 3D are viewport options, script and Asset Library are other panels) but they also require huge screen space to work. Also as noted before the most important detached panel is not currently detached and it's the Script Editor. This is so much important to multiple monitor users to be ignored. So my suggestion to the top panel is:
2D and 3D should be unified in a single "Viewport item". After that a option to this "Viewpot Mode" (2D/3D) need to be added.. It need be accessible all the time in viewport so should be a fixed option in the viewport top header.
Asset Library should be a floating panel by default. Just like a File Browser. It's not used so often that justify it own option here. It can be hidden in the Project menu e.g
So it let us with 2 functions Viewport and Script. What makes sense here is to keep Viewport fixed and Script as any other Panel, i mean, you should be able to put the script editor in any dock and be detachable too. I can quite think in some screen setups that would work just great with the Script in the left dock. Again the point is that Users should be allowed agency about their screen setup everytime it's feasible. With max flexibility users can fix bad default UI decisions, make it more pleasant or more similar to what they are used to.
How the default screen will look like:
How complex sub panels in bottom will look like
4 - Stop Changing Active Panels
There's something that is quite annoying with the current Godot editor design and is the bad habit of change the screen. I see the good intentions of it, but it's childish and annoying as hell!
Currently everytime you click in a Shader it opens the shader editor, everytime you click in a AnimationPlayer it opens the animator, you click to play it shows the Output even if i just closed it right now! At first it can look great but it's not, once you start to configure the window for the user he loses agency about how he want to see his screen and what is the most important for he now. It get's worse. It's not even currently consistent. E.g when you click in some file in the FileSystem it do not show the Import Option. When you click in any audio element in the Scene it do not open the Audio settings in the bottom panel. It's totally arbitrary and a design decision not compatible with modern softwares.
This behavior is also not fully compatible with a more customized UI as proposed. E.g if a user put the Shader editor in the same dock as the inspector after click in the shader the inspector will close on your face. Even if no other proposal of here is accepted please let me stop this terrible behavior with some editor setting.
### Final Thoughts
See that for proposals 3 and 4, even if looks is a lot of change it don't necessary need to cause changes to the Default setup. Other than the 2D/3D viewport All other Panels and Tabs can stay the same position as currently. Even this automatic change of screen can be kept if wanted, just please add a option for disable it. Those proposals are not disruptive changes for current users, they just increases flexibility and agency for those who want.
This is a WIP document and i will try to keep it updated if found/remember more problems. This was a exhaustive elaboration and i hope those critics and suggestions can contribute in someway to the future of Godot.
Best Regards.
Vitor.
The text was updated successfully, but these errors were encountered: