"Parent" Collection Relation

[ferdzso]

WHAT DO YOU RECOMMEND?

Have a relation visible on Objects, similar to Links and Backlinks, that displays the Collection they belong to. This would enhance usability, as currently, there is no straightforward way to determine if an object is part of a collection, and Backlinks can be cluttered with other items.

Optionally, make this relation editable, allowing for easy addition of an Object to a Collection with a single click, rather than navigating through sub-menus.

HOW COULD IT BE DONE?

Introduce a new relation, similar to Links and Backlinks, that displays the “parent” collection(s) an object belongs to. Additionally, the interface for adding new items could provide a convenient way to add the object to any existing collection, although this may become less relevant with upcoming releases that aim to simplify adding objects to collections.

REAL WORLD USE CASES

My current workaround is to have a type called Project, and each of the items in this Project acts as a Collection. Then, on any object I create (Tasks, Notes, etc.), I have a relation called Linked Projects that I fill diligently.

ADDITIONAL CONTEXT

In general, I would like some improved usability in the collections. This would allow me to actually use them over manually setting Relations and viewing them via Sets.

---

Edit: Following the discussion in the comments, I have decided to descope and rephrase my original request in light of the upcoming features and valuable feedback received. I have retained the original text to provide context for the initial discussion.

Original request

WHAT DO YOU RECOMMEND?

Add a relation between a Collection (parent) and the objects (children) within it.

HOW COULD IT BE DONE?

Right now, custom relations can be set up between objects. For example, the relation “Linked Project” can relate an object to a selected project. I suggest creating a similar relation (e.g., “Parent Collection”) that shows the collection(s) an object belongs to. This would allow the user to:

• Favorite the relation for easier visibility (like all other relations in an object).
• Change its value, essentially moving the object from one collection to another quickly.
• The current method of adding objects to Collections via “… / Add link to object” is a bit too clunky compared to this

So, when the Collection is selected in the below screenshot, the item is automatically added to the collection itself.

REAL WORLD USE CASES

My current workaround is to have a type called Project, and each of the items in this Project acts as a Collection. Then, on any object I create (Tasks, Notes, etc.), I have a relation called Linked Projects that I fill diligently.

ADDITIONAL CONTEXT

In general, I would like some improved usability in the collections. This would allow me to actually use them over manually setting Relations and viewing them via Sets.

Edit: I will add this from the discussion below as well, as I feel it helped refine the above request.

To clarify what I am asking for:

• Have a relation on Objects similar to Links and Backlinks that displays what Collection they belong to (similar to how Backlinks and Links relations work)
  • This would add significant usability, as there is currently no easy way to tell if an object is in a collection (Backlinks can be “spammed” with other items)
  • This would also offer something unique in favor of Collections vs. Sets + Relations
• Make the two-way relation editable, allowing for easy addition of an Object to a Collection (one click vs. navigating through sub-menus)
  • This would make the experience much nicer and easier to use
• Make the connection between Objects and Collections a Relation rather than a Link
  • An Object in a Collection feels like a child relation, not just a link
  • I realize this may degrade the experience for some existing users, so I understand if this is not possible or desired to be implemented

[sturdily]

@ferdzso

My current workaround is to have a type called Project, and each of the items in this Project acts as a Collection. Then, on any object I create (Tasks, Notes, etc.), I have a relation called Linked Projects that I fill diligently.

If I am understanding the issue correctly…

If you use a Collection or a Set, which have views with filters on them, when you create the objects on those views, they will set the filters properties automatically.

So you could have a collection which has a filter for a project, and create objects through there, and the project relation will be set. (could have duplicated views for notes/tasks/etc, each one with its predefined template).

[ferdzso]

Yes, but you must create it through that specific view for it to be applied. This is problematic for Sets, as you need to create many per project. It is easier with Collections, but you still have to navigate to the specific Collection to create the Object there.

My main issue is that you cannot simply create an object (which I generally do to capture an idea quickly) and then (when I have time to organize it) easily add it to a Collection. You have to click three times more than for a favorited Relation, and you cannot easily see which Collection an object belongs to.

So for my use case, the issue is that I need a specific custom type with its own sets created, while there is a perfectly good built-in type that just needs a slight extension to be a bit more useful.

[MikeyP]

