Object Hierarchy and Breadcrumbs (forked from Collections 2.0)

[Astro-L]

@Code-Jack

Finally did someone give it a try and brings even worthy thoughts!
Well made, @Astro-L !

Thank you, I’m glad you appreciated my feedback! I feel good about how I articulated my thoughts.

@Code-Jack

But it is shown from the perspective of Object A. That was never the problem, because for breadcrumbs we are interested in the higher level that’s above the actual Object.

True, my model doesn’t provide a means to get a single breadcrumb trail unless the parentage happens to be unilinear or, as @kaye suggested, a manual “priority links” feature is added. I’m not personally interested in breadcrumbs, but I am interested in improvements to the display of hierarchies generally. It seemed to me that the conversation was about more than just a breadcrumbs implementation.

@Code-Jack

I was all the time moaning, because multiple users in this and the other threads repeatedly spoke about a “tree” although they always described something else then a tree.

I appreciate specificity in language as much as anyone, but “tree” can mean other kinds of visualizations than what you’re referring to. You’re familiar with a “family tree”, yes? Where every node by definition has more than one parent? I think you’re doing yourself and this discussion a disservice by spending so many words arguing against people whose usage of the term is more common than yours. You’re not going to be able to stop everyone, especially people who don’t have your background and/or training, from using an also correct but not technically rigorous definition.

Ultimately I don’t care what we call my model or some other thing like it. Call it a “bush” or a “shrub” or a “hedge”, I don’t know. But this gets back to the good-faith thing: Are you really trying to engage with the core idea here - the desire that some of us have for more robust ways to track hierarchy - or are you using technical arguments to throw sand in the gears because you’re actually against the core idea itself in any form? Credit where it’s due, your suggestion in your last post for a 3D Graph view does sound like you’re starting to engage with the core idea, and I appreciate that!

@Code-Jack

-- That’s an disadvantage that the users wouldn’t accept.
Imagine that from Object A would not only two paths lead to Object D, but more. Much more.
The tree would be blown up and full of redundancy. The users would write Feature Requests and ask the devs to do something against that nonsense.

But that’s exactly how the widget view currently works, and who’s complaining and writing feature requests about it? I think you’re projecting your own distaste for this notion onto the whole userbase. Several other people in this thread and that linked FR one have expressed a desire for something like this. I won’t predict how the userbase as a whole would react to it being implemented, but you don’t know that either.

(And for the record, duplication can also happen in Flow view if two objects are both linked and backlinked to each other. The same object will appear on either side. That’s probably a rare occurrence, but I thought it worth mentioning.)

@Code-Jack

It’s sometimes good to throw something new into the crowd. A brainstorming idea that can become discussed later.

Absolutely agreed, and thanks for making that graph image; it was a good springboard.

@Code-Jack

-- Your post has more content worthy to discuss, but I need a break now, maybe I come back to it tomorrow.

Thanks again - I wanted to hold off on my reply until you’d finished your thoughts, but I just couldn’t resist. I’m with @Zak-from-Zork that improvements to hierarchical display “would help me with 99% of my needs.” So I’m keenly interested in any discussion and ideas on the topic. Have a good evening, or whatever time it is for you!