Preview of the interface:

With the Ctrl+H menu we can't have the padding to show hierarchy since it is a menu and I can't draw more than one element in the line (and for the padding I need to draw a few icons).

Note this would be for 2.81, since the UI is frozen and I want to spend time helping get Blender more stable rather than UI design.

In D5118#116399, @Brecht Van Lommel (brecht) wrote:

Note this would be for 2.81, since the UI is frozen and I want to spend time helping get Blender more stable rather than UI design.

+1 . At least we will enter 2.81 with a solution to that. I poke you again once 2.80 is out so we can re-visit this topic.

Hi!

Interestnig solution.

But the problem is that autonumeration is dynamic. That means, it requires more memory to remember which number belongs to which collection depending on current depth state. For example, if user want to send objects to Collection with number 5 via pressing M5, it is hard to say where objects will be sent.

So it will be better if first 20 slots, that available for numerals keypressing, will have static (adress) autonumeration independently of hierarchy depth, but with numeration starting from first level of hierarchy.

Static autonumeration is looking not so fancy as dynamic but is more usable.
Example - when scene's collections are formed, user can call collection as "1_Room", "2_Car", "3_Table" during single scene setup, and this numeration in static representation will be actual independently of depth parameter.

Here is numeration types comparizon
B2 type is the best one, because of this issue
https://developer.blender.org/T61492

Can I guess that all arguments considering dynamic auto numeration and direct adress access was ignored?

I guess I more fundamentally don’t really understand why this outline view must work so differently from the actual Outliner? In some scenes you want to expand some Collections and not others. For the main Outliner, expanding all items together would not be acceptable, so really I don’t think it should be here.

For the numbers, you could (manually) assign those in the actual Outliner too. I don’t really see why this must happen in this panel and not the real Outliner?

This Sidebar panel seems mostly useful for the case when you have unlocked Collection visibility, to set it per viewport, which is currently a missing feature.

When we add that, this mini-Outliner is mostly useful if it works just like the regular Outliner.

Not ignored, it seems to have been discussed at length on T61492. But I would rather leave the discussion on alternatives elsewhere not to detract from the main functionality presented in the patch.

I'm bringing it up to date in case we decide on pursuing it further. For the records what you suggest (B2) is already what we have in Blender, what we have in the patch is (B1) skipping the Scene Collection.

In D5118#125392, @Dalai Felinto (dfelinto) wrote:

Not ignored, it seems to have been discussed at length on T61492. But I would rather leave the discussion on alternatives elsewhere not to detract from the main functionality presented in the patch.

Thank you.

I'm bringing it up to date in case we decide on pursuing it further. For the records what you suggest (B2) is already what we have in Blender, what we have in the patch is (B1) skipping the Scene Collection.

Aw, so, it was.
B1? Manual assigning?
So, does that mean, that we will still need functions for managing QCD that managing Collections?

In D5118#125388, @William Reynish (billreynish) wrote:

I don’t really see why this must happen in this panel and not the real Outliner?

That was the goal of B3 proposal.

https://developer.blender.org/T61492#745582

So now what will happen:

• Manually assigned 20 slot will dissolve in 1000 collection's file just immediately, so we don't know where they are and what belongs to.
• Then multiplying it with dynamic numeration, so we are changing their access number in the same file. We are literally shuffling their numbers, changing depth value.
• Then having 30 such different files "made by someone", and... that's it. We've come to incredible mess.

What's the point of such system?

As a technical director, my job is to deal with mess that users brings to files just daily.
It is ok for me to work with 6000-8000 layers in autocad, including block refrences, that can contain multiple, because I wrote special toolset to handle that much layers, so I know how it feels.

I've seen that all, and can tell about interesting aftermath of such systems you never thought about.
This is a serious matter and you will have to be more strict to create a solution that will not make more problems than it solves.

We observed such issues, like:

• QCD itself
• Manual assigning in A1 way (QCD as bookmark system)
• Hierarchy depth changing behaviour in C1 way (current topic)
• Shorcut inconsistency (https://developer.blender.org/T61492#755751)

Here are two pictures that shows what happening with scene's hierarchical management now:

Those infographs are really clear and well done, thank you. I plan on abandoning this patch anyways since it seems I'm the only pushing for B1.

We still need a way to handle the UI though. Even if we stick to B2 as we currently have.

(out of curiosity, did you make these infographs for this task? or had you them around already?)

In D5118#127314, @Dalai Felinto (dfelinto) wrote:

(out of curiosity, did you make these infographs for this task? or had you them around already?)

(Ok, let us have some offtop.)
I often make infographs and schemes during workflow design, as far as it allows to compress complex ideas and workflow demands to a simple representation.
Basically, if an idea can be represented in that way, that means it is mature enough, so infographs are also a concepts testing tool.
Like in any kind of design, it is hard to make a simple, functionally-concentrated concepts. Apple iMacs are perfectly fits to any kind of interiors, my own peak was F2 tool, that allows to create that in Blender in almost no code.

Specifically, this one I did just yesterday.
But there are concepts that have been growing for decades.
https://developer.blender.org/T66337#729821

In D5118#127313, @Dalai Felinto (dfelinto) wrote:

Those infographs are really clear and well done, thank you. I plan on abandoning this patch anyways since it seems I'm the only pushing for B1.

We still need a way to handle the UI though. Even if we stick to B2 as we currently have.

I was also pushing for A1. But then I made an analysis, and have seen what it will turns to.
That's why A1 is so dangerous - it is looking so handy, profound and flexible at first time, if to imagine it with 20-30 collections, but then you imagining work with thousants of them with 15 levels of enclosure, and it is sobering from the spell.
It will be the same as sorting out a book where pages have their own pages.

Also, the difference between A1 and any other is indeed the same, as between bookmark and a bank cell.

In bank cell system user brings content to the slot, while in bookmark system - slot to content.
So, in first case slot have priority, and, like a bank cell, it will contain the most precious and thoughtful content,
while bookmark usually serves to mark something temporary, that becames constant when it is just forgotten.

I've also tested B2 system during making test project, and I can say that feel doubdts about the usefulness of its capabilities.

I've proposed B3, and I will try to explain why, later.
I need some time to make descriptive comparison.

Here is the result of comparison of B systems:

List of sysytems:

Analysis (fixed 2019-08-25):

I like B2 was designed to work like B3 in complex scenes, I've seen peoples making empty default scene with 20 empty first-level collections to have B3 from the scratch.
Don't know how to relate to this yet. I guess this is done intuitively in order to lower UMC rate.

Here is a bank cell representation for all 3 types.

By the way, I've spotted a mistake I made in page 3 considering B2 numeration.
Now it is fixed, but it shows how confusing can be such structure management (it allows to get lost in 7 digits!).

UMC level control is all about mistakes prevention.
At the end, higher UMC means more overall overload during work, or more checks, or allowing mistakes, and we cannot afford anything from this...

Also, a very HUGE slots management, UMC and workflow compatibility issue.
Basically, what is the problem of this problem:
https://developer.blender.org/T61492#766205