Top-bar: Open Design Questions
Open, NormalPublic

Description

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.
T50845 is the parent task of it, in here we should focus on the questions mentioned below.

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

  • Should it be possible to hide the top-bar in regular layouts? -- Yes, hiding should be possible.
    • 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).
  • Should top-bar be hidden in fullscreen area mode (Alt+F10, then Alt+F11)? -- Yes. But not in maximized area mode (+Space+bar, or Ctrl+).
  • How tall should the top-bar and its sub-bars be?
  • If there are no operator settings to display, what should the top-bar show instead? A mostly empty bar (e.g. on startup) might be confusing.

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.

  • In current mockups "More..." button is aligned to the right. How would it behave if space is too limited to show all buttons? Would it overflow other items? (Note that it's currently possible to scroll the content horizontally if needed, like in headers.)
  • Would the popup invoked by "More..." only contain advanced operator settings or all of them (current F6 popup)?
  • What would the top-bar display if an operator only has advanced settings?
    • 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

  • How exactly should deleting work? 'x' icon on active tab? Or on hover too?
    • Should we show a confirmation popup on deletion? Remember, deleting a workspace cannot be undone.
  • Should tabs support reordering (drag 'n drop)? -- Yes, drag 'n drop.
  • Should tabs be sized according to text + icons, or should all be of same width?
  • What about a right click menu for workspace tabs? What would it contain? -- Rename, Delete, Duplicate.

Misc

  • Should we hide screen-layout names from the UI? -- Yes. At least to test it.
  • In current mockups, operator settings contain a button showing the name of the last executed operator.
    • 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?

Details

Differential Revisions
D2758: Global Top-Bar - Initial Implementation
Type
Design

Adding a first round of suggested answers:

Top-bar in General

  • Should it be possible to hide the top-bar in regular layouts?
    • How would that work? Shortcut? Dragging of area edge?

Yes, should be possible. Dragging area edge over threshold should be fine (like with headers).

  • Should top-bar be hidden in fullscreen area mode (Alt+F10, then Alt+F11)?

Yes. But not in maximized area mode (Shift+Spacebar or Ctrl+Up)

  • How tall should the top-bar be?

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

  • In current mockups "More..." button is aligned to the right. How would it behave if space is too limited to show all buttons? Would it overflow other items?

Either overflow or be automatically added after last button, so scrolling like in headers would make it visible.

  • Would the popup invoked by "More..." only contain advanced operator settings or all of them (current F6 popup)?

No strong opinion here.

  • What would the top-bar display if an operator only has advanced settings?
    • Would the "More..." become "Advanced Settings"? Would the first 1-3 advanced settings be shown in the topbar, rest only in the "More..." popup?

I'd say it should show the first 3 items or so.

Workspace Tabs

  • How exactly should deleting work? 'x' icon on active tab? Or on hover too?

No strong opinion.

  • Should we show a confirmation popup on deletion?

Yes, seems reasonable.

  • Should tabs support reordering (drag 'n drop)?

Yes.

  • Should tabs be sized according to text + icons, or should all be of same width?

No strong opinion.

  • What about a right click menu for workspace tabs? What would it contain?

Rename, delete, duplicate, etc.

Misc

  • Should we hide screen-layout names from the UI?

Yes, at least to try if user's are fine with it.

  • In current mockups, operator settings contain a button showing the name of the last executed operator.
    • 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?

No strong opinion.

  • Would the popup invoked by "More..." only contain advanced operator settings or all of them (current F6 popup)?

No strong opinion here.

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.

  • What would the top-bar display if an operator only has advanced settings?
    • Would the "More..." become "Advanced Settings"? Would the first 1-3 advanced settings be shown in the topbar, rest only in the "More..." popup?

I'd say it should show the first 3 items or so.

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"

== Workspace Tabs

  • How exactly should deleting work? 'x' icon on active tab? Or on hover too?

No strong opinion.

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

  • Should we show a confirmation popup on deletion?

Yes, seems reasonable.

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

  • Should tabs support reordering (drag 'n drop)?

Yes.

Yes please :)

  • What about a right click menu for workspace tabs? What would it contain?

Rename, delete, duplicate, etc.

Yes this should be the main way to deal with them, and avoid what is mentioned above

Julian Eisel (Severin) triaged this task as Normal priority.Oct 24 2017, 4:00 PM

Here is mine:

Should it be possible to hide the top-bar in regular layouts?

Sure, just like the tool and properties.

How would that work? Shortcut? Dragging of area edge?

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.

Should top-bar be hidden in fullscreen area mode (Alt+F10, then Alt+F11)?

Yes.

How tall should the top-bar and its sub-bars be?

100 pixels on a non-high dpi screen.

In current mockups "More..." button is aligned to the right. How would it behave if space is too limited to show all buttons? Would it overflow other items? (Note that it's currently possible to scroll the content horizontally if needed, like in headers.)

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.

Would the popup invoked by "More..." only contain advanced operator settings or all of them (current F6 popup)?

Only advanced. F6 would contain all settings (Advanced section can be collapsed though).

What would the top-bar display if an operator only has advanced settings?

Can I get an example of such operator? This should be avoided - but in those rare cases -> empty space + More button.

How exactly should deleting work? 'x' icon on active tab? Or on hover too?

No X, only Delete entry in a popup on RMB click on tab.

Should we show a confirmation popup on deletion? Remember, deleting a workspace cannot be undone.

Sure.

Should tabs support reordering (drag 'n drop)?

Yes.

Should tabs be sized according to text + icons, or should all be of same width?

Same width.

What about a right click menu for workspace tabs? What would it contain?

Rename, Delete, Duplicate.

Should we hide screen-layout names from the UI?

Yes.

In current mockups, operator settings contain a button showing the name of the last executed operator.
Should that call the "Repeat Last" operator?

Yes.

Should "Repeat Last" be in a separate button instead, so it's not mistaken as some "Apply" button?

No.

What would the top-bar display if an operator only has advanced settings?

Can I get an example of such operator? This should be avoided - but in those rare cases -> empty space + More button.

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

  • If there are no operator settings to display, what should the top-bar show instead? A mostly empty bar (e.g. on startup) might be confusing.

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.

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.

  • If there are no operator settings to display, what should the top-bar show instead? A mostly empty bar (e.g. on startup) might be confusing.

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?

I pretty much agree with all of these, except the pop confirmation for delete.

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

Should we show a confirmation popup on deletion?

Yes, seems reasonable.

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

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.

  • If there are no operator settings to display, what should the top-bar show instead? A mostly empty bar (e.g. on startup) might be confusing.

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?

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.

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.

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.

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.

  • It allows the operator bar to be stationary - no jumping UI elements on screen depending on operators usage (sliding when active)
  • Solves the problem of the More button or makes it much less needed - as using almost all the screen height will allow to have a lot of settings before the need to be grouped/hidden for displaying purposes. As the widgets are more bound to width compared of height even taking in account the 16:9 resolution
  • Allows the introduction of Tabs if needed (where the switch between Basic and Advances will be easily reachable) for quick access similarly to the current Toolbar
  • As the space allows (especially introducing tabs) to have different operator tabs active. For instance a modal operator can have it's running tab setting. Of course, this depends on the API itself but it could be an option.

An example of how it would look like (with some notes following numbers on the image):

  1. Info area can have enough space for notifications and displaying the Blend file information
  2. Toggle the operator bar ON/OFF area - allows to hide/ show it. Does it need an icon or a pattern would be enough? Also should give some visual feedback if disabled. In case that is OFF the operator redo button should be in the global bar
  3. Operator tabs - First two are base and advanced settings as the current approach. However other categories maybe be possible. The blueish tab is a modal operator that runs in the background and can also have some settings - like stop/ pause some notification etc. The name is just an example, as the space allow it can be a full name
  4. The operator bar can be re-sizable. The default width goes to the size of the Object Mode pop-up (mode selection). The widget preferably with the labels inside the sliders
  5. The placement of items on the Top bar is optional as it is maybe better to be right aligned (less clutter)
  6. The current operator redo button. In case that the operator bar is closed, it should be placed on the top bar like in the current proposal

Open questions about this mock-up.

  • Does the current like 3d view Toolbar clash with it? Could be solved with placing it on the right - however that will loose some of the visual coherency as placing on the left or making it visually stand out more
  • Where the operator redo should be - always in the global bar or in the operator bar? The first one seems more coherent.

This is just a suggestion about exploring some other way of solving the issue of limited space. Hope that is of any use. :)

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.

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 @Vuk Gardašević (lijenstina), let me finally get back to your proposal. In short, it doesn't really convince me ;)

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.

  • It allows the operator bar to be stationary - no jumping UI elements on screen depending on operators usage (sliding when active)

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.

  • Solves the problem of the More button or makes it much less needed - as using almost all the screen height will allow to have a lot of settings before the need to be grouped/hidden for displaying purposes. As the widgets are more bound to width compared of height even taking in account the 16:9 resolution

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.

  • Allows the introduction of Tabs if needed (where the switch between Basic and Advances will be easily reachable) for quick access similarly to the current Toolbar
  • As the space allows (especially introducing tabs) to have different operator tabs active. For instance a modal operator can have it's running tab setting. Of course, this depends on the API itself but it could be an option.

This point is interesting, mainly because it could help solving the issues of the active tool settings (see T53047). 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?).

Open questions about this mock-up.

  • Does the current like 3d view Toolbar clash with it? Could be solved with placing it on the right - however that will loose some of the visual coherency as placing on the left or making it visually stand out more
  • Where the operator redo should be - always in the global bar or in the operator bar? The first one seems more coherent.

    This is just a suggestion about exploring some other way of solving the issue of limited space. Hope that is of any use. :)

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

Updated the task description to show the answers which we agree on (at least from what I can tell).

How tall should the top-bar and its sub-bars be?

100 pixels on a non-high dpi screen.

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).

In current mockups "More..." button is aligned to the right. How would it behave if space is too limited to show all buttons? Would it overflow other items? (Note that it's currently possible to scroll the content horizontally if needed, like in headers.)

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.

Yeah, I'm afraid that makes most sense. A bit tricky to implement though 💩

  • Would the popup invoked by "More..." only contain advanced operator settings or all of them (current F6 popup)?

I actually think the points @Duarte Farrajota Ramos (duarteframos) 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.

What would the top-bar display if an operator only has advanced settings?

Can I get an example of such operator? This should be avoided - but in those rare cases -> empty space + More button.

E.g. (De)select All (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 A multiple times, and inverting is usually done using Ctrl+I.
So I think showing this option by default is more confusing than useful, would rather have it hidden in the "More..." popup.

How exactly should deleting work? 'x' icon on active tab? Or on hover too?

No X, only Delete entry in a popup on RMB click on tab.

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?

  • Should we show a confirmation popup on deletion?

@Jonathan Williamson (carter2422), 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?).

  • In current mockups, operator settings contain a button showing the name of the last executed operator.
    • 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?

@Brecht Van Lommel (brecht) raised this point, see https://developer.blender.org/D2758#inline-26924.