Today we’re sharing a prototype of how Collections 2.0 works, which is a major upgrade to the organisation system on Anytype. You can experience it by:
For those who would like to learn more about this big initiative to improve Anytype’s knowledge base system, feel free to check out this post: Collections 2.0 Architecture.
This prototype is not a functional developed app, the goal is to give the community an idea of how the system works. Feedback would be highly appreciated. We want to build things that y’all love to use, and hopefully Collections 2.0 has incorporated a lot of the community feedback over the years.
--
Edit: Adding a short clip of nested collections used as tags that do not display when viewing the object.
I’m in love and in awe. It’s incredible! Only critique I have is that the arrow that opens a collection disappears too quickly. I have to move my cursor at a snail’s pace to be able to place it perfectly above the arrow if I want to open a collection. (I realize there’s also the option to right click and open the collection that way but why force myself to resort to a two step process when a one step process would do the trick?)
UI looks great. One point of clarification. Is there a functionality difference between the online shop/products collections and the books/dune collections? I only ask because in the UI they’re displayed differently. Couldn’t tell from the video if there was a specific reason for that.
Products collection is nested within Online Shop, whereas Dune is not nested within Books.
edit: it seems the only difference would be that if you open online shop the option to open a nested collection within it would be automatically available under the online shop title
Great job on the communication: informational message + discussion, and now a video and even a mockup—that’s fantastic!
And the project looks promising, with quite a few nice little ideas; I can’t wait to actually try it out.
A few questions:
Will the option to add properties as blocks on the page still be available?
-- edit : already confirmed by kaye, thanks
What layout options are planned for properties?
Hide the property name (on/off across different display versions), display them in “table” view (header row with values below), or display two per line, etc. (which can currently be done indirectly using property blocks on the page)
Clicking on a collection tag displays the related properties: is it possible to view all properties at once (from all related collections)?
When creating an object, what happens if you don’t click “decide later”? Does it end up in “Base” anyway?
What about select or multi-select properties? Does clicking on a tag open a (smart) collection displaying all objects with that tag?
If so, I’m looking forward to being able to add a property as a widget ;-).
Regarding Smart Collections, I admit I’m having trouble grasping the differences and use cases. I think in my case, the English doesn’t help—sorry if it was clear in the video!
The traditional query allows you to
view objects based on a property
it correctly retrieves objects created after the query was created if they match this filter
And creating an object within the query applies this rule to the newly created object
(and no links/backlinks are created)
So, what are the differences compared to Auto Collect?
As for Collect Once, it’s similar to a collection (you manually add the objects you want, and the list won’t change without manual intervention), correct?
There are a lot of questions about collection management (management panel? Merging, duplicating, moving a collection to make it a child of another or, conversely, making it independent) and the scope of properties, but this isn’t visible in the mockup—it must still be under development, so I’ll wait.
Hopefully, this makes it clearer—@Shampra. At present, we haven’t decided which path is the right one to take, is it one or all of them? Feedback here is especially welcome, naming is not set whatsoever. To explain the differences:
Traditional Query: all objects are constantly aggregated based on a ‘rule’ to form the view. Only objects that match the ‘rule’ are in the collection, which applies to past and future objects. No manual curation. This is the same as queries today.
Collect Once: this is a collection like normal, objects that form the view have been decided by the user manually. The collect once function allows you to query the space for objects that match a ‘rule’, and then add them to the collection. If a new object is created that matches the 'rule’, this will not be automatically added to the collection because the collect once function is a one-off event trigger. You can trigger it again the future manually.
Auto Collect: this is a mixture between query and collect once. You can manually add objects into a collection and you can create a ‘rule’ to add objects into the collection, which would continue add/remove objects automatically based on the rule (just like a query). Therefore, you can have manually-added and query-added objects in a collection.
Our challenge is the mental model confusion. Traditional Query is clear, all objects are automatically aggregated based on a rule. Collect Once is clear, all objects are manually added by you. Auto Collect is fuzzy, some objects are added by you while others are added by the system. We are questioning if this is a good idea at all.
Nested Collections
A deeper explainer is here in comment #42—@Regis. In short, Online Shop is the parent collection, and Products is the child collection—together they are what we’re calling a ‘nested collection’. The properties in a parent collection are extended into a child collection. The purpose of this is to give more organisational depth, instead of all collections existing on the same plane. This is still an object-based system, however there are similarities to folders that can be simulated with this. You can imagine:
Clients as the parent, with Company A, Company B, and Company C as the child collections.
‘Priority’ property in the Clients is used across all nested collections, but each Company can have their own unique properties that the other nested collections don’t share.
This system can be used for tasks, projects, experiments, wikis, etc.
Nesting depth limit is not yet set as there are edge case complexities—@pomp. For example, can you branch nested collections? Can an object be in two different branches? If so, how to represent it in the UI? Additionally, deep nesting depth and long collection names create responsive design issues. If we foresee that many nested depths is a highly requested, then we can put more efforts into this.
More property layout options: this is relatively easy to implement in the future, however we’ll stick with the main two in the beginning. As mentioned elsewhere, you can still add properties as blocks.
Viewing all properties from all collections at once is technically possible, it’s unclear how much this would be beneficial. We want to keep the system simple and haven’t put much energy into this yet.
All objects are automatically in the ‘Base’ (name not confirmed) if there is no user action. You could change the default of ‘create’ to a different collection, but we feel like the Base would function much better than the current default of ‘Page’ type.
Clicking a ‘tag’ to open up a smart collection is a valuable idea, however it adds another parallel dimension to the organisation system. Multiple collections on an object performs a similar function to this. We will revisit this deeply after the first implementation of Collections 2.0 to get more community feedback to understand how helpful this feature would be.
Collection management is indeed another big part of the new update. We did not want to overwhelm with the first prototype, but we can share more in the future.
how deep can nested collections go? would be great if its infinite, and not a limit like “1 level” or so
regarding the traditional query: to link multiple types would be great too! right now I do my queries by “property: object type” (since every object has an object type) and then a filter “object types=my desired types that I want to show” (but I assume this is slower, since it first reads and pulls ALL objects, hence I am querying for all objects with the property ‘object type’)
i love the base collection!! I solved this by creating a type called “ANYTYPE NEW” xD which would be the default type for new objects. but your solution with base collections is nicer! BUT maybe dont put it inside “collections” it would basically be “Object Type = empty”, right? So either its somewhere close to the types-overview, or this “base” collection could be named “Unset Types” or something more clear
That definitely confirms how it works—thanks @kaye !
But does that mean " Collect Once" is just a collection? What’s the difference? Is it just the absence of a link (at least as the object’s “type”)?
Put another way, what is shown in the demo’s “Collection v2.0” is a “Collect once”? Or another things?
Oh, what a letdown for me—I was really hoping and thinking that Collection 2.0 would address (or incorporate) requests for tags as objects, etc.
Apologies, I might’ve not been clear. There are many aspects of Collections 2.0 that will take multiple releases to turn into a reality. Tags as objects is certainly high on consideration (can’t say 100%, but it makes a lot of sense to do it), but it makes more sense to deploy it after the first round of implementation because we need to learn from usage first. That’s not to say we’re not going to do it, it’s just that there are many moving parts that need to settle down first.
‘Collect Once’ is really just a function inside a collection, it has a one-time effect. ‘Auto-collect’ is also just a function inside a collection, however it has continual effects. This is why we thought to call all of these ‘smart collections’ because they are functionally the same as a collection, but with augmented powers.
To be clear, we are not sure if ‘collect once’ or ‘auto collect’ is a desirable solution at all. So feedback is welcome.
We’re very happy to hear any feedback on this. We don’t know if inbox, unsorted, base, etc. are the best names. Also a good debate on where it should be placed in the sidebar. It is a ‘special’ collection, after all.
We’re still exploring this, however it may not change much from the current implementation.
This is a Figma prototype issue, it’s not the final implementation. Don’t worry, we won’t force you to chase the arrow.
imo, the section “Objects” in the sidebar should be called “Types” since what you’re seeing there are actually types. Objects are things inside a type. In my understanding
And then, when this section is called “Types” the currently named “Base” view would be pinned at the top of that – but maybe a name like “Uncategorized” or something like that might be more intuitive than “Base”
Thanks for the update, prototype and video. Looks great!
few thoughts:
love the base collection. with more inbuilt stuff we have less manual stuff to do. less shitty workarounds
how do collection and object types differ? are they all collections? task, projects, games, science fiction etc. does this mean I can create a new science fiction object from the ‘create‘ button? some collections will function as a list for itself. collection books filled with books. other collections will be used to have a big variety of different objects types (dune collection).
are ‘media type‘ objects in the dune page collections? I see books, games, Tv Series.
are tags and collections the same? I see science fiction. is that the same as the science fiction collection? if its different. when would I use tags and when would I use collections. both functions as the same thing right? maybe just the hierarchy is different. collections are more top level. tags as metadata of an object. but then it wouldn’t make sense to have a science fiction collection and a science fiction tag.
i’m trying to think how the p.a.r.a. method would fit into this. for example. i think all of these would be collections. projects, areas, resources, archives, nested into para. project 1, cooking, and books would collections too as it can contain multiple objects right? do you set the nested collections manually? or can it be dynamic as well. for example I create a new project (project 3) can it be automatically nested in the projects collection?
I think that with this system it would just make 100% sense to merge collection and tag and having quick categorization with syntax #collection/subcollection.
I just finished a book, i open anytype, i make an object with the book name and then i write #archive/books and that’s it, sorted and ready to have the other properties filled in. Unless you want to go for the crazy path of #property:“content of the property” , so having the syntax used for any property
Said that, I was having doubts about the new smart functions but i understand:
collect once is for people who are not able to just query something and then hightlight and right click + add to collection
auto collect in a first moment to me looked like just making a set but calling it collection, but it actually opens to a possibility of having different sets into a single collection, because i could auto collect stuff ‘‘not compatible’’ with other rules i have in the same collection
Anyway, the design looks clean and understandable and i hope that having the properties to tags/collection and not to types will finally undo the implication of the ‘‘local property’’ and ‘‘different to type template’’. It really made no sense to have one type per object and properties related to the type. Applying templates to already made object could have been elegantly solved with Properties list layout by me and @sturdily
Nooo, there is not “mental conflict”! – I believe I would quasi always use “Auto Collect” (and nothing else anymore)!
It’s the function that I was hoping for since long.
For me it feels absolutely natural.
A normal Query, with its rules, finds nearly all needed Objects. But some Objects are special, it wouldn’t make sense to tag them in such a way that the Query would find them, nevertheless there is sometimes need to have these Objects in the same View as the “normal” Objects that the filter rules finds.
A normal Collection on the other hand, is not a real solution for the problem above.
We can put things in it manually, yes. But a normal Collection can’t find Objects that are outside. That leads to the problem that we need to add our Objects either to many Collections (a lot work and cumbersome), or we do something like I do: I put my new stuff in a Collection without thinking much about it, but whenever I look for something, I use a Query.
– That somehow works, but it leads to an unpleasant phenomena:
I have for each Collection also an identically named Query.
For example:
I have a Collection “Woodworking”. Everything that has directly to do with woodworking comes in this Collection.
But now I see a video on YouTube about the flora and fauna of the Maldives. It has clearly nothing to do with “woodworking”, therefore it simply doesn’t belong to that Collection. It would better belong into a Collection “Holidays”. But there is one short scene in that Video that shows an ingenious wooden construction, that’s extremely inspiring. My normal attempt is, to give the video the Tag “Woodworking”, so that I can find it in the Query “Woodworking” if I look for some inspirations.
– As already mentioned, it leads to this situation:
There is a Collection “Woodworking”.
There is also a Query “Woodworking”.
And Objects can have the Tag “Woodworking”, so that the Query’s filter rule can grab them.
– As we see, there is now an unpleasant redundancy in this attempt. But (for me) it was the best and most practical attempt I could find with the currently existing methods.
Not nice, but the best I could do.
There was always the wish to have a combination from Collection and Query:
A structure that allows me to find Objects, no matter where they are (like a normal Query) but with the additional feature to manually add Objects that the filter rule normally wouldn’t find.
The “Auto Collect” seems to be EXACTLY what I was hoping for all the time!
– Please don’t tell me about “mental model confusion” and that this attempt may seem “fuzzy”!
No, it’s not fuzzy at all! It’s the opposite: It’s exactly what was missed all the time!
Normal Collections are much too limited. Organizing data only with them causes much too much work.
Queries, on the other hand, are much more flexible then Collections. But the reality, with its mass of different data, is too complex to fit in some filter rules.
Yes, yes, yes, with Tags we can use Queries for everything; there would normally be no need for Collections at all. But that’s not the reality. Because (and this is only one example) if we don’t use Collections at all and we have forgotten to give an Object a relevant Tag, It becomes hard to find it at all. Such Objects are somewhere in the giant blob of other data, there’s no place to look for them (if we don’t use Collections).
I practice, we end up with a system that uses both: Collections and Queries. And, in addition, we use Tags to feed the Queries filter rules. That works. But now we have redundancy. Not in the data itself, but in the management of the data.
And THIS it what always feels (your words) “fuzzy” and what causes a “mental conflict”!
The “Auto Collect” function wouldn’t cause a “mental conflict”.
No, it would clearly do the opposite: it would finally remove the fuzzy mental conflict and prevent it!
I would opt for number three: the all in one solution. In obsidian it is like that and makes life much easier. Also because this is the option most flexible: if you change your mind along the way you can just do it.
That would be the Fusion of queries and collections right? Perfect if you can decide if links are shown or not.
Finally I would call it
The Universal Library - the Swiss Knife for object management in Anytype.
That’s what it is, isn’t it? It would be logical too because all types are certain types of objects and if you don’t assign a type, any object is just an object.
They don’t. In this new system, objects can have multiple types—which effectively means objects belong in multiple collections. When you create an object, it can be directly into a collection or it can be put into multiple collections. You can imagine it similarly to applying a tag to an object, except those tags have properties attached to them.
Yes.
They can both be used to accomplish the same thing, but in different ways. You can choose which method you prefer. Collections have more organisational power (nesting, properties, etc.) while tags would primarily be used collect objects into queries.
Yes, you must consciously decide to create a nested collection. You decide what is the parent, which properties would you like to pull from it, and what additional properties (if any) you’d like to add.
We definitely want to learn from community usage. We can foresee some users still having a lot of value from tags, while others may skip them entirely and just use collections.
Our goal is to have templates that can be shared across multiple collections. That way, if you create an object with a template, it will also be added to the collections connected to that template.
I’m glad you like Auto Collect and I resonate with your example. I have a similar experience. Auto Collect is actually what I’ve always envisioned for Smart Collections, as I personally also don’t like this hard barrier between the current queries and collections. However, on the technical database side, Auto Collect is quite an unorthodox setup. If there’s a lot of positive community sentiment on this feature, then we’ll definitely pursue this style of implementation.
This is one of the key values I see in Auto Collect, it lowers the ‘stakes’ of setting up your Anytype system. You can add or remove the ‘smart’ functionality to existing collections, without the need to re-setup things because of a mental model shift. If users like Auto Collect (and the ability to not create links/graph), then it effectively is a merged feature of queries, collect once, and auto-collect — which is smart collections.
It’s accurate but semantically a little circular. Objects refer to the individual ‘object’, but if we use it to refer to this special collection, then it can be unclear. ‘Uncategorised’ is the most accurate, but not particularly nice sounding.
So, a collection is a collection.
Auto-collect, Collect Once and Query are just methods of enrichment for collections?
Indirect question : For queries that are just queries (without adding a collection to the items they contain), like in my use cases, is that possible?
And is it desirable… I would have said no (no use case, but I haven’t really thought about it yet), but a potential future user I sent the video to says yes, so I guess I need to think it over .
Personally, my tags aren’t meant to be used as a collection (such as a visible display, linked properties, etc.)
But, pehaps… Collection tag are in a “Collections” properties, and when we create another tag properties, it’s work the same way (but it isn’t used in the same way in Anytype (which is fine by me—my tags aren’t exactly collections and aren’t meant to be that visible, etc.).
Does that make sense?
It would be incredibly smooth if we could just type #collection-1 #collection-2 to instantly assign an object to multiple collections. Even better, we should be able to create new collections on the fly by simply typing #new-collection-name. We could then define its properties and tweak its structure later as it evolves organically.
However, I do think we need to carefully consider the flip side of merging Tags and Collections. Many users rely heavily on tagging and have hundreds of tags. If every single tag automatically generates a full-blown Collection, the Collections menu could quickly become a massive, cluttered mess. There might need to be a way to differentiate between a “structural collection tag” and a “simple keyword tag.”
2. The “Auto Collect” Mental Model
I strongly echo this sentiment! I believe Auto Collect is the only type of Collection we actually need. The other two concepts (Traditional Query and Collect Once) shouldn’t be separate collection types; they should just be optional settings or toggles inside a unified Auto Collect system.
This brings up a question for the community and the team: If Auto Collect allows us to manually ADD objects that don’t fit the query rules (exceptions), should it also allow us to manually EXCLUDE specific objects that WERE caught by the query rule?
3. Strengthening Query Logic within Auto Collect
If Auto Collect becomes the standard, I highly recommend upgrading its underlying query capabilities to support advanced Boolean logic (OR / AND).
For example: I want to create a “Weekend Activities” collection. To do this, I need to pull in:
(“Book” AND Status = “Unread”) OR
(“Movie” AND Status = “Unwatched”) OR
(“Task” AND Status = “Uncompleted”)
Currently, this kind of cross-type, multi-conditional filtering isn’t possible with the existing Query system, but it would make Smart Collections infinitely more powerful.
right now I do my queries by “property: object type” (since every object has an object type) and then a filter “object types=my desired types that I want to show” (but I assume this is slower, since it first reads and pulls ALL objects, hence I am querying for all objects with the property ‘object type’)
.