CHANGELOG: February 25 / Hierarchical Lists (beta), some improvements

It seems like hierarchical lists offer the same as smart folders, but without taking up space in the sidebar, right?
I like them, and will probably substitute them into places where I currently use smart folders.

This is an exciting update! It’s a step in the right direction for task/bug management and I’m sure I’ll be able to find other great use cases!

1 Like

Love the list feature.

Few suggestions.

  1. Only show the No Product when there are orphaned entities. Not sure if that’s how it should be, but I’m seeing and empty set at all times
  2. Would love to be able to add custom color at all levels based on more sophisticated rules. Seems like I can only match on name and creation date

Thanks for all the great work

1 Like

I think the idea of it always being there is so that you have the option to create orphan entities, using the plus sign on the right. Otherwise, you can only create them with parents.
Having said that, I think the board view solves this by having multiple ‘+ New type_name’ rows underneath instead, so I would have thought that the List view could do the same thing.

I like the idea, but think that your simple test data doesn’t highlight some significant limitations that would likely confuse users once they try to use it in practice with their more complicated models.

Undocumented Limitation:

There is a confusing and undocumented limitation around what Smart Folders and Hierarchical Lists support. They seem to only support top-down traversal, where the nested types that can be displayed must have a many-to-one relationship

You may look at your example and say, why would this matter? Let’s say that you want to have a nested view like this, but instead of following the happy case in the example, you want this hierarchy:

Project → Issue Type → Issue

If you setup your Issue Types to be a Type, then there is a many to many relationship between Project and Issue Type. This is not supported, isn’t documented, isn’t communicated in context, and I think should be supported. The only work-around would be to create a unique Issue Type for each Project and actual Issue Type. There might be more workarounds with absolute freedom and toy data, but you don’t have as much freedom with the Integration (like the JIRA one).

This is related to the issues I’ve run into with the JIRA integration and Smart Folders/Context Views.

My Suggestion

  1. Document the Limitation and plans (if any) to remove that limitation (for this feature and smart folders hierarchy)
  2. Provide contextual feedback where limitations exist instead of just hiding fields
  3. (hopefully) Remove the limitation
2 Likes

I think you’re right @rothnic that it’s not immediately communicated that hierarchical lists only really work for traditional one-to-many relations (or many-to-one depending on which way you look!) and this has to be true all the way down the chain, so to speak.
Personally, I intuited that from the way the feature was trailed by Michael and the team, so I’m not disappointed/confused.

Interestingly, I had kind of hoped that there might be recursive possibilities (see Representing recursive relations) and that would actually have been more useful to me than supporting many-to-many relations, but it is what it is.

In terms of removing the limitation, I presume that you mean that you would like (for many-to-many relations) that ‘children’ are shown in the hierarchical list under all of their ‘parents’?

p.s. Just out of interest, I wondered for your example with Project → Issue type → Issue, why Issue Type is a type, rather than say a single-select field (or even multi-select) for Issues? I may be wrong in inferring what you are using these terms for though.

It’s great that you can choose which fields are shown, but it would be nice if the values were ‘padded’ so that all the fields aligned vertically for all entities of the same type (kind of like columns in table view).
At the moment, if I make several fields visible, the position of the left most field will depend upon the total width of all the values of the fields to the right, so it makes it a bit harder to scan down the list and compare entities.
Just a suggestion :slight_smile:

2 Likes

I caught onto it, but really only because I was tuned into other, different limitations on the Board view. I’m currently trying to get something working for a broader set of our organization to leverage Fibery, where many users don’t have data modeling experience to think about. While I quickly caught onto it being a limitation, I did try a number of different work arounds with auto linking and various things. Ultimately, there doesn’t appear to be a reasonable work around, so I wasted my time looking into it.

Yeah, think about Dynalist, Workflowy, Roam, etc. The power for them, and really Fibery/Notion/Coda as well, is to have the ability to show something in multiple contexts/views. I feel like in practice if I’m having to constantly fuss with data models to make sure they support a certain view I care about, it just isn’t going to be super useful in practice if I can’t trust it is going to work for a given use case I come up with.

