There could be a Panels menu in header of the editor as a reminder. This way, layers could be also used with View Properties.
Panels| Properties
| Toolbar | Add & Delete
[INDENT=3]| Adjust
| Grease & Measure
[/INDENT]
[INDENT=3]| History
[/INDENT]
[INDENT=3] | Keyframes
| Transform
| Rigid Body | Display Used Layers by this Panel
[/INDENT]
[INDENT=5] | Show it on Layer 1 [ ]
| Hide it on Layer 2 [v]
| Show it on Layer 3 [ ]
| Show it on Layer 4 [ ]
[/INDENT]
Back from my travels, so I’m around full time again.
Showing the layers in the menu is not a bad idea. However, I’m afraid you wouldn’t be able to quickly see in a glance (or remember) what panels are on which layers. If that is correct you would have to click and scan, on average, 2.5 layers before getting the right set of panels. I think that customisable sets of panels is a good idea, but perhaps they should be named like tabs, or get custom icons perhaps.
I’ve made some quick mockups that show the idea of separating more clearly the operator buttons from operator properties. This clearly takes up much more space, but I think that it is probably worth it. It also paves the way for building customisable panels. The reasoning here is the following:
What do you think? Does this distinction make sense? Are you happy to lose this space from the viewport so more buttons can be shown?
I’ve made some quick mockups that show the idea of separating more clearly the operator buttons from operator properties. This clearly takes up much more space, but I think that it is probably worth it. It also paves the way for building customisable panels. The reasoning here is the following:
[ATTACH=CONFIG]251273[/ATTACH][ATTACH=CONFIG]251274[/ATTACH]
What do you think? Does this distinction make sense? Are you happy to lose this space from the viewport so more buttons can be shown?
The new toolbar - Yes, yes, YES! Need I say I love the idea? 
Very interesting top tool bar, I like the idea of custom menus later as well
Was thinking about a top menu like that myself, it’s a good idea that way we can have the toolshelf for, well, tools and make a better spot for actions.
-I don’t like the idea of displaying a handful of action buttons though, doing this it becomes only a place for new users to learn the hotkeys.
-Also think we should avoid making actions as buttons and especially not as icons. Icons are not good for describing detail. There are hundreds of them, too many to efficiently display like that.
-I would be incredibly hesitant to take vertical space from the 3D View. In my opinion this action bar should be maximum 1.5 “rows” “thick”.
If we look at a rough example edit mode “tools” (this being something you can pick up, kind of a mode you enter to use the tool.
What I believe should be in the left panel (toolshelf as it’s known)
-Selection stuff
-Grease Pencil stuff
-Knife stuff
-Ruler stuff
-Editing options
-Any addon editing tools
-etc
And an idea of edit mode action “headers”, these are containers of the operators/actions.
-Transform ->
-Add Shape ->
-Delete ->
-Face edit ->
-Edge edit ->
-Vertex edit ->
-UV Unwrap ->
-Topology edit ->
-Deform/warp ->
-Mirror ->
Personally I would do something like this, but I think many people will not like it.
It involves a row of dropdown menus which must be incredibly well organised, sorted, named and contextual.
Dropdown menus can work well, if done nicely. In my opinion GIMP is a good example of dropdown menus working naturally and sorted pretty well.
I don’t think that it is an insuperable problem.
In fact, if UI is limited to 3 or 4 layers per toolbar, it would not take long to click and scan panel in layers.
And if you are able to enable all of them, with click and shift drag. It would be very quick to see all available panels.
There are more 3D layers in 3DView without names since years.
Of course, it is clearer to use Layer Management add-on and text panels are not so easy to distinguish than different geometries.
You are right. It does not have to use 3D View layers design. Each one could have an abstract icon to consolidate memory of where panels are grouped.
As a customization, it is the user that is responsible to what he does. If he decides to change a panel from a layer to another, it is because it make sense to him. It is adapted to its workflow for the specific production.
So, it should be easy to remind.
And for work in groups, it could follow same rules of the rest of the UI. Blend file’s disposition could not be loaded if load UI option is unchecked.
The idea of menu is just to be sure that you find a specific panel if you scan layers too quickly and did not find him.
It provides an info per panel like Relation panel of object data tab does per 3d object but without the risk to be stored in a panel like in layer management add-on (it is problematic if panel that allows to show/hide panel is on an hidden layer).
So, if a panel is not displayed and the menu says that it should : there is a bug.
It makes sense to put it somewhere in related area. In outliner, you will have to add an extra click and scan according to editor type.
The idea was not to restrict them to 3D View toolbar but to use them anywhere, in VSE, image editor etc…
It is not totally right. Most operators acts like that in Paint Modes.
But there are operators like Dirty Vertex Colors in Vertex Paint Mode or Weight Tools (normalize all, normalize, mirror, invert, clean…) in Weight paint modes that requires redo panel. And probably there are add-ons operator that use it, too.
But most of them have less options than a transform operator. So, maybe you can think of an horizontal redo panel for these modes.
In my opinion, davesf proposal of a minimized floating redo panel that can be opened when needed and moved anywhere is the best one.
In your horizontal toolbar, most of titles are unreadable and are taking space. I don’t think that they are needed when panels are open. The information seems to directly depends on icon readability.
It would be probably more interesting to show panel title only on mouse-over for open panels.
I am not sure that 3 rows are needed. You used one third-party of the space available to display 8 panels.
2 rows is probably sufficient as default.
It would let space for a customizable row. I think that it make more sense than customizable panels in an horizontal toolbar.
It would be probably easier to customize a row by drag and drop icons from the 2 rows above.
And then, the user could work only by showing its customizable row and hiding the 2 default ones.
I don’t think that steal screen space is good idea, this mockup won’t work for me… :no:
I like Rhys idea of dropdowns instead, but what if user would need to use some option very often? He would need to expand dropdowns and look in them everytime he needs something…
Solution to this I think is to allow user to pin category to toolshelf (RMB or drag & drop).
Here is picture to visualise it:
Ribbon 'em All
We don’t want to go back that route.
It is well tested and we know the reaction will be.
[Horizon toolbar = nope; Vertical toolbar = yes]
In all seriousness, other than tools as buttons, the other issue is the distinction between tools and their properties.
That part in dire needs of fixing, or we’ll patch this problem again and again to no real solution.
There are 3 main areas on the 3d view that need to be properly defined, they are
The problem now is, there are properties in tools, tools in properties, and properties panels that shouldn’t be in a mode. ie
Here are few notes that might help…
It is quite common to have toolbox that look like this in graphical applications.
Here, krita’s toolbox showing 32 icons (2 rows of 16). If you avoid tabs and text, you avoid 3dsmax’s nightmare.
It is as simpler as that.
It does not take so much space vertically (can use region overlay) and gives potentially quick access to 64 tools on a widescreen (a little bit more than in trunk’s mesh tools panel that is partially masked by last operator region or hide some in pulldown menus).
I sincerely think that it is a solution that should be considered. Open panels does not need title. It could be displayed by mouse hovering the 3 dot button.
And if you choose a solution like panel layers or Tynkatopi’s mock-up, you can provide a way to avoid to close panels by choosing to not display them.
I think that if that upper toolbar will have autohide functionality, It will upgrade the UI and will not steal space.
The upper toolbar is excellent for icons and when you add a popup menu for more options you can create a great toolbar.
This is just what Blender needs, well done!
That’s very true. These operators would then sit in the horizontal toolbar still. The options in the sidebar would be the options of the tool you’re operating with the mouse (paint/sculpt/grease).
I quite like this myself to be honest. It provides a highly organised and easily navigatable way of showing many non-modal operators using a widely known metaphor. Many operators could go in a top menu bar and the modal operators (e.g. grease and knifes) could sit in panels in the left sidebar.
I especially like this because it frees up space for the redo operator panel to always be visible in the sidebar. I’m hesitant to turn the redo panel into a popup because it shouldn’t really be hidden anyway. Making it into a popup that then is permanently open is perhaps not the best solution.
I’ve started to do a prototype of a menubar. Let’s see what it feels like…
Based on the discussion about tools and tool settings placement, here are five different variations.
1: Tools & Operator panel on the left:
http://www.pasteall.org/pic/show.php?id=57097
2: Tools on left, Operator panel on the right:
http://www.pasteall.org/pic/show.php?id=57098
3: Toolbar on top, Operator panel floating:
http://www.pasteall.org/pic/show.php?id=57099
4: Toolbar on top, Operator panel on the left:
http://www.pasteall.org/pic/show.php?id=57100
5: Toolbar on top, Operator panel on the bottom:
http://www.pasteall.org/pic/show.php?id=57101
I think the first option is the simplest, but we still need to solve the issue of displaying the Operator panel when the toolbar is hidden.
A tabbed horizontal bar with many heterogeneous buttons and styles is quite different from a horizontal toolbar with icons (like zeauro pointed out). The problem is that there just isn’t much space and there are many many operators. An extra small horizontal toolbar might go a long way to aleviate some of the stress and would probably be better than a sidebar that requires scrolling to find what you need. Granted, the mockup with 3 rows of buttons is perhaps excessive. 
Those are very good points. However, I would further subdivide point 1. Tools into 1a. Tool buttons (execute), and 1b. Tool settings or properties. Tool settings are quite different from data properties so making a toolbar without sliders or toggles wouldn’t work so well.
Would anyone object to removing some of the panels in the properties region in the paint modes?
It’s quite nice to see an overview like this!
In #5 it would be problematic to lay out the properties nicely. The labels and the widgets are quite wide so a list like that would be quite wide as well. For many operators the properties probably wouldn’t fit in a single row. Then you could either do scrolling or an automatic double row layout (top-down first? left-right first?), but I feel both are quite clunky.
In #2 the tool settings bar (A) would set next to the normal properties bar (B), because mixing them would be a bad idea. Hiding B would make A sit in the location of A, which would be quite confusing. Also, it would mean even more vertical space is used.
#3 would be problematic for the paint modes I think. The tools area would work nicely with buttons, but not with paint settings (which I imagine you wouldn’t want in the floating panel).
I find that #1 and #4 are both acceptable. What about a slight mix?
A conventional menu in the top bar could free up quite some space for more frequently used command buttons (icons or text) and operator settings and redo properties in the sidebar.
@ack-err, I see that the horizontal toolbar is getting more supports, I’ll use it to do worst screen resolution study and try to narrow down where the operator panel should be.
I have another study on how to deal with Paint/Sculpt/weight paint/vertex paint mode tools as horizontal toolbar. Will show that later. For now let’s focus on 1 case at a time.
