Top-bar: Open Design Questions #53139
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#53139
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Top-bar: Open Design Questions
Here are various open UI design questions for the top-bar. Mostly they cover details, but at this point we need to start thinking about answers to those.
#50845 is the parent task of it, in here we should focus on the questions mentioned below.
(NOTE) Questions also list the currently agreed on answer if there is one. They are not set in stone yet, it's still possible to veto against them.
Top-bar in General
**How would that work? Shortcut? Dragging of area edge? -- Dragging of area edge. Should behave just like headers (no variable height, hide when dragging edge over some threshold).
Split basic and advanced operator settings
That is, only basic operator settings are visible in the top-bar. There'd be a "More..." button to access advanced ones in a popup.
** Would the "More..." become "Advanced Settings"? Would the first 1-3 advanced settings be shown in the topbar, rest only in the "More..." popup?
Workspace Tabs
** Should we show a confirmation popup on deletion? Remember, deleting a workspace cannot be undone.
Misc
Should that call the "Repeat Last" operator? Should "Repeat Last" be in a separate button instead, so it's not mistaken as some "Apply" button?
Changed status to: 'Open'
Added subscriber: @JulianEisel
Adding a first round of suggested answers:
Top-bar in General
Yes, should be possible. Dragging area edge over threshold should be fine (like with headers).
Yes. But not in maximized area mode (Shift+Spacebar or Ctrl+Up)
Would say upper sub-bar should use default header type, lower one a bit thicker (say around factor 1.5).
Split basic and advanced operator settings
Either overflow or be automatically added after last button, so scrolling like in headers would make it visible.
No strong opinion here.
I'd say it should show the first 3 items or so.
Workspace Tabs
No strong opinion.
Yes, seems reasonable.
Yes.
No strong opinion.
Rename, delete, duplicate, etc.
Misc
Yes, at least to try if user's are fine with it.
No strong opinion.
Added subscriber: @DuarteRamos
I strongly believe it should contain all settings, not just advanced ones, it would be a convenient place to have everything together for easy tweaking.
I'd assume while one is tweaking/adjusting advanced properties the regular ones will often need adjustment too.
Does the pop up close when loses focus? Image tweaking both advanced and regular properties if one has to click the More button every time one clicks away.
Even if doesn't, having to go from the pop-up to the toolbar and back can quickly become distracting and cumbersome because of the potentially large mouse travel distance.
Especially if said popup eventually becomes detachable and behaves like the current F6 popup only having advanced properties feels incomplete.
I'd even say the More or Advanced button could behave more like an "Expand" button that would reveal more lines of the top bar allowing for all properties to be shown.
Can (read should) an operator only have only advanced properties? I mean if they really are all advanced then hide them all as so (no inconsistent exceptions); if not then tag some of them not advanced.
Otherwise just show the More button alone, or along with a message saying something along the lines of "no options for operator xxxx", like for an operator without any properties,; or "See advanced options for operator xxxx" , "Click More for advanced options for operator xxxx"
I imagine managing workspaces is a "maintenance" or "setup" task, it should not happen that often and thus shouldn't be exposed so explicitly, one might delete something by accident. Right Click menu should be the only way IMHO, see bellow
Yes, especially if is not undooable, and even more so if you go with the "always on" or "hover" X button that might be triggered inadvertently
Yes please :)
Yes this should be the main way to deal with them, and avoid what is mentioned above
Added subscriber: @PawelLyczkowski-1
Here is mine:
Sure, just like the tool and properties.
Edge dragging, collapsed would display a similar button to tools and properties sidebars. Top bar should not be variable height though, so it would snap shut.
Yes.
100 pixels on a non-high dpi screen.
No scrolling. If the content overflows, it moves to the More popup (to the top). But if there is too much space, the advanced settings do not move out of the More popup.
Only advanced. F6 would contain all settings (Advanced section can be collapsed though).
Can I get an example of such operator? This should be avoided - but in those rare cases -> empty space + More button.
No X, only Delete entry in a popup on RMB click on tab.
Sure.
Yes.
Same width.
Rename, Delete, Duplicate.
Yes.
Yes.
No.
Added subscriber: @Blendify
I do not think would ever happen, if there are no simple settings for the operator then that makes the "advanced" setting simple.
Also if a setting has no advanced options then it the more... button should still be there but greyed out.
Forgot to add a question (added now):
Added subscriber: @zeauro
At least, there will be the name of the operator. Generally, those working like that have a long name. So, I don't think there is a risk of confusion.
But maybe tooltip of the operator could be displayed.
The cases that I'm especially interested in are the ones where we don't even have a last executed operator. That is e.g. on startup, on file read or after undoing all operations.
Ok, here is an idea. How about we have a row with only the operator stuff that unfolds automatically only when there is an operator/tool which setting we can change? ->
This breaks the idea of what's inside tab and what's outside tab, but I don't think it's that valuable anyway.
The only problem I see with this - can the folding unfolding be done so that it doesn't get in the user's way?
Added subscriber: @JonathanWilliamson
I pretty much agree with all of these, except the pop confirmation for delete.
Since Workspaces are strictly UI and do not contain actual asset data, the pop-up seems unnecessary to me. With the Delete being in the RMB (good choice) it's no longer at much risk of accidental deletions. As an existing example, browser tabs don't confirm removal.
Having a popup isn't that bad, I just don't feel it's necessary.
Conditionally showing the operator settings in some way is good but I don't think expanding the top bar is a good solution. This will cause the UI to suddenly increase in vertical height, potentially overlapping assets and the workspace. This can be jarring and frustrating when it's jumping between tool activations.
Perhaps we always show the tool settings area, adjacent to view-type settings (such as pivot point and other settings shared across all editors), but allow the bar to be hidden just like the Properties and Toolbar.
In the vast majority of cases this bar will not be empty, since most tools have some settings.
Could there be an info message of what happens in this case ?
"Startup file launched" "Operation Undone"
But currently, I am not uncomfortable with a temporary blank space. A user will call hundreds of operators during one session.
The fact that undoing last operation is clearing last operator region is not counter-intuitive.
The fact that this space is empty at creation or opening of a file before anything was done seems logical too.
I think that we should not overstate the fact that a user may conclude that there is a problem because this bar is empty.
I agree with Jonathan. Expanding the topbar is creating a bigger problem than the one it tries to solve.
Added subscriber: @VukGardasevic
The majority of the issues related to displaying the Operator settings would be solved if it can be placed on left or right of the screen.
An example of how it would look like (with some notes following numbers on the image):
Open questions about this mock-up.
This is just a suggestion about exploring some other way of solving the issue of limited space. Hope that is of any use. :)
The problem with this, and the reason we've decided to go with the top bar is that the tool settings constantly get pushed down or are in the way due to the size of the toolshelf. Even with toolshelf tabs this section can get quite long.
The current tool settings are on the left, via the operator panel, and most of would agree that it's not a good solution. It conflicts too much with the space needed for actual tools.
If i wasn't clear i apologize. The idea of an global bar is good this just touches the placement of the operator redo /settings as part of it. The basic / advanced setting could still be implemented, however they're are not a pressing issue as they are in the current proposal.
Space wise, the vertical placement can fit a lot as it is not limited by a timeline, and toolshelf taking up area.
Something like this where the whole operator settings for ANT landscape fits the screen.
Hey @VukGardasevic, let me finally get back to your proposal. In short, it doesn't really convince me ;)
Not sure which jumping you're referring to. When executing different operators, buttons will be added/removed in either case.
Moving some settings except of 1-3 into a "More..." popup might reduce this though, since count of buttons wouldn't change that much and drastically anymore.
Purpose of the "More..." button is not just to save space. It's also supposed to increase usability by simplifying the UI to the important parts, a technique known as progressive disclosure . The lack of space just really justifies going this way.
So even if we wouldn't add operator settings to the top-bar, I think the introduction of a "More..." button for advanced settings would be a good thing to do.
How exactly this button behaves, I see as a rather trivial question. We just need to find agreement on what's nicest.
This point is interesting, mainly because it could help solving the issues of the active tool settings (see #53047). But I'm still skeptical, is it really worth having a tabbed interface if there are only going to be 2-3 tabs anyway? And it still doesn't solve the issue of per-editor active tool (which should the global bar show?).
Honestly, I don't think there's a problem with limited space. Splitting the operator properties into basic & advanced solves them mostly, while bringing additional benefits. I know there are really extreme examples like ANT landscape add-on, but I'm sure we can solve these too.
Take a look at the mockup you posted. Even with rather oversized buttons, settings count that is above average (I guess), and a relatively narrow window height, about a third of the space is unused:
Testing with real Blender and a more common window size, it's about half the height. With the settings placed in the top-bar and the "More..." thingy, it's far less unused space.
Another issue is that another vertical area that would often be visible, would really limit the available screen width for viewports (as in 3D View, UV/Image Editor, Clip Editor, etc). It wouldn't be common to have operator-settings-bar, tool-shelf, properties-shelf, and properties editor open at the same time:
Also note that many other apps have their tool settings in a top-bar, e.g. Photoshop, Krita, ZBrush, etc. So it's something users would be familiar with.
Don't really want to sound negative. I'm just not really convinced this would be such a great idea :)
Added subscriber: @brecht
Updated the task description to show the answers which we agree on (at least from what I can tell).
Eeeh, that's about twice the size it has now with default DPI, don't think we should go that far.
But you agree that the upper sub-bar should have header height and lower sub-bar be higher is a good start? We can still find out the exact factor. Just good to know (current code requires all global sub-bars to be header height which had to be changed).
Yeah, I'm afraid that makes most sense. A bit tricky to implement though ?
I actually think the points @DuarteRamos makes are quite good. When alternating between tweaking basic and advanced settings, one would have to re-open the popup over and over again.
To be clear, if the "More..." popup would contain all items, it would simply be the F6 popup, just spawned from a button rather than a shortcut.
If we have the chance to re-use the F6 popup for this, I'd say this is a good idea to avoid confusing users with a similar version of it.
E.g. (De)select All ({key A}): by default it uses "Toggle" behavior, but gives you the options to "Select", "Deselect", "Invert" instead. I doubt users would use this commonly since selecting and deselecting is usually done by pressing {key A} multiple times, and inverting is usually done using {key Ctrl I}.
So I think showing this option by default is more confusing than useful, would rather have it hidden in the "More..." popup.
Not sure on that. If a tab can be deleted, users would expect to have a 'x' icon in the tab to do so ("What, I can add tabs but don't remove them??!"). Not sure if users would check the context/RMB menu really.
Also, worth considering consistency here: At some point the UI may contain removable tabs in more places, wouldn't they contain the 'x' icon at least?
@JonathanWilliamson, so you're against this?
Thing is, users may spend quite some time setting up their workspace - setup layouts, set viewport settings, enable/disable add-ons, override keymap items, etc. And then, they press "Delete" instead of "Rename" in the RMB menu... doh!
We could alternatively try to solve this with user-counts. Deleting a workspace would set real users to 0 and add a fake user (so it's not deleted on file reload). However, only advanced users would know how to bring them back, and that they are still there. Maybe we could solve this though (asset manager? Add deleted workspace to "Add Workspace" popup?).
@brecht raised this point, see https://developer.blender.org/D2758#inline-26924.
Sorry for the long wait. :)
Concerning the wasted space the reason why the sidebar should be switchable - where the user can easily show/hide it if needed, depending on the layout and tool used. The global bar suffers from the same issue at this time.
The issue of space is a real one, however it is also one that the user can opt in too.
Currently the Last Action hovers over the Outliner and the pop-up menu is still mouse focused. That leads to loosing the menu itself (an example is dragging the sliders where the mouse can be outside the menu region).
Depending on the theme and the size of the editor bellow, it can blend with the surrounding, making it visually cluttered.
While i do understand that is still WIP and some / all of the concerns will be addressed, dealing with possible complexity of operators needs to be an option for consideration.
The reasoning behind this is - for a new user, playing with settings to learn to ropes of a tool is a must. A persistent overview of all the options available helps greatly with it. If there is attrition, where you need to press the button each time in certain cases, instead of pressing it once ( for the operator options bar to show up and leave it as long as needed) can cause some frustration.
Again, these are observations on the current state, and probably temporal. :)
Added subscriber: @Lapineige
This task is rather outdated, the design changed quite a bit. Closing this together with #50845.
Changed status from 'Confirmed' to: 'Archived'