Collections 2.0 Architecture—changing how we use types

[sturdily]

@Edw1n

In Notion, you open a page, write, and that’s it.

That is exactly how it is on Anytype also! You can use it without ever creating a type or property…
… Just open it… click create … write… that it, you don’t even have to save it, its automatic!

@Edw1n

Ultimately, most people don’t want to pursue a technical degree to organize their lives;

Then why does Notion have “Databases” ? Isn’t “Databases” a “technical degree” ?

I find Anytype soo much easier than Notion, specially since the rename of “Sets” and “Relations”.

[ferdzso]

hey @kaye,

First of all, thanks for the discussion around implementing this; I am hoping some of the feedback will be incorporated into the final product.

After three weeks of ruminating on this, I think I finally fully understand the goal, and I do have some more practical questions that I hope may also help with the implementation (if you have not already addressed them).

1. Will there be some sort of master / primary / parent Collection field that is mandatory for new objects? That would inform what properties are assigned initially to an Object (similar to how Types work).
2. If there is no mandatory Collection, I assume the objects will just be uncollected when created?
3. How is a “primary” Collection mentioned above different from the other Collections you add to an Object later in its life?
4. How are properties handled for objects that belong to multiple Collections, especially shared properties (like status that may have different values per Collection)?

I feel most of us come from a similar mindset to what exists in Anytype now and how Notion Databases work, where an object belongs to some base Type / Database / Collection and is then sorted forward from there. Collection 2.0 would likely still be fine for this, but I assume either we would need to limit our usage to a single Collection per object (essentially a Type) or we would need tools / properties to mark what the “primary” Collection is (though that makes naming confusing).

5. Do you have an approach for the above? How would you onboard new and old users to this new way of working that helps them understand and teaches them the discipline needed to maintain it the old way or deviate to the new way?

[kaye]

@sturdily

To be clear:

• Simple tag with no properties → just label, shows all objects with that tag
• Tag with properties → a label, shows all objects with that tag, and adds properties (what is maybe the of collections 2.0 multiple collections?)
• Tag with properties and template → a label, shows all objects with that tag, adds properties, adds content template when added.

Indeed, this is very similar to how we think about it (with some small differences with templates and object creation). When you apply a ‘collection’ to an object (in a very similar UX to how we use tags today), it means that all three levels of organisation inherently can happen at the same time—without the need for user choice. One of the challenges of tags today is that if you want to ‘view all objects with that tag’, then you have to take an additional step of setting up a query.

We definitely take inspiration from Tana (and many other apps, not just Notion) to try and learn from their great approaches. Hopefully our spin on it will work as well as we imagine. I’m personally very excited about Collections 2.0

@Zak-from-Zork

So please, please, please, however you will call those collections, please use the folder icon and keep the magnifying glass icon for immediate orientation.

In short, I (kind of) agree. Currently I’m planning onboarding materials and I’ve thought about explaining Collections as ‘magic folders’ as it’s the closest description I can come up with to orientate a new user who is used to the folder hierarchy system while still noting a fundamental difference with the object model. The issue we have with calling it folders + folder icon is that it will likely create a strong mental model that’s wrong. You can’t create multiple folders and organise objects in a hierarchical way. So we need to balance this. Nonetheless, I appreciate the feedback.

@Edw1n

That initial friction is what kills retention. If they don’t learn from the simplicity of the competition, Anytype will always remain a niche app for enthusiasts, while the rest of the users move on to what actually works instantly.

Thanks for the feedback. We 100% don’t want to be niche app just for enthusiasts, but we do want to create a meaningfully different product. We just need to be better in how we bring people into this different system.

@ferdzso

I do have some more practical questions that I hope may also help with the implementation

1. Our current thinking is to implement a ‘base’ that acts as a temporary container that holds objects that have no assigned collection/type—which can be organised later. This hopefully removes the mental barrier that can exist where a user has to think of the type before they create an object.
2. The ‘base’ is effectively a mandatory collection of unsorted objects. You can skip this entirely by creating objects directly in the collections they belong in.
3. A ‘primary collection’ serves as a neutral grounding for the object. E.g. if you navigate to an object, the first collection and its properties to display will be the primary collection. If you search for an object, it will only show up once even if its in multiple collections, and the primary collection will be the first collection that shows up in the object search.
4. This is why we’re implementing space-level and collection-level properties (naming unconfirmed). If a space-level property is shared across multiple collections on the same object, the value will be the same in all the collections. If it’s a collection-level property, then the value will be whatever is assigned to that property. In your example, it’s a question of how you choose to set up your ‘status’ property in those multiple collections.
5. This is a work in progress (and backwards compatibility in general), but existing users don’t need to use the new mental model if they don’t want to. Your type will automatically be the ‘primary collection’ and you don’t need to assign any additional collections to the object—effectively retaining the current system. The UI would look similar to how it is today, although not exactly the same. One of the big benefits of this new system is if you assign ‘collections’ instead of ‘tags’, then you don’t need to manually create a separate query to view those tags—removing many user steps. Additionally, with the ability to have nested collections (where they have joint sets of properties), you have more organisational power for people who want to draw stronger relationships between tags. In summary, the new system doesn’t prevent the old from existing, however there are notable new capabilities enabled by Collections 2.0.