You might find sets are better than collections for this. Then you could just set up a relation called ‘project’. Then create a set that collects all objects marked as that set. So if you have a set called Project A, everything you’ve marked as Project A would appear in that set. And if you changed it to Project B, it would show up in your set that has everything marked as Project B

(Btw, in case you didn’t know - you can create a set based on a relation, they don’t all have to be the same object type)

[ferdzso]

You are correct; I find this approach better than collections, as I use it exactly how you described.

The main reason I raised the request is that this approach is better than what collections offer, essentially rendering collections useless. In this approach, a Project type is just a pseudo-Collection that exists because the collection experience is not pleasant.

In my opinion, an object inside a collection is a child of the collection, so the relation should be a Relation, not a Link. As a relation, it should be more clearly visible on the child object for a better experience (easier to change and view).

My complaint is likely more deep-rooted than it appears, but I believe a Parent relation is a simple enough solution to bring up some discussion and consideration, even if nothing comes of it.

[sturdily]

@ferdzso

The main reason I raised the request is that this approach is better than what collections offer, essentially rendering collections useless.

In my opinion, and it’s just that, an opinion, you are confusing collections with Sets. I think you find Sets what you actually wants, because you are looking for a dynamic/ real time updated query/search of everything with “ProjectA” or “ProjectB”.

Collections aren’t “queries or searches” but manual collections of items. It is supposed to be used for items you want to group not really based on relations or queries. The way I think of it, is the way of searches (Sets) and folders (Collections), but with the difference that there is no hierarchy.

In my use case, collections are more similar to Tags than Sets, as instead of creating tags for every little single thing I want to specifically group, I just use a collection. (this helps on keeping a sane tag system)

I don’t think the “Parent” → “Child” association is correct, but agree that a relation “Is In Collection” would be nice, especially in case an object is on multiple collections.

Anyway, just my view… might not be what the Anytype team intended.

[ferdzso]

@sturdily

In my opinion, and it’s just that, an opinion, you are confusing collections with Sets. I think you find Sets what you actually wants, because you are looking for a dynamic/ real time updated query/search of everything with “ProjectA” or “ProjectB”.

I think this helped me clarify what I am not clearly communicating, and to clarify my request, so thank you. I understand the difference; I was just not clear on what I want (how they should be differentiated).

In your example with my use case, the only difference between ProjectA and ProjectB being a Project vs a Collection is how you assign items to it. My main goal is to make Collections more appealing for some use cases vs Sets + Relations, as there is very little difference between the two if you implement Sets + Relations properly.

ProjectA as Type

If ProjectA is just a type (of Project), then to assign a Task (or any object) to it, you go to the object itself and set it up there (Linked Project relation, and set it to ProjectA). After this, you can create a Set to display related items (but you have to do it manually for each Project).

Task — Relation ⟶ ProjectA

ProjectB as Collection

If ProjectB is a collection, the main way to add items to it is to go to the collection itself and add (link) the objects.

ProjectB — Link ⟶ Task

ProjectC as Collection - Proposed Solution

My proposed solution is to have ProjectC as a collection but still behave closer to ProjectA as a type. Have a two-way relation on objects that displays what collection they belong to, so you can add an object from the collection or add the object to the collection from the object.

ProjectC ⟵ Relation ⟶ Task

Request

To clarify what I am asking for:

• Have a two-way relation on Objects that displays what Collection they belong to (similar to how Backlinks and Links relations work)
  • This would add significant usability, as there is currently no easy way to tell if an object is in a collection (Backlinks can be “spammed” with other items)
  • This would also offer something unique in favor of Collections vs Sets + Relations
• Make the two-way relation editable, allowing for easy addition of an Object to a Collection (one click vs navigating through sub-menus)
  • This would make the experience much nicer and easier to use
• Make the connection between Objects and Collections a Relation rather than a Link
  • An Object in a Collection feels like a child relation, not just a link
  • I realize this may degrade the experience for some existing users, so I understand if this is not possible or desired to be implemented

[sturdily]

@ferdzso

My main goal is to make Collections more appealing for some use cases vs Sets + Relations, as there is very little difference between the two if you implement Sets + Relations properly.

Maybe I am having trouble understanding, because I see Collections as very different use case that Sets, it just so happens they have a similar interface.

I do agree that it would be usefull to have the ability to add an existing object to the collection, from the collections page.

@ferdzso

Have a two-way relation on objects that displays what collection they belong to

