Solution to the sidebar panel design

The problem here is that even with vertical layout, there was sometimes not enough space to fit all the tabs in. With horizontal tabs, the whole thing would become overcrowded even with 3-4 default tabs and no addons installed.

My idea is not to have more than 2 vertical tabs (columns), and combined with William’s idea of a dropdown list then it becomes much more extensible than before.
Imo this is better than just one column and a long list, you hit two birds in one place.

Hi.

As some of you already mentioned it, the real issue here is not to make the N panel prettier, but to find a solution for this sidebar that can become vertically cluttered by tabs, especially if the user has activated many add-ons.

As you already know, an add-on is not simply displayed in a tab, but also in an expandable drop-down menu, some kind of “container”. Some addons sometimes have many of them.

Since there is currently no real solution (at least not yet) to fix this “N panel tab clutter”, I decided for the last weeks, to contact several addon developers to ask them if they’d agree to add an option (in the add-on preferences) to let users customize the location of their add-on. …To let users choose where they want it to be placed.

The overall response has been really positive and most of them consented to add this option.

For the moment, I have asked about 50 developers to add this option (some devs have created several add-ons).

  • 15 devs implemented the option
  • 11 devs added this option on their todo list
  • 23 devs haven’t answered me yet
  • 1 dev refused to add the option (preferring the solution to come from Blender itself)
4 Likes

This particular thread IS about the look of the sidebar panel though. That being said, I think the main reason for the sidebar clutter is that Blender’s python API still does not allow addon developers to implement addons in form of custom editors or custom tabs in the Properties editor. That would help addon developers a lot in finding better place to put their addons in. Right now, the sidebar has became a kitchen sink for everyone to throw their addon in.

3 Likes

Hi.

This particular thread IS about the look of the sidebar panel though.

There would be no point of redesigning the “sidebar panel” without fixing this annoyance: the “tab clutter”.

IMO, the right location for add-ons is where they currently are: in the N Panel.

I don’t see how, allowing add-on devs to place their add-ons in the Properties Editor would fix the clutter. It would just move the clutter in the Properties Editor.

The N Panel is a better suited area because add-ons are very accessible there, being very close to the center of the viewport: the distance between the scene and the N Panel isn’t that far, which is good for a speed workflow.

I don’t think that any improve better the look of the sidebar that talk with addons developer to make optional the tab in the sidebar. It’s more improvement that any other decision.

And some of us want to use the viewport without a properties editor. Do you know that we use multimonitor, fullscreen mode, workspaces,…?

For some addons, certainly. And it certainly will be too much to contain them all in there as is. But there’a bound to be addons better fit elsewhere too.

Add-ons can already be placed in expandable drop-down menus in the Properties Editor (Proxify, Animated Render Border, …) but indeed, not as tabs.

Just to make sure that I am on the same page wit everybody else, here. Currently the N-Panel is supposed to be the place where all the Addons are going to be instead of the T-Panel where they used to be in Blender 2.79, correct?

Since there has been a discussion about the T-Panel in another thread I was wondering if an additional empty shelf for custom editors would be really such a bad idea. Obviously there is the danger that addons and everything else could get thrown into it again to create the kitchen sink phenomenon (which is to be avoided).
Yet 3D programs with as many addons as Blender are a large thing and the UI needs to go somewhere.
Also I am not sure if I’m comfortable with only one panel that has to stick on the right side.

I mean - I do like William’s proposal. The drag and drop access seems like a good thing.
But I also do feel like the N-Panel alone could be overburdoned by all the things that are going to be thrown at it. And we probably do need some place to stick additional interfaces, don’t we?

There is a similar topic on RightClickSelect: N Panel Tab Clutter Right-Click Select — Blender.Community
Here are some of the proposed mock-ups (+ what I think about them at first sight):