[Zak-from-Zork]

Hey Kaye,

@kaye

The distinction between a collection and smart collection isn’t much besides the query-ability to auto aggregate objects into the collection.

I am still working through the new objects thread. And one idea is coming up while I’m reading, you’re writing about collections and smart collections.

In Obsidian, they just have bases. So one kind of library serves them all.

And what is the difference between collections and queries anyways?

Except for the backlinks and the linking to collected objects?

So why not merging collections and queries to one standard library?

Wouldn’t it, again, simplify the system for everyone? Just blend the features and there is no need to have an artificial distinction.

Or am I missing something?

[Zak-from-Zork]

@kaye

As for displaying the properties in the object header, this is something we have not fully figured out yet. Should there be tabs that all you to cycle through different collection properties of the same object? Should all properties from all collections be displayed? How about the same global property used on multiple collections that the object belongs to, do they show up repeatedly or only once?

Tabs can get very confusing if you have a lot of them, I would go for a list with titles and subtitles for different headers and maybe even a table of contents if you have a lot of property-headers for one object.

If you make the different headlines toggable. It would help a lot to orientate fast. It could be circular, too, scrolling round to the beginning after the end.

Like this you could even toggle on and off the global properties.

Maybe you could show properties again as a library with raster-view like in collection/queries.

And:

Why don’t you call the different object-headers ‘perspectives’? Cause that is what it would be in real life. If you look at somebody or something, you always have a certain perspective.

And:

Do you really need a primary collection? They are all objects as such anyway. So this could serve as the initial collection for everything.

In Obsidian every Base (their ‘collections’ or rather queries) lists at the beginning all objects and you start by filtering out the ones you don’t want. It could be the same with the initial collection of (all) objects in Anytype. So no dedicated primary collection to decide on.

What do you think?

[jakub]

I’d love to see a simpler and more user-friendly way to add new types in Anytype.
Right now, every time I need to create a new data type, I tend to postpone it because the process feels too complex.

Craft is a great example of how smooth this can be. It’s incredibly fast to create a new collection and define new types. I’m attaching a video to show how easy this flow is in Craft. I’d love for creating new types through the Collection in Anytype to feel just as simple.

[Shampra]

I don’t know Craft well enough.
But based on the part shown in the GIF, it looks very similar:

If you can, focus on the friction points in Anytype—the details that make a difference—and break them down step by step. That could help the team.

In the process shown in this video, several issues have already been noted:

• speed up the addition process (too many open windows), exemple here : Small UX update : Add a relation more quickly
• navigate through the table to fill it out (by the way, I instinctively hit TAB to move to the next field while recording…)
• …

[jakub]

In the provided example, you’re extending an existing Page object.

I’d like to create a new one.

Currently, to achieve this, I need to create a new Object Type and then start adding such columns to the general Query Object View.

This process is not intuitive. It would be easier to have some choice when creating a query or collection, allowing you to decide whether to start with a new Type or an existing one.

This current system is quite confusing for new users.

[Edit]

I believe the New Collection should default to the new type, and then we should have an option to switch to the existing one in the settings.

[kaye]

We have shared a prototype, please see this forum post: Collections 2.0 Prototype

Hopefully this can make the discussions in this thread much more tangible about how the new system feels. I did not cover all topics in the prototype, but it’s should give a high level overview of how it functions.

Really looking forward to everybody’s feedback.

[Malcolm]

I like it!

[callumgare]

This look sick! I really appreciate how much time and attention you put into thinking about how these sorts of mechanics work. I think the idea of an object potentially having multiple “types” matches the real world a lot better. Sorry I don’t have more helpful constructive feedback but just wanted to say keep up the good work!

[Snomstor]

Having only one type for each object is quite straightforward way to think about objects and organize them.
From the very beginning of acquaintance with Anytype this logic seemed very intuitive as it is used in Object-oriented programming.

[ogokcocoball]

