Reorganizing the GUI
Open, NormalPublic

Description

You can place proposals and mockups that deal with the organization of the GUI here.

Some of the issues:

  • Blender doesn't communicate the hierarchy of functions well, or use the "Gestalt principles" well. Examples: The Mode switcher, one of the most important GUI elements in the program, is just one of similar looking list menus on the 3d View's header. The buttons in the Toolshelf all look the same, despity varying importance. The button the render out the scene is placed in the Render properties section of the Properties editor. Some unrelated values are placed as if they affect each other:
  • Some elements are used wrong. For example the Unwrap, Extrude, Delete and Merge buttons look like a combo box (a box where you toggle between options from the list), but aren't ones:
  • Certain categories in the Properties editor are overcrowded (Render, Object).
  • Some of the GUI elements are occupying screen space while being rarely accessed - for instance Display/Shading options in the 3d View's Properties sidebar. Their placement also places the burden of keeping the GUI tide on the user. This issue was described by Brecht van Lommel here - http://youtu.be/ziPLNUfm7KA?t=4m9s
  • Certain areas are disorganized, have low clarity, and so are discouraging to work with (at least for users unfamiliar with these sections). Example:
  • There are no elements or layouts in the GUI that would guide the users that are performing specific tasks. Functions, which usage is required to perform for example Texture Painting, Sculpting, or Retopology, are scattered across the GUI, and so are difficult to remember.

Related Design Tasks:
Tool Settings Location in the UI
Reorganize 3d View Toolbar

Details

Type
Design

Another common problem is using expanded options when a dropdown would be better and save space.
Examples: The BW/RGB/RGBA options in the output panel (color depth too), Units and Color Management in Scene.
They would be better used as a sort of in-panel tabs, only if they affect the widgets below them (for instance, how they are used in the Duplication panel).

Many of the problems with the Properties Panel could be solved by reconsidering what needs to be there, and in what form.

For instance: an object's location, rotation and scale in 3d space is there, and together with the 3d cursor's location takes up half the vertical screenspace. One thing to debate should be 'does this belong in the Properties Panel, or the Properties Window?'. No matter which you're in favour of, though, it should be much less large and overwhelming, and I will do some thinking about how to solve this.

I'm in favour of more dropdowns/pop-up palettes, and think these could even be done dynamically by allowing the user to collapse the side-panels of the 3d viewport to a minimal bar, as in this example:

-The View options are used rarely enough that they could be in a dropdown
-'Item' contains only the Object's name, and I feel this should be in the Properties Window, not the Properties Panel.
-Display should be a dropdown, and what's more: I feel this should be on the viewport's menubar, and I use an addon that puts them there.
-Shading should also be a dropdown, and could be on the viewport's menubar.
-Mesh Display is useful, but takes up a lot of space? I see why it shouldn't be in the Properties Window, but either a dropdown or a massively reorganised layout is definitely in order here, as I feel it's not worth the space it takes up.
-I've personally never used Motion Tracking, but does this belong in here?
-Background Images belongs here, but could it be improved? I don't use it often, but when I do I think it works fairly well.
-Transform Orientations and Extra Options: I find myself hardly ever using these, but that's also due to how crowded the entire Properties Panel is. If this wasn't the case I'd certainly use these more.

The video output and encoding panels are poorly organized and misleading.
Here's the full proposal on how to fix them.

Some of the changes in the above proposal involve new features, but there are also many small improvements that could be added incrementally.

@Sam Brubaker (rocketman). Splitting out video & audio encoding could be nice.
Note that I think giving Frame Server a prominent position in the UI isn't justified, Possibly frame-server could be removed, though thats another topic.

Here is something to clean up the panels a bit - sub-panels:

Only one would be open at a time - so they work like ctrl-clicking the triangles. That wouldn't close the main panels of course, just previously open sub-panel. This introduces a bit of self-management of the GUI, which is currently overly user-managed (the user has to clean up after himself).

All can be collapsed - just click on the triangle of the currently open sub-panel.

I like the cleaner look, and the added ease of use of being able to collapse an entire section of related functions, but this way we do lose the ability to re-order panels absolutely how we want them.
I'm also not really a fan of the 'only one panel at a time' solution, as it's currently found in Zbrush for instance. It's a logical solution for an overabundance of panels, but it feels clumsy and only combats the symptoms, not the underlying cause.