Similar to how the graph shows it? (Although in the grapth, it only shows one way link of objects/collections).

@ferdzso

Have a two-way relation on Objects that displays what Collection they belong to (similar to how Backlinks and Links relations work)

• This would add significant usability, as there is currently no easy way to tell if an object is in a collection (Backlinks can be “spammed” with other items)
• This would also offer something unique in favor of Collections vs Sets + Relations

Isn’t this Bidirectional links request?

Automatic Bi-directional linking + Rollups

Is your feature request related to a problem? Please describe. In Notion there is a way to make two-way/synced relations. In Anytype there is currently no way to reflect a two-way relation directly in sets expect for having a normal-relation and then looking into the navigation dialog of an object to find out which relation is linking to this object of the same type. But I think this can be a bit clunky if you want to use some sort of two-way relation. Describe the solution you’d like I can t…

@ferdzso

Make the two-way relation editable, allowing for easy addition of an Object to a Collection (one click vs navigating through sub-menus)

• This would make the experience much nicer and easier to use

In the Beta versions, there is a “Add to collection”, that makes it easier to mass add to collection in Sets, for example.

@ferdzso

Make the connection between Objects and Collections a Relation rather than a Link

• An Object in a Collection feels like a child relation, not just a link
• I realize this may degrade the experience for some existing users, so I understand if this is not possible or desired to be implemented

Yeah, I personally would not like this and see it as implementing the exact limitations of filesystem folders if meaning in terms of Parent → Child, meaning an object can only be in one collection.
Other than that, does not bidirectional linking solve the issue?

Disclaimer:

I am sorry if I am misunderstanding it, for clarification, what I think you want to do is have collections “Project ABC” and “Project XYZ”, and as you add object to each of those collections, those objects have a “belong to/part of Project XYZ” relation.

This would make it not necessary to add “belong to/part of ProjectXYZ” manually to each object you add to the collection?

[ferdzso]

@sturdily

Maybe I am having trouble understanding, because I see Collections as very different use case that Sets, it just so happens they have a similar interface.

No, you got it. We are on the same page on how it works now. The main reason I raised the request is that Collections are kind of useless compared to Sets in their current form and need some QoL improvements, in my opinion.

@sturdily

Similar to how the graph shows it? (Although in the grapth, it only shows one way link of objects/collections).

I think so.

@sturdily

Isn’t this Bidirectional links request?

Pretty much, that would solve this request as well. However, the scope of this is a bit smaller, limited to collections, so it is potentially more reasonable to implement.

@sturdily

Yeah, I personally would not like this and see it as implementing the exact limitations of filesystem folders if meaning in terms of Parent → Child, meaning an object can only be in one collection.
Other than that, does not bidirectional linking solve the issue?

It depends on whether one-to-many linking is allowed or not. In most fields in Anytype, there are no such limits, which is why I did not bring that part up. It feels like a given considering the general design.

@sturdily

I am sorry if I am misunderstanding it, for clarification, what I think you want to do is have collections “Project ABC” and “Project XYZ”, and as you add object to each of those collections, those objects have a “belong to/part of Project XYZ” relation.

This would make it not necessary to add “belong to/part of ProjectXYZ” manually to each object you add to the collection?

Exactly as you explain it. Ideally, if I fill out “belong to/part of ProjectXYZ” on the object, it would automatically add the object to the collection (so it works both ways).

I guess it is potentially worth descoping my request to just have a Relation (like Links and Backlinks) that displays the Collection an Object is associated with.

[sturdily]

Thanks for the clarification. I think I am sure I understand now.

First just would like to say, that I really don’t think that collection are useless. Although Sets are what more usually is used, as Queries/Searches are vital to a PKM, Collections provide a manual “grouping”, permanent or temporary, which would be messy to do without them.

Now… as a generic means, maybe have collections have a “Special Feature” that would have some properties that would “apply to all objects on them”?
I guess I am pretty much now saying what you requested, but just as a more “generic” way.
Example:

Collection has “cascading properties/relations” (meaning as soon as some object is in these collections, it automaticly inherits these properties/relations):

Collection XYZ:
Color: Gray,
Due: Yesterday,
Project: XYZ,
Importance: Life or death

Collection ABC:
Project: ABC,
Importance: Nothing really matters