I felt the same way, so I shared my thoughts in a more recent post a few days ago.
What are your thoughts on the proposal I made there?

Collections 2.0 Prototype—feedback is welcome

I apologize if a similar proposal has already been made in the past. Since queries act essentially as concepts like Smart Collections or Dynamic Collections, I would like to propose changing the concept of the currently-in-development “Collection 2.0” to an “Object Collection”. Looking at the development intentions, I understand that Collection 2.0 is being built because a single document can simultaneously have multiple types (properties), even if its core essence (the body text) remains the …

[Snomstor]

Well, it seems reasonable to me if I understand correctly your ideas.

[kaye]

If you’d like to have only ‘one type’, then you still can do so in the new system. You can simply assign only one ‘type/collection’ and continue to use properties, queries, and other functions to organise your objects.

[ogokcocoball]

@kaye @Snomstor

I’ve posted this as a follow-up to the feedback thread that I believe is more appropriate for this discussion: Collections 2.0 Prototype—feedback is welcome

[Zak-from-Zork]

@kaye are there any news on how tags will fit into the new Tycota-System?

I. e. can I use tags now, thinking that they will be converted to collections 2.0 automatically?

Or will there be manual effort to convert tagged content into the new collection system?

[kaye]

What is the Tycota system? Maybe I missed something.

Tags as you are using them right now are effectively multi-select properties, they will exist in Collections 2.0 exactly as they are now. Nothing will change there.

If you want objects that have a tag property organised via queries to show up in ‘Collection 2.0-style’, you will indeed need to ‘manually convert’ it. What we will likely recommend as an approach is to test out the new system in a fresh space first (preserving your original one).

[Noe]

Only limitation I’d see is clarity around some primary “collection” that an object belongs to, so as to prevent it from getting cluttered. I may want to use the Tana approach and hashtag type a collection name inline to a new object so that it inherits that collection with no additional clicks or navigation. Let’s use your Dune example:

Dune #book

But then let’s say I want to add it to some additional lists, which can be done with current collections. So I add that same object to “Books to Read this Summer”, and after I’ve read it perhaps “Books I Enjoy”. The power of the new collections feature is that if these tables have their own properties, Dune will inherit all of them.

Potential drawback: wherever Dune is mentioned, or when Dune itself is opened as a page, does it now carry around with it the visual UI burden of:

Dune #book #bookstoreadthissummer #booksienjoy

Likewise in the properties header of the page, can I identify to see some primary type with it, or will all of them be co-equal? Co-equality is wanted in some explicit instances like

John Smith #person #friends

But maybe not in such superficial instances as I described with the Dune book. What is the vision for this?

[p4ssenger]

Hi Anytype team,

I’ve been exploring the new Collections 2.0 design, and I’d like to confirm that my interpretation matches what you’ve built.

From what I see, the old approach was type‑centric: objects were tied to fixed types, and crossing those boundaries (e.g., treating a book and a movie together based on “status”) was difficult. Collections 2.0 seems to flip that to a property‑driven model. Objects are essentially IDs with a set of attributes attached; the storage layer does not enforce any domain hierarchy. Collections are now dynamic queries that group, filter, and sort objects based on shared properties (like “status” or “due date”), regardless of their original type.

This feels like moving away from compile‑time domain modelling towards a more flexible, data‑oriented composition – almost like an ECS (Entity‑Component‑System) approach applied to knowledge management. It allows the same object to appear in multiple collections without forcing it into a single tree branch, and it makes cross‑type queries feel natural.

One nuance I’d like to add: even though the underlying architecture leans towards ECS, the user‑facing mental model still feels backward‑compatible with OOP – you can continue thinking in terms of “types” and “instances” if that’s what you’re used to. Moreover, the new context mechanism appears to add extra flexibility on top of that OOP‑like view, allowing objects to adapt their behaviour or presentation depending on the current context, almost like dynamic roles without the rigidity of inheritance. Is that a fair reading?

Now, a few questions to clarify:

Am I on the right track overall? Are there any hidden constraints – for example, do collections still depend on some underlying schema, or is it purely property‑based at the query level?

Does this architectural change affect how relations and sets are stored internally, or is it mostly a UX/API layer that sits on top of the existing storage?

And I’m particularly curious about the inspiration behind Collections 2.0. Was it influenced by similar products (like Notion, Tana, or others), or did it emerge more from internal refactoring needs and architectural reflection while evolving Anytype’s own codebase? Or perhaps something else entirely? I’d love to hear more about the design journey – it’s fascinating to see such a fundamental shift in a mature project.

Thanks for any insight you can share – I really appreciate the work you’re doing!