edit: I notice that the abscence of the dividing lines and grab-handles does wonders for making this panel feel less crowded! Sadly this is at the expense of communicating to the user that these can be grabbed; Would only showing the lines when the mouse is in the panel, and the grab handles when the mouse is over the line itself be an option?

@Paweł Łyczkowski (plyczkowski): as @michael knubben (michaelknubben) said, without the lines this is less attractive to the eye, cleaner. But we need some visual information about grab and separation between panels.
I think that very soft (i mean very little lighter/darker than the background) lines can be cool, the same for grab handles.
And why not more visible lines when overlapp is activated (because of less readability).

A little mockup from your image, to let you see what i mean:

About your mockup @michael knubben (michaelknubben), I think that the icons on the tabs are very very cool: we can't read the name vertically as fast as we can recognise the icon. Great idea !
About the panels pinning, that a good idea, and I think that can work very well, especially when the user is not using the overlap option.

But I have reservations about the last operator panel. That kind of popup is not so nice (I'm thinking about some big parameters panels, with lot of options).
Something closer to the F6 popup can be more usable.

Sadly this is at the expense of communicating to the user that these can be grabbed

These can't be grabbed in my mockup : )

we lose the ability to re-order panels absolutely how we want them.

Is that necessarily a bad thing? Let's take my example: Texture, Stroke and Curve settings all affect the Brush. So putting them inside the Brush palette makes the organization correct, while making them auto-collapsing (only 1 open at a time) reduces clutter - so no need for the user's ability to reorganize all panels.

only combats the symptoms, not the underlying cause.

Elaborate please.


Here is a small one:

Sadly this is at the expense of communicating to the user that these can be grabbed

These can't be grabbed in my mockup : )

we lose the ability to re-order panels absolutely how we want them.

Is that necessarily a bad thing? Let's take my example: Texture, Stroke and Curve settings all affect the Brush. So putting them inside the Brush palette makes the organization correct, while making them auto-collapsing (only 1 open at a time) reduces clutter - so no need for the user's ability to reorganize all panels.

In a lot of case, we need some particular panels to be on screen, while the rest is at the bottom (off-screen).
For exemple, you may think that Sampling, Light Path and Volume sampling needs to be attached.
But personally I rarely use Volume Sampling, while I use sampling all the time, and light path when i'm on the rendering step.
So I move them off-screen when i'm using others tools.

If that was no need to have multiple panels, why are they there ?

About the secon mockup, item+transform in 1 panel is a very good idea.

Tackling the multitude of view settings with sub-panels (I would still prefer a popup though):

Not so readable, may need more shift to the right.
But a good idea. Better organization.

It looks cleaner, but you're giving up customisability, while taking up more space.
I realise those parts can't be grabbed, but that's a regression in functionality. This could be forgiven if it would solve other issues, but I don't fully believe that it does. I also don't enjoy auto-collapsing (one panel at a time), as I find it cumbersome in practice. I can elaborate on that at a later time.

The way I see it, the underlying problem lies in three seperate areas:
-There's a LOT of information in the properties panel. This is partly because some of it doesn't belong here (and I believe there's a consensus about this so far), and parly because it's being displayed in an overly verbose way (for instance, you could bring the Transform panel's loc/rot/scale section down to three lines, with a combined x/y/z box)

  • The graphics try to communicate all the information to the user, all the time. Dividing bars, grabhandles, collapse-indicators... subpanels solve this, but at the expense of functionality. I think having some of this information only be shown when the cursor hovers over the element could go a long way towards making the panel clearer, when information isn't actively shouting out its function all the time.

-The only way to organise and navigate this information that's available to us right now is collapsing/moving panels and scrolling.

We have to make sure we don't just solve one of these, and give each problem equal attention.
Tabs could certainly help, and I'm of the opinion that it doesn't make sense for them to exist in the Tool panel but not the Properties panel. Either we decide that tabs aren't a good solution, or the Properties panel should get them as well. This aids in organisation, and I think is a more elegant solution than subpanels.

I think the question of which information belongs where is the most pressing one right now, and we're more likely to get anywhere by brainstorming together. This might be easiest if we can share screens and make annotations, so if anyone from the UI team's up for a Hangout conversation about this, let me know.

for instance, you could bring the Transform panel's loc/rot/scale section down to three lines, with a combined x/y/z box

Sounds good. Could you make a mockup of how exactly?

  • The graphics try to communicate all the information to the user, all the time. Dividing bars, grabhandles, collapse-indicators... subpanels solve this, but at the expense of functionality. I think having some of this information only be shown when the cursor hovers over the element could go a long way towards making the panel clearer, when information isn't actively shouting out its function all the time.

I was also thinking about hiding drag areas and dividers and adding a "Customize UI" button that would show them, along with other options, like checkboxes to hide unused panels. Any thoughts on that?

This aids in organisation, and I think is a more elegant solution than subpanels.

I'm currently trying to design a display settings popup. I could use also some mockups by other people.

I think the question of which information belongs where is the most pressing one right now, and we're more likely to get anywhere by brainstorming together.

+1 to that, see above.

I sure can :D

I coloured it as an experiment, but we could also colour the text. If we go with either of those though, there will be clashes with the colours of animated values, so on second thought that's not great.

I really like your suggestion of having a Customise UI button and hiding this functionality otherwise. Good call! I've thought about this before, but kind of forgot about it. I'd also like to have the 'customise ui' option in the rightclick menu, on any item in the panel.

I sure can :D

But that's not readable at all. Where are the labels?

Note that the multi button drag feature relies on button being on a column, so that will most likely break it.

@Paweł Łyczkowski (plyczkowski) It would still have the labels, ofcourse. This was only to show the widget itself, in comparison to its old version.
This combined version will show less decimals, but I think the current system of showing 5 decimals even when there shouldn't be any is very noisy looking without imparting useful information.
When there are no decimals, just display a number as 5, not 5.0 or 5.00000

@Kévin Dietrich (kevindietrich)
That's true. I personally don't feel that's such a terrible loss, but it *is* a regression.

@Kévin Dietrich (kevindietrich)
That's true. I personally don't feel that's such a terrible loss, but it *is* a regression.

For this reason, and because people often don't want the toolbar to take so much screen space (this implies a narrower window), I think that not so usable.
Especially it is not possible to enter decimals, except with a larger toolbar.

About the background color, individually it's cool, but I think that will create more distractions for the eye. And people can learn very fast that the X value is on left side, y on center, etc. So without color, that's not a problem.

About tabs in the properties, that's very consistent. Tabs on the 2 sides, or no tabs. And in this case, properties needs tabs, now it's a big mess.

About a Customise UI button, can you make a mockup ? Because that's sound good, but i thik that can "hide" this possibility of customisation for users.
Is it not better to show the line + grab handle on only 1 panel, when the mouse is over it ?

As kevindietrich said, having the XYZ buttons horizontally will break the multi button editing functionality.

I use it all the time to set XYZ values like scale, and I wouldn't like to lose it..

Campbell Barton (campbellbarton) triaged this task as Incomplete priority.Sep 18 2014, 8:58 AM

@Paweł Łyczkowski (plyczkowski) - can you constrain the scope of this task?

Reorganizing the UI is fine, but this looks to be everyone suggests random ideas for the UI with not much direction.

This gets hard to manage and usefully respond to each suggestion. - splitting off tasks is an option too.

Maybe I'm being too strict here, but I think end result of these kinds of open-ended tasks is we get many comments but not much useful outcome.

@Campbell Barton (campbellbarton) I can split tasks off, but I don't really want to spam the list more. I would prefer to do that if there was a decision from the module owners that an idea looks decent, and let's explore more and later try it out in a prototype. That's would be the useful outcome in my view.

It's true that going through long discussions is cumbersome, and some things get buried in time - that's why I created a doc where I gather the ideas that are worth exploring IMO (not just mine) in an organized fashion - concise description, sections and a table of contents. It's like a report of some of the stuff done in such threads.

About splitting this task, I think we you can create a specific task about what we said about toolbar: grab handles and separating lines (+ the "popup" idea).

And 1 about the video & encoding panel.

@Paweł Łyczkowski (plyczkowski), @Campbell Barton (campbellbarton) what I think works well for splitting tasks is to first create an Overall Task (such as this one) and then add individual items as Subtasks. This way the discussions can stay constrained while also following a consistent thread. In this case, this task would set the goals and direction while the subtasks would contain the discussions and actions for individual tasks.

@Jonathan Williamson (carter2422) Sounds good. As not to unnecessarily spam tasks - can you or Pablo create these subtasks if you see an idea you deem worth pursuing further, at a time where such a task may become relevant (UI developers running out of TODO's for instance)? Or even when an idea seems good enough, and has low probability that it will become irrelevant in the future due to other development.

I don't have that much free time, but if this task becomes too long and cumbersome to skim over, I can summarize it in more concise reports from time to time.

Also, there are two candidates for subtasks in the description of this task (I don't have the authorization to move tasks).

Here is a mockup for the "Customize UI" button I mentioned:

Here's my small proposal. When menus are collapsed in the header, they could keep the same layout.

I think this makes it more complex and less user-friendly.

Consider that moving outside of the menu bounds results in a 'failure', because that closes the menu again, and that with this redesign you're forcing the user to move up only a little bit, and then move sideways in a straight, narrow line. In the current design, the width of the text means that there's a much larger target that can't as easily stray from.
This seems like it requires more surgical precision from the user, and doesn't offer equally compelling usability-gains to balance that out.

I would move all attributes from all view properties to regular properties window.


I totally disagree with that proposal. In fact taht just remove the properties bar, and hide all the tools, in addition to disperse them.

For the display and shading panel, that's impossible to add all these buttons in the header shading's mode selector.

For the background image, it is less convenient, and that will add the tools.
For the transform, you are not always using the properties view, and not always on the object part. For example, when i want to delete some keyframe, i go here and not on the properties view.

And so on.

@Albert (wevon) +1 to the general idea, since the properties sidebar is a mess where things that don't fit anywhere else go. Or where display settings which really shouldn't be persistent elements (that stay on screen) are. But these arrows don't give us much. Each one is it's own separate design problem. I'd be interested to see more concrete mockups, since I'm also trying to tackle the problem.

"For the display and shading panel, that's impossible to add all these buttons in the header shading's mode selector"
Why not? All these parameters could be inside camera attributes.

"For the background image, it is less convenient, and that will add the tools."
Mudbox and other softwares use cameras with linked image planes

"For the transform, you are not always using the properties view, and not always on the object part. For example, when i want to delete some keyframe, i go here and not on the properties view"
You don't uses regular properties window because you have a duplicate attribute in properties view, that's all. I normally have both of them active.

With a good scene explore I don't see any problem with these proposal.

"For the display and shading panel, that's impossible to add all these buttons in the header shading's mode selector"
Why not? All these parameters could be inside camera attributes.

How/why do you want to put all of that:


In the 3D view header's shading selector, or inside camera attributes ???

@Albert (wevon) +1 to the general idea, since the properties sidebar is a mess where things that don't fit anywhere else go.

I agree, we need a better organization for these tools.

"For the background image, it is less convenient, and that will add the tools."
Mudbox and other softwares use cameras with linked image planes

Why not, a camera linked image in back ground. But in this case, just on the camera background, and the rest on the 3D view.
Because of your example, i was thinking you want to displace all the option in the camera panel...

"For the transform, you are not always using the properties view, and not always on the object part. For example, when i want to delete some keyframe, i go here and not on the properties view"
You don't uses regular properties window because you have a duplicate attribute in properties view, that's all. I normally have both of them active.

Sorry, I spoke too soon. After reflections, that's more consistent.

About the properties panel, I think it is usefull: the big difference with the toolbar is that the toolbar just show some tool, and the properties panel show... properties.
For instance, the 3D Cursor properties has no place in the toolbar.
I think we need to think carefully about it. All the properties we need in the 3D view (witch are used less often thant tools, but witch are also important to have within easy reach) have to be here, and the others... It depends.
For instance, the grease pencil properties (and yeah, tools) need to be in the 3D view. There is no sense to put them somewhere else.
And the "Item" panel, with just the object name, is just taking screen space.

Assuming the default camera can not be deleted and clicking twice the "Z" key can temporarily access their attributes

In the camera transformation properties, could be saved by default (maybe as a data blocks), the position of the orthogonal views and other bookmarked camera planes, I don't really now

Is it not better to have a separate menu for viewport shading ? You don't want to select all the time your camera to be able to change shading and so on.
And for the image texture in background, that's more consistant, but less easy to use and less user-friendly I think.
But for some render background, why not.

http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Properties_Tabs_as_a_customizable_Dock

here's a possible solution to the properties editor tabs not fitting into the horizontal space,as well as some other changes,consisting mainly of transforming the properties editor into a customizable dock.The tabs for each instance of the dock can be hidden or displayed independently, so multiple editors can be utilized for specific areas(see mockup) feel free to comment.

here's the tabs in GIMP 2.8 for comparison, they're similar in many applications using the tabbed "sidebar" format.

But we have a problem: you can't have the 2 windows displayed simultaneously.
And that take a bit more place than a classical tab.

I prefer the idea of this mocup (see before, the @michael knubben (michaelknubben) post): https://developer.blender.org/file/data/ca6dlde5ituhlswahokj/PHID-FILE-dzeoq6aaruyihhvxhu2d/bl_tabs_mockup.png

With a better UI of course, but the idea to show only some panels (even from differents tabs) needs to be considered and further explored seriously.
That's like an double overlap ^^

But in the both cases, we just least disrupt the eye, and we hide lots of tools.

For my own sanity, we should have one "task" aka "discussion thread" per window or topic. One for the render settings, one for the toolbar/properties panels, and additional threads where needed. That way we can be sure that none of these great ideas are lost to the dark depths of the internet.

That being said, this is a topic that I have thought quite a bit about, from the time I started using blender.

I propose that we get rid of the properties panel for a few reasons. The darn panel eats up an enormous amount of window space, and with a little bit of re arranging, every button that exists there already exists in a different location in the menu.

Starting with the topic of screen space, I will give you an example. My blender often winds up looking like this. Granted, this is an exaggerated example, but I am sure it gets my point across.

Why do we need so much repeated information, when most buttons in that menu do the same thing regardless of which 3D view your mouse is currently over?

For example, you can type in the object or cursor coordinates in any of the properties panel, and the result will be the exact same. All that information is duplicated all over the place the second you have two properties panel on screen at the same time.

In the name of screen space, it makes sense to only include the viewport depenant buttons in the 3D viewport. All other buttons can be located elsewhere, with the exception of tools. I can give formal definitions of these at a later time.

That being said, let us move all the buttons that do not care what viewport you are looking at to either the properties window or the information window.

This change makes sense, and I am suprised it has not been done already. There are two other buttons up there that change what "mode" blender is in, why not have a third? (the two buttons I refer to is the scene button and the render engine button.

The header in blender has the same problem as the properties panel. It has functions that do all sorts of different things. I propose that we use that header for all drawing mode related functions. This includes changing the shading mode, the viewport background, viewport focal length and clipping distance, and so on.

Even the motion tracking menu could be moved down to the bottom.

Next we get rid of the view, select, add, and object menus. Like the properties panel, they have information that is duplicated all over the user interface, and is so long and convoluted that nobody uses it anyway.

Let's do some cleanup. The add menu is identical to the create menu in the toolbar. The select menu is a "tool" so it can be moved to the toolbar. The object menu has a lot of things that only exist in hotkey form, but that is a discussion for another time. The view menu relates to the drawing of the 3D view, so it can remain in the header.

There is a lot more that could be said, but in conclusion this helps to solve the problems of inefficient screen space usage. Not only that, but this gives context and reasons for why buttons should be placed where. Mode changing buttons go in the info window. Buttons that manipulate objects (also known as tools) go in the toolshelf. Buttons that change the drawing style of the 3D view go in the header. Things like specific coordinates go in the properties window. If you quick access to the coordinates of objects, simply have two properties panels. open at the same time. If absolutely necessary, the properties panel could still exist with only the coordinates of the active object, the 3D cursor, and the last used operator properties.

In the name of screen space, it makes sense to only include the viewport depenant buttons in the 3D viewport. All other buttons can be located elsewhere, with the exception of tools. I can give formal definitions of these at a later time.

That being said, let us move all the buttons that do not care what viewport you are looking at to either the properties window or the information window.

This change makes sense, and I am suprised it has not been done already. There are two other buttons up there that change what "mode" blender is in, why not have a third? (the two buttons I refer to is the scene button and the render engine button.

I agree with that idea. Ok that is a 3d view 's relative selector, but it apply to all the 3d view, and we already have mesh information in the top side of the Blender's window. That makes sense.

The header in blender has the same problem as the properties panel. It has functions that do all sorts of different things. I propose that we use that header for all drawing mode related functions. This includes changing the shading mode, the viewport background, viewport focal length and clipping distance, and so on.

I agree with that (but it needs to be carefully explored). I often found users who want the matcap selector, or the lock camera to view, to be located in the header.

Next we get rid of the view, select, add, and object menus. Like the properties panel, they have information that is duplicated all over the user interface, and is so long and convoluted that nobody uses it anyway.

Let's do some cleanup. The add menu is identical to the create menu in the toolbar. The select menu is a "tool" so it can be moved to the toolbar. The object menu has a lot of things that only exist in hotkey form, but that is a discussion for another time. The view menu relates to the drawing of the 3D view, so it can remain in the header.

There is a lot more that could be said, but in conclusion this helps to solve the problems of inefficient screen space usage. Not only that, but this gives context and reasons for why buttons should be placed where. Mode changing buttons go in the info window. Buttons that manipulate objects (also known as tools) go in the toolshelf. Buttons that change the drawing style of the 3D view go in the header. Things like specific coordinates go in the properties window. If you quick access to the coordinates of objects, simply have two properties panels. open at the same time. If absolutely necessary, the properties panel could still exist with only the coordinates of the active object, the 3D cursor, and the last used operator properties.

Yeah there is a lot of duplicates. I agree with that, but we have to think about how we can do that without hiding all the non-duplicated tools. And there is another problem: that takes a lot of screen space in the toolbar.
In return that makes tools used regularly more visible and accessible.

In summary, a lot a good ideas to explore. We need to do more mockups and thninking about that (in a specific task ?).

In the name of screen space, it makes sense to only include the viewport depenant buttons in the 3D viewport. All other buttons can be located elsewhere, with the exception of tools. I can give formal definitions of these at a later time.

That being said, let us move all the buttons that do not care what viewport you are looking at to either the properties window or the information window.

This change makes sense, and I am suprised it has not been done already. There are two other buttons up there that change what "mode" blender is in, why not have a third? (the two buttons I refer to is the scene button and the render engine button.

I agree with that idea. Ok that is a 3d view 's relative selector, but it apply to all the 3d view, and we already have mesh information in the top side of the Blender's window. That makes sense.

I disagree. It does not make sense to see mode in which is active object in a Video Editing screen layout.
This piece of info is influencing only UI of a 3DView Editor in a Scripting, Game Logic or Compositing screen layout.
A problem in Blender is that UI is too much dependant of active object.
When skinning a character, armature can be in pose mode and mesh in weight paint.
Actually, we can have an object in sculpt mode and another one in texture mode and switch from one mode to the other by changing active object with a right click.
In the future of Blender, maybe that UI could display caracteristics of 2 modes at the same time for better ease of use.

I think that it would be a mistake to give too much importance to modes of active object by putting this switch in an info bar, present everywhere.

The header in blender has the same problem as the properties panel. It has functions that do all sorts of different things. I propose that we use that header for all drawing mode related functions. This includes changing the shading mode, the viewport background, viewport focal length and clipping distance, and so on.

I agree with that (but it needs to be carefully explored). I often found users who want the matcap selector, or the lock camera to view, to be located in the header.

I agree with that. Most of display properties can be toggled on/off. A display menu could group them and use same checkboxes that the brush menu.
I think that we should keep settings with numeric fields in view properties panels. Because it is fastest to scan than pop-ups.
But instead of having motion tracking and background images panels that are visible even if they are not use. This panels could appear in Properties column only if their chekbox is enabled in Display menu.

Next we get rid of the view, select, add, and object menus. Like the properties panel, they have information that is duplicated all over the user interface, and is so long and convoluted that nobody uses it anyway.

I am using menus. Each time, I don't remember exactly the name of an operator and I cannot find it by using search.
They are reminders and grouping of specials menus that you cannot guess their existence like Ctrl A, Shift S, Ctrl V, Ctrl E, Ctrl F looking at toolbar.

I am using shift A shortcut to add a rigify armature. Does it mean that the shift A menu should disappear, too? How user could understand that he can call menus and don't use toolbar without these reminders in header?

In the name of screen space, it makes sense to only include the viewport depenant buttons in the 3D viewport. All other buttons can be located elsewhere, with the exception of tools. I can give formal definitions of these at a later time.

That being said, let us move all the buttons that do not care what viewport you are looking at to either the properties window or the information window.

This change makes sense, and I am suprised it has not been done already. There are two other buttons up there that change what "mode" blender is in, why not have a third? (the two buttons I refer to is the scene button and the render engine button.

I agree with that idea. Ok that is a 3d view 's relative selector, but it apply to all the 3d view, and we already have mesh information in the top side of the Blender's window. That makes sense.

I disagree. It does not make sense to see mode in which is active object in a Video Editing screen layout.
This piece of info is influencing only UI of a 3DView Editor in a Scripting, Game Logic or Compositing screen layout.
A problem in Blender is that UI is too much dependant of active object.
When skinning a character, armature can be in pose mode and mesh in weight paint.
Actually, we can have an object in sculpt mode and another one in texture mode and switch from one mode to the other by changing active object with a right click.
In the future of Blender, maybe that UI could display caracteristics of 2 modes at the same time for better ease of use.

I think that it would be a mistake to give too much importance to modes of active object by putting this switch in an info bar, present everywhere.

For the mode selector, I said that because we already have some information that are not used in all kind of screen, but related to the mesh.
But after more reflexion, that can give a "global" appearance to this selector. And this is nonsense.

The header in blender has the same problem as the properties panel. It has functions that do all sorts of different things. I propose that we use that header for all drawing mode related functions. This includes changing the shading mode, the viewport background, viewport focal length and clipping distance, and so on.

I agree with that (but it needs to be carefully explored). I often found users who want the matcap selector, or the lock camera to view, to be located in the header.

I agree with that. Most of display properties can be toggled on/off. A display menu could group them and use same checkboxes that the brush menu.
I think that we should keep settings with numeric fields in view properties panels. Because it is fastest to scan than pop-ups.
But instead of having motion tracking and background images panels that are visible even if they are not use. This panels could appear in Properties column only if their chekbox is enabled in Display menu.

I agree about numerical input.
And i think a lot of properties can be converted to icons to use less screen space.
Because we have that problem: Currently the screens are wider than high (in a ratio of about 1.7). So we can take more vertical space than horizontal one. And users will more often split the view vertically when they used lots of views (except for some particular cases, like with the timeline). Especcialy for the 3d view.
So more options in the header meens more horizontal screen space used.

I think the idea of "floating" toolbar panel can be great in the case that @Ian Gallacher (DoctorShenanigan) showed.

Next we get rid of the view, select, add, and object menus. Like the properties panel, they have information that is duplicated all over the user interface, and is so long and convoluted that nobody uses it anyway.

I am using menus. Each time, I don't remember exactly the name of an operator and I cannot find it by using search.
They are reminders and grouping of specials menus that you cannot guess their existence like Ctrl A, Shift S, Ctrl V, Ctrl E, Ctrl F looking at toolbar.

I am using shift A shortcut to add a rigify armature. Does it mean that the shift A menu should disappear, too? How user could understand that he can call menus and don't use toolbar without these reminders in header?

Indeed there is that shortcut issue...

As I said, we must think about that more further. Why not opening a new task ?
Because a lot of good idea are hidden now.
For instance, the video encoding panel....

In the name of screen space, it makes sense to only include the viewport depenant buttons in the 3D viewport. All other buttons can be located elsewhere, with the exception of tools. I can give formal definitions of these at a later time.

That being said, let us move all the buttons that do not care what viewport you are looking at to either the properties window or the information window.

This change makes sense, and I am suprised it has not been done already. There are two other buttons up there that change what "mode" blender is in, why not have a third? (the two buttons I refer to is the scene button and the render engine button.

I agree with that idea. Ok that is a 3d view 's relative selector, but it apply to all the 3d view, and we already have mesh information in the top side of the Blender's window. That makes sense.

I disagree. It does not make sense to see mode in which is active object in a Video Editing screen layout.
This piece of info is influencing only UI of a 3DView Editor in a Scripting, Game Logic or Compositing screen layout.
A problem in Blender is that UI is too much dependant of active object.
When skinning a character, armature can be in pose mode and mesh in weight paint.
Actually, we can have an object in sculpt mode and another one in texture mode and switch from one mode to the other by changing active object with a right click.
In the future of Blender, maybe that UI could display caracteristics of 2 modes at the same time for better ease of use.

I think that it would be a mistake to give too much importance to modes of active object by putting this switch in an info bar, present everywhere.

Is it any stranger then having the render mode and scene options available when you are doing a "composite only" render? I agree with the fact that you can have two different objects in two different modes. That is kind of weird.
Really, I feel like the button could go in either place. Not to big a deal. Although, like I said it is a button that changes every 3D view out there, not just one of them.

The header in blender has the same problem as the properties panel. It has functions that do all sorts of different things. I propose that we use that header for all drawing mode related functions. This includes changing the shading mode, the viewport background, viewport focal length and clipping distance, and so on.

I agree with that (but it needs to be carefully explored). I often found users who want the matcap selector, or the lock camera to view, to be located in the header.

Seems like we agree to put display and rendering options in the header. Quite frankly, it makes sense. It takes the some of the load of remembering where these darn buttons are off of the user.

The biggest question is if we want these buttons to be text only or icon only or both. There is quite a mix and match going on in the header.

I agree with that. Most of display properties can be toggled on/off. A display menu could group them and use same checkboxes that the brush menu.
I think that we should keep settings with numeric fields in view properties panels. Because it is fastest to scan than pop-ups.
But instead of having motion tracking and background images panels that are visible even if they are not use. This panels could appear in Properties column only if their chekbox is enabled in Display menu.

Next we get rid of the view, select, add, and object menus. Like the properties panel, they have information that is duplicated all over the user interface, and is so long and convoluted that nobody uses it anyway.

I am using menus. Each time, I don't remember exactly the name of an operator and I cannot find it by using search.
They are reminders and grouping of specials menus that you cannot guess their existence like Ctrl A, Shift S, Ctrl V, Ctrl E, Ctrl F looking at toolbar.

I am using shift A shortcut to add a rigify armature. Does it mean that the shift A menu should disappear, too? How user could understand that he can call menus and don't use toolbar without these reminders in header?

Having the operators as reference is really handy. I am not suggesting that we get rid of the buttons. I am saying that we move them to more logical locations. If you ever need to remember a hotkey, hover over one of the buttons in the toolbar.

Shift+A will still work. That menu will still exist, but not in the header.

I can make a mockup for this once we agree on the icons for the header. I suppose the properties panel will still exist for anything numeric, with the possibility of the user being able to add buttons there.

How feasible would it be for the operator settings to still exist if you undo? For example, you extrude and then scale. You decide that you do not like how you scaled it, so you undo. Currently, you are not able to change the extrude settings without undoing again and re-extruding.

Meh… We end up again with a wall of text, with three-level quotes… Please, this is not a forum.

Should this one be closed now (and open split ones)?

@Bastien Montagne (mont29) This wall of text (which is what you get when talking about UI, since there are multiple ways solutions can go) is not really for the devs to read, it's more for the designers. And I do read it. To see a summed up "report" of the more polished ideas (not all polished enough for a design task though), nicely divided into sections and with a table of contents, you can go here. This "report" is also not for the eyes of the devs though, it's rather for the UI module owners.

You can kick this discussion out of here of course, but that would be unfortunate IMO, because the quality here is a bit better than on BA.

Bastien Montagne (mont29) raised the priority of this task from Incomplete to Normal.Oct 15 2014, 10:15 AM

Hi.

I would like to have tabs for any window. As this makes workflow much better.

Here is i would like to show you how cool tabs in modo/houdini: http://youtu.be/JfYe1vTNPO0

Also "+" button is important to add new tabs.
Also, "x" button on a tab is important too. To close a tab quickly.

PS: in modo i had lags a bit because of recording.

Here's a little functionality demo I made , that I think would really work well to clean up the properties editor.It separates Scene/organization from object properties. It would also make a practical place for a layer manager, and make it easier to interact with the outliner.
full blurb here:http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Properties_Tabs_as_a_customizable_Dock


.. goes and hides under a rock until the war is over