However, in this case the “Issue Type” isn’t even really like a child to parent relationship. It is just a common set of types that all of the parents leverage. This is why I think the toy data example is probably not helping here.

I agree it is reasonable to argue to keep it simple, but it is common with tools like Airtable and Notion to start with a single select field and later convert to a Type/Table down the road. That would actually limit you on the views you can utilize in Notion, which is, along with JIRA integration, pretty much why I am here.

The argument for using a type instead of single select is just it is often helpful with teams so that you can include a description so that people know what you mean by Priority or Status. For example, what deserves to be a High vs Highest priority or when do you use a Status of Open vs To Do. You could add a rich text field where you discuss this further.

The real reason I bring it up is it is exactly the issue that I was currently fighting with, when trying to get some smart folders setup for JIRA projects. The JIRA integration seemed to require me to import it as a type, but found it is kind of broken.

I’m sorry if ‘I’m teaching grandma to suck eggs’ but did you know that you can add as many fields as you like to single-select/multi-select fields? (they are basically just types, but without the same visibility at the app level).
So you can actually have Text/Rich Text fields associated with a single-/multi-select, and people can view all the details with Alt-click like normal entities.
You can even choose to have simple Text fields visible when you’re using the single-/multi-select as a column heading (but not Rich Text fields :frowning: ).

1 Like

FWIW, yeah, it would be nice if the Fibery fields weren’t set in stone, so you could change them (single-select to standard type, one-to-many to many-to-many, number to text etc.) but I’m sure the Fibery guys have this in the backlog :slight_smile:

1 Like

Can we have the option to show buttons in the hierarchical list entries, please :pray:

2 Likes

This already works in Hierarchical List, check this gif

2021-02-27 11.39.25

Indeed

Indeed this is not supported and lists work only with true types. The reason is quite technical, Project Type does not have relations to Issue Type single select and system has no chance to display it. What you want is a mix of Hierarchy and Groups, but that is hard to implement in our paradigm. I’m not sure how to solve this problem so far.

1 Like

It will be done.

2 Likes

[UPDATE: Thanks to @anayericov for pointing me to what I was missing - didn’t realise that I had to enable recursion by selecting the ‘recursion’ symbol when configuring the list. It’s not a bug, it’s an undocumented feature :wink: ]

OK, then I must be experiencing a bug.

The hierarchical list is not showing the items as sub-entities… :frowning:

I don’t think @rothnic was meaning that Issue Type was a single select.
He does in fact say,

so I think his request is that hierarchical lists support many-to-many relations (as well as one-to-many).

It was just me that introduced single-selects into the discussion, confusing things, sorry…

Did you click the icon that enabled this mode? 2021-02-27 15.43.53

Yes, thanks.
I updated my post after @anayericov gave me the clue…

My request is to support many to many relationships. In this example I’m only referencing types imported via the JIRA integration. There are no single selects utilized for the JIRA integration iirc. I used the auto-linking to make sure there is an association between the Issue Type and Projects.

If there is a work-around of some kind, I’d be interested… I just can’t find one.

That is correct, but the suggestion was helpful. I haven’t looked too closely at single selects mainly because I’ve stayed away from them in other tools, where they can be more limiting. If there was a way to assign a single select, similar to the auto-linking of types, then it would be an option for me.

The real reasoning on why I used a proper Type for “Issue Type” example is just because that is how it comes in via the JIRA integration.

Hey guys! My team has been moving along with the Hierarchical List View, and one big piece of feedback I have right now is I’d really like to be able to have the Cards/Boards functionality when displaying the entities of being able to determine size of the Entities. In other words, the options of:

Compact
Line
Default
Full

Or something equivalent.

In particularly we are really missing descriptions of fields that are part of “full” cards in board view. I am trying to emulate one of the best views of Target Process when the Parent Entity rolls up values from the children, such as total effort, etc, and this can be toggled open or closed.

I can do this set-up in Fibery with Hierarchical Lists, but we can’t see what those values are without the labels that you get in Full Cards in Boards. We have many formulas at times, so without these labels, you can’t have easy readability as to what number represents what value.

Thanks!

2 Likes