The old system were to use fullscreen and when you want to access something of the property editor press shift-space. Then you switch between have all info or only the editor.
1 Like
Let me go on a little tangent for everybody else here, mostly fromo a Modo user’s perspective. 
As a reference: That’s very close to what Modo has introduced since Version 13. They added panels to the sides and bottom that can be collapsed or opened by ring menu. To be fair - this was always able and is more of a preset, since Modo’s UI is entirely modular and based around the toolset the developers used to create thw workspaces.
Since they don’t have an equivalent of Blender’s N- or T-Panel integrated into the 3D view they made it as a regular window that can be hidden/shown and pretty much hold any data, UI or whatever you want. Not just a UI shelf but just as much a UV editor, a secondary othographic view, timeline, whatever …
Like so: https://i.imgur.com/6yoTvoZ.mp4
(Yes - Modo has terrible, teriible UI lag when resizing viewports)
Make that easily extendable/modifyable with a good UI editor so that not only Add-On developers but also the regular users can customize their most used tools and UIs to their liking.
Looks like this in action: https://i.imgur.com/yS5blCv.mp4
It felt kind of weird at first but essentially it gets rid of a lot of the workspaces and flows very fluently where you basically don’t even have to switch workspaces any more because you have most windows and toolboxes available anywhere.
BUT - this is Modo. And as much as this works for Modo Blender has a different mentality
When applying this to Blender’s way of working, though, I am not sure if this should really eliminate the N- and T-Panels alltogether. Don’t get me wrong:
I am totally for an empty shelf that is user customizable but it’s maybe not a good idea to have it replace the existing panels. That could for one break too many existing workflows, plugins and compatibilities, probably.
But secondly: Blender isn’t Modo. I’d even go so far as to alledge that Modo took it’s inspiration from Blender’s T-Panel in the first place and merely adapted it to the existing workflow and own modular paradigms. So when we (assumingly take it back) from Modo and adapt it again we might get a sort of GoogleTranslate situation where a concept was adapted for one software and now comes back into the original one.
As Alberto pointed out: In Fullscreen mode a logical panel split would most likely not work. The Sidepanels have the benefit of being integrated into the 3D view and also being not only quick bt very unobtrusive. And yes - I am aware that I even proposed an empty shelf myself a few posts up. 
I didn’t think of the Fullscreen mode, then.
For the sake of an empty customizable panel - here’s an idea:
- Assuming the N-Panel gets used for options and statistics as proposed a few times
- The T-Panel is used for tools and Plugin UIs and…
- …maybe leter on gets a flexible UI editor so that users can extend it themselves
- An empty custom shelf is introduced that can be edited the same way.
The T-Shelf remains it’s own layout, though. So in the empty shelf you could introduce for example:
- Dedicated Rigging Utilities and macros you created yourself
- UIs with the best-of commands from all the tools and Plugins you use the most.
- but also have a mirror of the T-Shelf. The t-shelf would basically be its own datablock.
Then again I am not sure if we’d really need a mirror of the T-Shelf if it’s customizable.
I am also not sure how it would behave with Blender’s different edit modes.
1 Like
There are 2 main benefits of T-Shelf that needed to be mentioned.
As the need grows, the user switches from the default functionality to add-ons.
At some point, basic tools are used mainly as shortcuts (because they are basic), and add-ons become the main tool that needs to be organized. Addons are “enhanced tools”, not “properties”.
- T-Shelf allow to keep lots of addons as well as regular tools. It is a dedicated place for tools.
- T-Shelf allows you to simultaneously access add-ons with object properties in the N-panel, eliminating the need to switch between them, which is very useful.
4 Likes
I think I posted in this thread a long while back, but as the discussion goes on I feel like throwing in my 2 cents again.
I haven’t been totally caught up on the discussion so I apologize if I say irrelevant or redundant things.
Design is solving problems. The sidebar was designed a long time ago, to solve specific problems that were relevant then. Blender is different now, it’s changed a lot, and the problems that the sidebar was originally designed to solved might be solved in better ways. I think we need to ask ourselves not how to improve the sidebar, but rather first ask ourselves what problems it’s solving, and if it really is the best solution to those problems.
Pretend for a moment that we don’t have the sidebar.
-
You want to allow the user to change viewport focal length and clipping values. What’s your best idea to let the user do that? Would you really come up with the idea for a hidden panel that holds many miscellaneous and unrelated things, or would you think it makes more sense to put those options in the viewport shading popover, with all the other viewport-dependent rendering options? Or maybe even somewhere else?
-
You want to allow the user to finely control the 3D cursor’s location and rotation. What’s your best idea to let the user do that? Is it to create some miscellaneous panel? Or would it perhaps be to put it in the tool settings for the 3D cursor itself, and improve the usability and precision of the 3D cursor tool, with gizmos and such? Or perhaps you might think of the overlays popover? After all, the overlays popover is not purely for visual toggles. Changing the grid scale there, for instance, changes the behavior of absolute grid snapping, so being able to change the position of the 3D cursor, next to where it is visually toggled, wouldn’t be out of place.
-
You want to allow the user to edit Annotation layers, change the thickness and color of annotations and change other annotations settings. Is your best idea really to create a miscellaneous panel and put these settings in there, as well as putting most of the settings in the 3 tool settings areas, except leave out all settings but the Placement setting for the properties editor, and include an additional exclusive Onion Skin setting for this new miscellaneous panel? Or would your best/most sensible idea be to simply put these settings in the Annotations tool settings? (Seriously, why does the annotations tool settings have all these settings except onion skin? No, onion skin isn’t even viewport-dependent. And why is Placement the only setting that appears in the properties editor for annotations? Also, if you have the annotations tool out, the sidebar will have two areas in different tabs which contain these same exact settings (except onion skin): View > Annotations; and Tool > Active Tool. Is that not weird to anyone else…?)
–
The sidebar is convenient. But I think it’s convenient for the wrong reasons. I think it’s convenient mostly because it solves unsolved problems, not because it solves them the best way possible. In fact, I think it solves them in a pretty bad way, but because the problems it solves mostly don’t have alternate solutions available in Blender, it seems more important than it is. (In the case of annotations, it provides strange redundancy and inconsistency.)
The reason this discussion has gone on so long, I think, is because there probably isn’t a satisfying conclusion to the sidebar problem as a whole, because a miscellaneous panel just isn’t a good design solution in the first place. Such a panel just gets tangled up in too many areas at once, so there’s no way to satisfyingly handle everything it concerns.
I really think we have to assess each problem the sidebar is solving and seriously ask if it truly is the BEST solution to each of them. I think this will result in many things being moved out of the sidebar, and if the sidebar isn’t found completely empty at the end of that process, at the very least it will be greatly simplified.
From that point approaching things like how to organize addons, readability of tabs, or if the sidebar should be a totally user-customizable thing, and all that etc, will be much easier.
13 Likes
I Totally agree. miscellaneous sidebar is not a good idea from 2.8x series. Why should tool settings, view settings, addon settings, 3D cursor settings be bound together? It doesn’t make any sense. These should be moved to wherever they belong sooner or later(although this doesn’t seem to happen in the near future). This is also why the sidebar gets so crowded with many addons installed.
There are a number of room for improvements:
- Object properties(such as scale or dimensions) belongs to object right-click menu or properties editor.
- Addons belong to 3D viewport header menus(if the addon is operation based) or properties editor(if the addon is object-property based)
- 3D cursor deserves its own popover menu, like snapping and proportional editing. (or transform orientations and 3D cursor can share one popover menu, since they have very similar role)
Plus, (Although this topic is controversal) I believe the tool settings are the only thing that should be left in the sidebar. We should be able to select the tool at the left, tweak the settings at the right. Regardless of editor type.
Because it is a single place for viewport-related items.
Aw, I am familiar with such kind of solution in Sketchup - A2 tools.
It is a floating panel with addons toolset, that you always move to another monitor to see the model and start to work)
To be honest, though I agree that these would be the core problems to be handled, those require new designing and developers’ effort and reviews which is not a small task.
Before those core problems being tackled, we at least need to change the outdated(2.5-ish look) design of the sidebar(which is all this thread is about). Initial suggestion of this thread looks good. For those who don’t know, there’s also a design ready at Blender Developers. Here’s the link to T76023.
There are no evidence that it is outdated, since it works nice.
Please, stop confusing “outdated” and “not like in Maya”.
Don’t forget that the most of Industry standards was designed in the 80-90s, so this is called “outdated”.
That outdated panel is one of the best things that blender2.5 added and basically only the newest software in the industry, modo, have.
1 Like
Let me clarify that
we at least need to change the outdated(2.5-ish look) design of the sidebar(which is all this thread is about)
was talking about the design of it, not the function of it. 2.5 design was made 10 years ago when UI standards were completely different from today’s. Not only 30-year old things are called “outdated”. However I agree that the sidebar still works well(it’s just that it’s not the best way).
What I mean by design is rounded corners, floating design, more obvious(darker) color that makes the sidebar more distinguishable from the back 3D scene.
I think @billrey’s mock-up is the most promising one. Also I see you are a bit worried that it might slow down the user’s workflow while switching between tabs(or list items). I partially agree.
About discoverability of addons:
Luckily I found there was this nice proposal at rightclickselect which matches what I tried to express.
This is the last key to the usability of @billrey’s mock-up. No big list that takes up the precious sidebar area, no worries about addons being hidden due to their large number.(Maybe “Toggle tabs” option can be included too)
About effenciency:
Blender 2.8x introduced new workspace system(with tabs). Each workspace is intended to be used in different workflows. Users don’t need to use 15 addons at a time in a single 3D viewport.
- Inside “Modeling” workspace, user might want to enable some grass, tree, material related addons.
- Inside “Sculpting” workspace, one might use addons that help sculpting.
- Inside “Rendering” workspace, addons related to camera might be used.
Even if the user don’t use multiple workspaces, Normally one doesn’t do modeling, sculpting, texturing, rigging, rendering all at once. We do it step by step, and each step doesn’t require so much addons to be enabled simultaneously. We don’t need to constantly toggle addons on and off all the time. We only need to do it when going on to the next step of the workflow.
Many addons cluttering tab bar is making their names hidden is what really makes the workflow a lot slower. It makes the user “wha… where’s that graswald addon tab?? It’s just a bunch of …s!”
To sum up, I believe @billrey’s mock-up is almost there with only a few more room for improvements.
1 Like
Not exactly - workflow defines if user using them or not.
It depends on the area of use.
Looks like proposal from Alberto - a tab that controls other tabs.
About vertical text - it is ok, if it turned left side up (not right side up, like in modo or Rawalanche’s proposal)
Yes, it has some similarities. What’s different though is that it’s the popover that controls sidebar panels, rather than tab that controls other tabs.
I think that is better left a configure tab to that things instead a icon in the header. but the proposal is good.
I don’t see the difference, except that popover have no reason to be a popover.
As you can from RCS proposal, that popover took the exactly same place as entire tab, hovering the entire N panel.
So it is a popover that pretends to look and work like tab (that takes the exactly same place, hovering the entire N panel by definition), but was not proposed as tab… for some unexplained reason.
I’m glad that the war brainstorming on the siderbar panel has resumed. 
People are just talking about it. It’s just you who tries to turn it into a war.
Obviously people are passionate about the topic. It shows how much developers (in general) underestimate user interfaces. They often wonder why people don’t care about super complex things like dependency graph but spend hundreds of messages arguing about a simple panels of buttons. That’s simply because the code itself is absolutely nothing without the UI.
The UI is pretty much the only way vast majority of people interact with that code, so if this UI bridge between the code and user is bad, that’s all the user cares about. Subjectively, bad code with good UI is still superior to good code with bad UI.
People are not in war about it, they are just passionate about it so they argue a lot, but just having civil arguments is not a war. So let them be.
5 Likes
don’t take me too seriously, I joke, I know people are passionate