1.:bulb: Icons instead of vertical tab names (3dddan’s suggestion):

  • I like the idea of icons on tabs (but I am not against vertical tabs either, they don’t bother me that much).

  • Icons on tabs would solve RomboutVersluijs’ whiplash / stiff neck issue. :wink: (vertical tabs)

  • They would probably fix the truncated tabs, as long as there aren’t too many of them.

  • My additional suggestion: maybe there could be a vertical scrollbar or two arrow buttons in case there are too many tabs.

Summary



2.:bulb: Two (or more) tab bars for tabs (@ZachHixson’s suggestion):

  • Would fix the truncated tabs.

  • It is visually not really different than what we currently have, but with two tab bars (obviously). The probability to need a third tab bar is, IMO, quite low.

  • One drawback: the second tab bar (if not full of tabs) shows a solid color for the rest of the unused tab bar: which is a waste of viewport space. Note that on this mock-up, the first tab bar is not full of tabs, but for the second tab bar to appear, the first one would have to be full of tabs.

  • It might probably be simpler to code a double tab bar (rather than completely recreate a new N panel UI).

Summary

42652358c4f14f48ba13697aee057bb2-l



3.:bulb: A button that displays a vertical list of all tabs (_hpx1’s suggestion):

  • It doesn’t seem to fix the truncated tabs.

  • Helps knowing all available tabs & switching to a hidden (truncated) tab.

Summary



4.:bulb: Sub-tabs: (Darknoodles’ suggestion):

  • It would fix the truncated tabs

  • If there are too many tabs, it would be possible to scroll the bar (the first “tab bar” of tabs) with mouse wheel

  • Creates two tab bars (so there’s some waste of space in the unused area of the second tab bar)

  • My additional suggestion: the user could be allowed to re-organize (to group) addons into a custom tab (similar to the option that I suggested to addon devs), maybe with an option displayed in a right-click menu on the tab.

Summary



5.:bulb: Arrows (extra buttons) to scroll up/down: (@JulienKaspar’s suggestion from this post):

  • It is visually very close to what we currently have (1 single tab bar of tabs)

  • Would fix the truncated tabs.

  • Doesn’t create a double tab bar of tabs

  • Arrows clearly indicates that there are other hidden tabs (I like this idea).

  • Using the mouse wheel could probably allow to scroll the tab bar of tabs (I wouldn’t mind if there was a vertical scrollbar in case the tabs don’t fit on the bar)

  • Simple to code (I guess)

Summary



6.:bulb: Arrows, Custom tab names, Axis gizmos that move if N panel is closed and navigation icons placed above the N panel: (@OscarNebeAbad’s suggestion from this post):

  • Arrows (this seems to be a recurrent suggestion among the mock-ups): I think it’s a good idea (that + I’d like to have the ability to scroll tabs with mouse wheel)

  • Custom tab names (seems similar to the option that I have been suggesting to add-on devs) but I don’t see how on the mock-up, this design makes tab names customizable (maybe with a menu that’d appear after right-clicking on the tab).

  • I like the fact that the Axis gizmos could move to the right side of the viewport if the N panel is closed

  • I dislike the navigation icons being placed above the N panel (I made a suggestion about these icons)

Summary



7.:bulb: List of addons: (@Alberto’s suggestion, from this post):

  • tbh, I don’t like this mock-up that much

  • It would fix the N panel clutter but at the cost of not being able to switch to other tabs quickly… It looks like a solution to alternatively show or hide add-ons (with a list) if the N panel is cluttered. It looks similar to the Active Tools and Workspace Settings, in the properties panel, which also allows to hide add-ons in the N panel even if they have been activated.

  • With this kind of list, I have the feeling that it will be slower for the user to switch between tabs (especially the one that don’t fit on the vertical tabs bar).

  • If the user has activated 15 addons, I guess he/she wants to have access to them at anytime.

  • the user should be able to quickly switch from a tab to another one, without the need to display a list to hide a few tabs and display others.

Summary



