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

[mdubakov]

Hierarchical List View (beta preview)

You can secretly try a new hierarchical list feature. It has some bugs, so it is not official yet.

Step 1: Add ?list into URL
Step 2: Add a new Hierarchical List View in some app

Step 3: Try to create a new list, like this, for example:

Step 4: Give us any feedback, what you like, what you miss.

Improvements

Entity History contains full comments text now, so you can more easily trace entity activity.

Fixed bugs

• Error if update formula field having collection type
• Do not allow to create IF formulas with collection fields in branches
• Create a hook, warn and do not close the Edit Button editing window if there are unsaved changes.
• Endless loader in Smart Folder with empty configuration

[Chr1sG]

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.

[helloitse]

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!

[Aram_Zadikian]

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

[Chr1sG]

@Aram_Zadikian

I’m seeing and empty set at all times

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.

[rothnic]

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

[Chr1sG]

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.

[Chr1sG]

@mdubakov

Give us any feedback, what you like, what you miss.

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

[rothnic]

@Chr1sG

so I’m not disappointed/confused

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.

@Chr1sG

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’

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.

@Chr1sG

why Issue Type is a type, rather than say a single-select field

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.

[Chr1sG]

@rothnic

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.

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 ).

[Chr1sG]

@rothnic

start with a single select field and later convert to a Type/Table down the road

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

[Chr1sG]

@mdubakov

Give us any feedback, what you like, what you miss

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

[mdubakov]

@Chr1sG

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

This already works in Hierarchical List, check this gif

[mdubakov]

Indeed

@rothnic

Project → Issue Type → Issue

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.

[mdubakov]

@Chr1sG

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

It will be done.

[Chr1sG]

[UPDATE: Thanks to @cannibalflea 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 ]

OK, then I must be experiencing a bug.

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

[Chr1sG]

@mdubakov

Project Type does not have relations to Issue Type single select

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

@rothnic

If you setup your Issue Types to be a Type, then there is a many to many relationship between Project and Issue Type

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…

[mdubakov]

Did you click the icon that enabled this mode?

[Chr1sG]

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

[rothnic]

@mdubakov

Project Type does not have relations to Issue Type single select and system has no chance to display it

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.

@Chr1sG

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…

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.