(I guess I am not helping, you are “de-scoping” to make it easier for the feature to be developed and I am “up-scoping” (the reason is that I have fealt this need… to have it kind inherit some properties/relations, but instead of being on creating a new object in a view with filters, be on just being part of a collection)) EDIT: (thinking more about it, maybe this is unneeded, with rollups it could do it, so maybe no need to “up-scope”)

[ferdzso]

Isn’t this how Sets already work to some extent (or am I confusing it with how it works in Notion)? If you have a filter applied and click New, it copies those relations to the newly created item? Indeed, roll-ups and automations could also solve this.

[sturdily]

@ferdzso

If you have a filter applied and click New, it copies those relations to the newly created item?

Yes.
What I was thinking, was not when creating, but when adding an existing object to a collection.

(Like if you could drag and drop an object into a view with filters).

Btw, maybe API/Plugins could also solve this. (a plugin that adds a relation when adding to a collection)

Sorry for not adding anything insightful, I hope the feature either goes in sooner like you requested, or that Bidirectional links+Rollups come soon (which would be really great, but not expecting them this year).

[ferdzso]

@sturdily

Sorry for not adding anything insightful, I hope the feature either goes in sooner like you requested, or that Bidirectional links+Rollups come soon (which would be really great, but not expecting them this year).

It was super helpful to refine it to a core request: a relation displaying the collection an object belongs to, with additional features if possible, such as editing the relation field and displaying a relation between the collection and the object.

Tbh, it won’t impact me much if this is delayed, as I am very happy using Sets as they are. I just wish Collections made more sense for my workflow.

[Filip]

In the next update, we’re changing how objects are added to collections. You will now have a separate menu entry only for collections instead of needing to use Add link to objects. I think this should address some of your concerns here.

[Angelo]

Thanks, @ferdzso and everyone, for the discussion! You’ve touched on a long-time pain point for those of us who’d prefer not to have an entire orphanage of lost objects wandering aimlessly around our graphs

The second workaround described here, and the upcoming “add to collection” function mentioned by @Filip, should partially ease your woes: Creating Child Objects / Pseudo-Hierarchy in Anytype

For the rest, such as Automatic Bi-Directional Linking & Rollups, we’re still playing the waiting game until our devs have more bandwidth.

[ferdzso]

That indeed solves a significant part of my request, thank you! Based on this feature in the next release and the discussion above, my request becomes quite simple:

I would like a Relation, similar to Backlinks and Links, that displays the Collection an object is part of. While it is displayed in Backlinks, it gets lost very easily if there are many items.

@Filip @Angelo Let me know if it helps if I update the original request body with the simplified request, or if you think / know something similar is already in the works, I am happy to close the request not to have duplicates.

[Angelo]

It sounds simple, and it is if the object “belongs” to only a single collection. But things start to get messy and complicated if the object is used repeatedly throughout your Space.

Imo, it should not be applied ubiquitously to every object, but rather added manually (or activated, maybe with a toggle switch) just for the particular Collections and Objects you’d like to behave that way.

[ferdzso]

I have changed my original wording based on the discussion, to clarify my request within the context of what is possible.

@Angelo

It sounds simple, and it is if the object “belongs” to only a single collection. But things start to get messy and complicated if the object is used repeatedly throughout your Space.

Adding this feature might also just be delaying the issue. The main reason I considered it is that when I add an item to a Collection, it appears in the Backlinks. However, the Backlinks become cluttered over time for this purpose too.

@Angelo

Imo, it should not be applied ubiquitously to every object, but rather added manually (or activated, maybe with a toggle switch) just for the particular Collections and Objects you’d like to behave that way.

If the dev team has an open story / epic to revise and change collections, this could be added as a suggestion for consideration. A comprehensive revision of collections might bring more improvements beyond this simple suggestion in different ways.

[AnyReport]

Hi everyone! I see this topic has already been discussed in the thread, and I wanted to share my similar thoughts. I just discovered the new ‘Add to Collection’ option and thought, ‘Cool, now I can organize all my images into different collections.’ After adding some images to various collections, I wanted to filter them to see which ones aren’t part of any collection. However, there doesn’t seem to be any metadata indicating whether a file or object is part of a collection. Personally, I think it’s a no-brainer to add such a filter or relation. While I could achieve something similar by assigning my images to different sets, that would mean losing the convenience of the ‘Add to Collection’ feature. I really hope this feature can be added; otherwise, it will be very difficult to manage collections effectively.