8.:bulb: About @jfmatheu’s Google Doc.

  • Solution N°1.1 (page 8): A new Editor could perhaps be the solution, as it would be easier to organize add-ons (but there should be a way to customize the location of tabs). In another hand, like for the Properties Editor, I wonder if a dedicated Editor would slow the workflow down or not, because of a longer distance with the viewport. I also wonder if it would un-clutter tabs, because from what I see on this mock-up, there are also vertical tabs on this dedicated Editor. I also wonder if there would be enough vertical space (on low resolutions) for a new Editor (I guess it would be placed between the Outliner and the Properties Editor, wouldn’t it?).

  • Solution N°1.2 (page 8): I don’t like the idea to place all add-ons into the Properties Editor that much (on low resolutions, there’s no room for other tabs at the bottom of the Properties Editor). tbh, I wouldn’t want the Properties Editor to be cluttered by other tabs.

  • About Solution N°2: At first sight, I raised en eyebrow :face_with_raised_eyebrow: trying to figure out how this concept works. I was confused (and I still am a little bit). I tend to think that having a drop-down menu for Sections + tabs can be confusing for (new) Blender users. IMO, the N panel needs to be simple to use and switching between tabs must be fast, intuitive.

Summary



9.:bulb: About @billrey’s suggestion, from this post):

  • I have mixed feelings about this mock-up.

  • I pretty agree with almost all @JulienKaspar comments. He said things better that I would (especially that English is not my mother language) and I think that he made good arguments.

  • I am too a bit worried about the efficiency of the menu. Especially about the number of clicks required to switch from a tab to another. I am afraid it could slow the user’s workflow down. I am afraid that it would take more time than simply clicking on a tab (as we currently do).

  • About the discoverability of tabs: from what I understood, this concept moves vertical tabs into a list. A list that partially hides some of the add-on tabs. :worried:
    IMO, if the user has to organise which add-ons must be displayed at a given time, that’s not really cool. If a user has activated 15 add-ons, he/she should be able to quickly switch from one to another, without having to expand a list to be able to have access to other tabs.

Summary

Screenshot_2020-04-23_at_13.37.02



:point_right: To sum up my point of view:

  • The N panel must be simple and intuitive. The user should be able to quickly switch from a tab to another. Tabs are a very well known concept (it’s used in File Explorers, in Web Browsers, other 3D softwares…). People are used to them. That’s why I would prefer if Blender developers kept the current tab bar.

  • To fix the tabs clutter, I suggest to add a vertical scrollbar (only displayed if there are too many tabs)

5 Likes

In reality I do 4-5 proposals different. I made the last only in response to this thread and I can’t find the other proposals.

The problem is known

  • There are no tabs where you can put addons that can enter other categories, such as create, edit,… where the developers can put things.

  • The T-shelf was removed, which allowed to divide the viewport in two easily distinguishable panels and more space for tabs

There are many ways to solve the problem. The right one in my opinion is to return the T-shelf to its place of origin with some predefined categories where the developers can put tools without having to create their own tabs as a side effect in 2.79. And to separate the addons without categorizing, in the same tab bar or that only use the sidebar the addons with own tabs. It would be a very good solution, tools on one side, addons on the other, so we can make a better mind map of the program, as in 2.79. Right now the tools are spread all over the interface for no reason.

But that’s at a hierarchy level, at a technology level there are also many ways to fix it, icons, lists, tabs that can be without selecting anything, buttons instead of tabs…

The problem is the same as always, with the movement of everything to the sidebar. And forcing it to be on the right any solution that is adding icons next to the icons of the property editor does not look as good as on the left of the viewport. With the sidebar on the left, this problem would disappear.

2 Likes

I like the idea of decoupling addons from others things (view,transform,etc) and that is how I’m doing it currently with my custom pies. Having addons on the left and coupled with the William’s proposal it can be interesting. But where to put the active tools in this case ? Personally I don’t use them but I guess that the devs would not want to hide them or move them to the bottom of the 3d view ?
We have a hard design task here🤯

I kind of agree to this. For now the T-Shelf is mostly intresting for the more painterly workspaces like sculpting and drwing or painting vertex colors or -weights.

When the proposals for using the t-shelf as a toolbox were introduced initially I kind of thought it would go more ito Modo’s direction of offering a quick access to several tools and a way to expand or add tools yourself. Basically I thought that the tools that were already there would just be expanded and clarified better by clearer Icon and color coding.
The way that the tools are very limited and especially fixed by working mode does feel a little wasteful.

I am totally fine with cleaning up the N-Panel and all the discussions around it so far. I do not have any better input for the tabs or structuring proposals right now. All of you seem to have put much more thought into it.
It is werd, that Item Tool and View are also incorporated in the Sidebar. Those are not plugins and some of these need to be either accessed or checked frequently. During work traveling with the mouse to switch between vital areas should be minimzed as often as possible, though.

I kind of fear that it would become a bit like the tool settings - changing the settings for the creation of a new primitve or invoked tool on te lower left of the screen: having to move the cursor and focus away from the object and to the lower left of the screen, then having to open/expand the settings panel and having a disconnect beween looking at the object itself and the values. That is always a slight pain to work with. And I completely admit that I do not know all the shortcuts to every tool by heart or think I need to (if there even are shortcuts for everything).

If we don’t bring back the T-Panel we could still offer a secondary, customizable toolshelf:

4 Likes

No, at least some of the things that used to be in the T panel should actually be converted into tools and be in the tool palette/bar. Some that used to be buttons in the T panel should be menu options per each of those previous buttons, categorized appropriately. etc.

The properties panel should only really be for properties, under the current paradigm it would still result in a lot of add-on tabs though.

1 Like

Another idea:

This uses a few concepts from previous proposals. Here there are two drag zones. One is at the end of the icons, and one is at the end of the panel. The icon drag zone expands to show labels. The labels would also be displayed with tooltips when it’s not expanded of course.


I didn’t bother changing the icons, I think I have better things to do : P

If there are too many tabs the list would scroll, just like in the properties editor. And the text should probably be smaller too, so if wouldn’t have to be as wide.

Pros

  • It keeps the tab concept for interaction
  • Uses the same system as the properties editor tabs
  • Quick interaction with buttons already exposed

Cons

  • Somewhat confusing interaction with two drag points
  • Addon-created tabs need icons (like other icon proposals)
  • Labels would probably be hidden by default

A note about the last con
We already use only icons for the tabs in the properties editor, so clearly this concept works. I would argue that withe the proper icons the tabs would be even more clear and quicker to read than with text.

7 Likes

I experimented a bit over the weekend to see how feasible it’d be to let users ‘dock’ panels in the header via a set of configurable popover buttons. It didn’t take much to get a bare-bones system together:

image

It doesn’t solve the issue of sidebar crowding, but a more polished version might alleviate some of the pressure.

1 Like

A custom pop-over instead of yet another tab in the properties editor is certainly an alternative that add-on developers can use, but it is an option for them already and it has as much of a potential to become overcrowded and potentially even worse.

There’s a huge difference between a bar and a popover. Popover is something that stays visible only as long as the mouse cursor is over, and disappears as you click in the viewport. That’s completely different to a sidebar which stays available all the time. Most of the addons are in the sidebar because you need it constantly available as you work. Like a tree generator for example, you don’t want your tree generator panel to disappear every time you click inside a viewport to turn it around and look at the tree from a different side before continuing to tweak the settings. Or even when you just accidentally move the mouse cursor away from the popover.

Futhermore, popovers will end up covering important parts of your viewport while sidebar is always on the side, leaving your viewport clear.

Anyone who is suggesting replacement of sidebar with the popovers really has no clue what’s going on.

5 Likes

This would fail too. You’ve intentionally resized the outliner above the properties panel because you yourself have realized the issue. If you had a cluster of icons for the viewport sidebar right next to the cluster of icons of the properties editor, it would because quite messy and confusing very fast.

1 Like

It’s easy to solve, go back the sidebar to the left.