Collections 2.0 Architecture—changing how we use types

News
62

Yes, the experience should be the same as today. The content inside an object won’t change regardless of which collection you open it from, this applies to the block-based properties as well.

In our perspective, the object should only appear once in search. Otherwise it’d be quite polluting to see the same object multiple times but just with different collection labels. It’d show up with the ‘primary collection’, which acts as its default. In prototypes, we’re exploring that users should be able to then ‘switch the header’ so to speak to view different collection properties. Or maybe even view all. Technically, this is the same experience as today? When you open an object from any search, it opens with the same (type) properties and you can’t see local properties in the header.

This is an interesting point I haven’t checked with the team on, I imagine we would be able to set deeplinks based on the collection. By default the link would just be for the primary collection.

Is there any particular concern that you’re worried about? From my perspective, there is no loss of functionality for power users of today, but it is a different UX.

63

This is something I wondered before. I don’t know if I mentioned it before. This came to me when trying to do journal and habit tracking (if the objects inside the collection 2030-01-01 inherited that “journal-date” property with 2030-01-01 value, I could track it by journal day).

A quick way to test the proposal, would be to have collections, where selected properties of the collection was copied to the objects inside of them.

This is a great move in my view, by itself, not only on the “Collections 2.0” goal.

64

First of all, congratulations to entire AnyType team. The way you guys treat and listed to user’s feedback is insane. Never seen anything like this before.

I got worried about this change, but probably because I didn’t understand well how will work.

Types to me are the system core. They are the reason I started using (and loved) AnyType. With AnyType I was able to finally create a system that is rigid just enough to put thing on their places without breaking my creative thinking.

I use it this way:

  • I have Types for real things: people, books, movies, events, pages, organizations, deliverables;
  • Those Types are related to real-life Collections: psychology, finance, customer success, self-improvement.
  • When I create a Type I must link it to one or more Collection: this book is related to customer success, but it also brings psychology concepts.

Having a strict type like Books also helps me to manage my library. I have properties that define the characteristics of this book, like it was purchased in that specific date, have an amount number of pages or was finished by January 25. Using tables as a view, I can also see my Books, regardless their context, as a raw object.

When we are saying that Collections and Types will be “merged” into a single thing, I’m assuming that my workflow will become a mess. I don’t want to see a Book in my graph along side with Psychology, because my Collections help my navigate over the app. Seems to me it will be similar to show “Types” in my graph.

Frame 1
Frame 11920×1152 319 KB

Not sure if I made myself clear and probably this concept was just a misunderstanding from my side, but I would love to hear about you how this would work as only one single thing.

65

Understood and thanks for the feedback. Shampra brought up a similar point discussed above. Today, Queries and Collections are used in a way to bring ‘views’ of objects into focus, but not necessarily relationships that wants to be seen on the graph. Our solution for this would be to put a toggle in place where you can decide to show the links or not.

We could think about another solution where only primary collections are shown on the graph, and any ‘additional’ collections must be manually turned on. Unclear on the impact/necessity/feasibility of such a feature.

Nonetheless, we understand the point. People don’t want their graph polluted by too many links.

Thank you! We’re trying. :slight_smile:

66

Here are some of my thoughts, maybe a bit messy and too compact though.

Types seems to resemble filters or advanced filters for properties/relations, in collection.

  • In collection, Turning a filter on/off with a toggle, without deleting the filter, users can toggle the relevant properties/relation and their contents.
  • For example, when book type is on, display genre, writing style; when movie type is on, show actors, duration, cinemas.
    • Turning properties on/off will benefit the management of increasing number of properties involved if when multi-types are implemented.

Equalising type and collection seems compressing… but yes set/collection is extremely important for users to understand relation because tables, as illustrated by @dzlg in Multi-dimensional Relations , are the most straightforward way to express matrix.

  • We can have type for objects and type for properties/relation as well, hence FR Creation of Relations from scratch .
  • If we show the advantages of relation data model, type is like grouping attributes (hence why property makes senes) for entity (aka object in Anytype). We can call for a specific group of attributes by contexts (for both data input and display respectively).
    • Entity will have its own set/collection for storing all keys/identifiers, which keys are for referencing other sets/collections.
      • For example, A book has author attribute, but when movie type is added, introduce actor attribute as well (which these attributes can be a one-to-many relation).
      • Book has its own set/collection containing author attribute; Movie also has own set containing its attributes; but more importantly,
        ‘All objects’ set will store the indicators which sets and attributes each entity has to refer to.
        ‘Harry Potter’ (an object) can be reused as one of the primary keys to both the book and the movie.
        Book set will store a foreign key in AuthorAttribute to J.K. Rowling in Human set (or All object set with Name and HumanType).
        Individual book of the series - The philosopher’s stone (another object) can take Harry Potter as first identifier to pull AuthorAttribute from Book set but add a Second Title for a second but more definitive identifier.
        • All of these objects are related and can be interactively used across sets/collections.
      • Hence a single Table/Collection has its constrain for explaining relations across collections, and definitely infinite matrices. FR Node editing workflow could be an alternative to help users understand relation and how relation can refer a certain connection point of another object - The nature of table and graph combined - Best fit.
    • Therefore, with relational data model, Context properties should be default because a type is the fundamental context for what is involved and the request for keys. A book is simply the context for the genre.
      • For example, these days we also need to define men and women, so there are rarely cases for things to exist without contexts. Not that we need to specify contexts every time, but we need to allow contexts whenever is needed.
      • Global or generic attributes are essential but users are less likely to make constant changes since it is universal anyway.
  • See some information about relational data model, specifically about entity, attributes and relationship here, and keys here. (Sorry, is me mumbling about relational data again :sweat_smile: but I really highly recommending going into relational data model)

However, type/context can act on/for individual object as well. For canvas, we do have this Multilayer text annotation objects on the forum, which shows a little bit how we can display the relevant information only when context is selected. This FR emphasises on highlight relevant text with background. However, we can have more advance control over all texts as well. For example, with New relation type: Block . we toggle a group of properties/relations on/off and decide only the linked blocks (and included texts/data) should be displayed.

  • This method would work well with publishing and its design as well. Since we can compact and section information for users to display based the focus. e.g. Under a main topic/header and explanations, introduce 4 examples which one example is shown by default, but users can decide to click on other examples to understand more. Like on Anytype.io - “Single objects, infinite possibilities” section, where you can see usage examples of table, kanban and gallery.

I am genuinely glad to see how relationships are back to focus, but perhaps these are not easy to implement and for users to onboard.

And yes, Anytype is the Apple of note-taking industry!! As Steve Jobs said, “Our job is to figure out what they’re going to want before they do.”.. as Anytype shows the beautify of Type and Relation, users will then eventually understand why these are essential for note-taking - the interactive dynamic but reusable components of ideas and lives.

67

Yeah, but that doesn’t change your cousin. Only how you view him. So this is not a different type of object, but a different view on the same object. Even when he’s your vendor, he’s still your cousin.

68

Absolutely not. A Dune type would not be “perfectly reasonable”. It’s a movie that related to a book (and vice versa), a soundtrack that’s related to a movie, etc. Those are different types. Cramming all that into one type is not reasonable at all. However, they could be in multiple collections: a book collection, a movie collection, and, yes, a Dune collection. But only the first two collections are referring to their respective type.

Funny example. I have something very similar in LogSeq and it doesn’t require AI at all. It just parses the block I created and links all the keywords. The name of the person refers to that persons page (which can also have aliases), the word “movie” would link to the movie page. The only real thing I have to do is the “I want to watch it”, which would require me to add TODO to the beginning of the block to make it a task on my todo list. I think I can manage that pretty well without AI.
And actually, I think you can do pretty much the same with Anytype. Put an @ in front of the persons name and it’s linked, right? However, you can’t quickly assign a type on creation this way. You would always get the default type for the space and then need to manually change it to a task for instance. Or you can create a blank task and then you would immediately be taken to the page of the task to fill in the details, which breaks workflow. So it would be better if you could create a link to a new object of an arbitrary type and just needed to input the title, so you could keep writing what you’re writing and fill in any details later. Something like @task[Call Ghostbusters].

(I’m intentionally ignoring “next month” since that is not helpful information at all. You would have to have a specific date, when the movie is released and/or when you want to watch it.)

69

I like the team’s enthusiasm, as well as the development speed and community interaction that have been felt in recent months! Keep up the same pace. I had written off Anytype, but now I’m returning to it.

70

What I like about this proposal and why

  • Collections and Queries are (almost) combined into one concept and tags become redundant:
    • Simplification is (almost) always good thing
  • Sharing of collections between spaces
    • Avoids creating silos of information which will improve the usability of Anytype for team collaboration

What I like less about this proposal and why

  • An object can have multiple types
    • This is confusing and turns my OO world upside down
    • An object should have a clearly defined format/type (i.e. is a type of )
    • A Collection is really an object that contains references to objects (i.e. composition via reference)

Suggestions

  • Keep the current object - type relationship
  • Merge the concepts of Collections and Queries as suggested
  • Collections become a specific type of Object - This should make it possible to have collections of collections
  • Remove Tags completely by migrating them to Smart Queries - that should be easy :grimacing:
  • Modify Type and Object so that they can be associated to multiple Collections via a type of mult-select property

Radical end of the work-day idea : rename Anytype to AnyThing

I hope that people will excuse the rather opinionated nature of this reply, but I wanted to keep it as short as po …

71

This idea frightens me!
Because my whole data organisation depends to more then 99% on Tags.

Choosing some Tags goes much quicker then connecting the Object to multiple Collections.
OK, choosing some Collections from a list could in principle be comparable easy. But as a result we would end up with tons of Collections and a highly complex Graph that reacts slowly and drives the CPU load through the ceiling.

I have much more Tags then Collections plus Queries together.
More then that: for some Types I use more then only one Multiselect-Relation (that’s one reason why I wish two-dimensional Tags, to get rid of that).

At the moment I’m not able to imagine a concept that really could replace Tags in the future.
If the devs here come up with a half baked concept, it may ruin the usability completely.

.

Anytype offers multiple ways to organize data.
When I started two years ago, it has cost me one full month to test things (every day multiple hours!) and to try the different approaches. I was running into dead ends multiple times before I ended up with my Tag based approach. That worked best for me.

There are some astonishing other ways. For example, there really is a way to use only Queries and they show even connection lines in the Graph, like Collections do!
– Really, this is possible! Queries that show in the Graph connection lines to the Objects!
Two different users came independently up with such a concept; even different concepts.
I tried both and it has some charm. But in practice, I didn’t stay with it. Too cumbersome. Although these two users hyped the easiness of their principle, it was too cumbersome for me and I’ve had always the feeling that I not fully understand what I’m doing.
Today I couldn’t even explain anymore how that was possible at all.

There was another intelligent concept around, where Inline Queries (or Inline Collections?) in the Templates do some really smart things that one normally wouldn’t expect.
But again: I got a knot in the brain while trying to grasp what’s going on. As result, I never really worked this way, although it would have solved a real problem that I’ve had (and still have).

Note taking must work quickly!
If a theoretical better concept forces me, to solve a Rubick’s cube first before I can even start to make a note, then the concept fails.

72

I can understand why this frightens you! I didn’t think it would be easy. This is why I suggested a migration path for people who use tags. However, I hadn’t thought about the graph update problem. If tags were converted to smart Collections that did not update the graph with connection lines, would that make things better?

The idea I was thinking of would involve the tag being converted to a link to a smart collection. The tag would still exist, but as a link to a smart collection. Would that still cause you a lot of pain for those who use tags extensively?

73

Discussions like this is one of the reasons why I’m moving to Capacities. They have a clear concept that is communicated clearly and pursued consistently, and they offer exactly what I need.

74

As a general update, we’re hoping to build out a prototype that the community can click through and experience directly—this should hopefully add more substance to this conversation. It’s still a couple weeks away (no promises), but we’re making progress.

Honestly there so much good stuff in your post that it’s almost impossible to respond to them all. I love the call out to relational data and I learned quite a bit from what you’ve shared. In short, I think this is clearly one of the best ways to build a knowledge base, the challenge I see is an issue of front-loading. It requires a lot of pre-planning of understanding what data/properties/relations you want to have across your different collections. The ideal system would very little front-loading of organisational thinking, but enable you to add complexity over time without the need to rebuild. A difficult needle to thread.

Yes, agreed. The object and its contents remains the same regardless of how many collections you put an object in. In other words, I am always ‘Kaye’—which is the object. But I can be in multiple collections: cousin, vendor, etc. This is exactly how it works in many workplaces: one employee (an object) can be in multiple teams (collections). They are always the same person, but how we view them changes depending on the context.

I’m glad to hear that. Still got a lot more work to do, but we’re making progress. :slight_smile:

Yes, we understand that a fair amount of users are worried about the merging of types and collections—described as the compression or weakening of the barriers of a type. In my mind, this can mostly be solved by only applying one collection to an object. Additionally, we could arrange the UI in a way that lowers the significance of ‘other collections’ that are not the primary/base collection (type).

At present, I agree. In my mind, even in Collections 2.0 there is value in having tags. I think that many users could go without tags entirely, because they would use collections as the defacto tag. But there are others who can find value in it (see below).

It’s a great product and I love what they’re doing and the direction they’ve taken. Thanks for participating here nonetheless.

I can imagine a scenario where you want an item in a ‘collection’ and you want to tag it with some labels but not necessarily organise your space based on the tag. For example: you have a news article that you’ve put in a collection called ‘Interesting Technology’ and you want to tag it with themes such as ‘open source’, ‘security’, ‘local-first’, etc. This doesn’t mean that you want a collection in your space of ‘local-first’ objects, because that isn’t important enough organisationally to warrant a ‘collection’.

75

What I meant above all is the uncertainty that is spread by the announcement or discussion of such serious changes.

We users put a lot of work into the PKM tool we use, and migrating to another tool is a huge effort, so reliability, continuity, and trust in the development of the tool are absolutely essential.

Publicly considering removing tags because tags are something like collections and at the same time considering combining collections and queries (to “simplify” Anytype?) undermines trust in the app. In my opinion, this is a serious mistake.

As for tags: yes, collections can be seen as tags, but the reverse conclusion, replacing tags with collections, only adds to the confusion and, in my opinion, does not simplify anything at all - on the contrary.

As a paying user of Anytype who has put a lot of unpaid work into bug reports and suggestions, I expect a clear concept and reliable development - but what I read in this thread makes me think of an alpha product, and is very disappointing and discouraging for me.

76

I understand that this is not what you want from Anytype and we’re absolutely grateful for all the efforts you’ve put in to make this product better. I truly mean that. Anytype can’t get better without people taking the time to give feedback and pay—for which, you’ve been doing both. Thank you.

At this stage, what you want is from Anytype and the team is not what you’re going to get. I’m glad that you’ve at least found a tool that meets your needs, and that’s the great thing about the modern era—choice.

In my personal life, I like to live in a way where I’m always transparent about who I am and where I’m at because it self-selects the people who are around me. It’s when I’m not authentic to who I am where I will attract those who will eventually be disappointed anyway—so it’s better to not establish that expectation and relationship in the first place.

The same here applies to Anytype and I hope we haven’t misled you to what stage we’re at. We have a very clear vision for empowering digital freedoms across the world, and we’re devoted to making that happen. However we do not have a mature product today. We will change and we want to bring the people with us along that journey. We would rather communicate openly rather than impose change without community input. We do not want to feel like we can’t innovate because this leads to community dissonance.

Again, totally appreciate all you’ve done for Anytype and hope that you find the product and community where you belong. And maybe one day, I hope that we can be that for you again if you ever decide to return.

77

I find myself somewhat at odds with my dear bug detective colleagues :grinning_face_with_smiling_eyes:.
I like this idea.

I am eagerly awaiting the ability to use a tag to view all objects with that tag (without having to create queries/collections). And to be able to add a widget with it.

And yes, it seems that this requirement can be met, provided it is managed properly.
For example:

  • we create a tag-type property
  • we must be able to decide the type of relationship: “Collection,” “Smart collection,” “Label,” or whatever, which implies “Should we create a link between this object and a collection linked to this tag?” “Is it just a label or is there a need to integrate a collection or smart collection?”
  • Boom, quick and done (also plan to be able to define the scope!)

If we just want to mark the object, it works (e.g., as is currently the case, no need other than to put a manually usable label in a collection/query).
If we want to be able to use this tag to dynamically find everything attached to it with a single click (widget, etc.), that’s possible (e.g., classification labels, which I use a lot, and I can have tons of them: here I could click on a label to see my objects, but it won’t create a real link and it won’t blow up the Graph view).
If you want to create a real collection and a real link behind this tag, it’s possible (e.g., “Movies,” “Books,” and it will add my object to these collections, with a link and visible in the Graph display).

78

I not only find at odds, but am expecting that for almost 2 years now… with the TAO.

“Tags” that are not simple select labels, but objects, that one can click and find other objects with that tag was something I was hoping the TAO development would bring.

We do not have to decide anything, Tana Supertags and Logseq DB Tags do all 3… always and at the same time. The types of relationship you mentioned are not exclusive.

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.

The above features are already possible on Tana and Logseq DB, and working very well.
Maybe these 2 apps could serve as inspiration, instead of Notion. (also Emacs Org, for a way to be able to link to headers and headers having their own properties, but not bring down database performance on Anytype)

79

Hey guys!

I think the point is, it’s all about orientation, isn’t it?

I started using anytype two weeks ago and took me a week to get a grip of the thing and now I’m digging deeper.

I love it, but it’s really a rough start to get to the thought of objects everywhere.

Honestly, I tried anytype some month ago, and it was too confusing at first sight, so I left it for obsidian. And Obsidian is easy to start with, because it’s all markdown text files and folders. The rest was linking and tagging.

However, after a few months, I realized that the core of obsidian is not open source, so I had to look around again and came back to anyrype.

To cut a long story short, my findings are:

1.) It doesn’t matter so much how you call collections. The icon is the game changer.

I immediately understood what queries are for, because of the magnifying glass icon

When I changed the collection-icon to a folder-icon (kudos to graphicmail), all of sudden anytype made sense to me and all of a sudden I had an idea how to order all that stuff.

Screenshot_20260314-231410
Screenshot_20260314-2314101080×1257 82.1 KB

Even though that I know now how collections are meant to work, with folders, I feel much more oriented.

Why don’t you call manually curated collections folders? At first sight it seems maybe weird, because collections can do more than folders can.

But where do you put your pictures? Where do you put your files when you want to sort them and bring them to an order?

In a folder.

A folder is a perfect container for any type of digital collection.

And the folder icon is understood worldwide immediately. Everybody knows immediately what it is for and doesn’t have to think about it, how to use it.

folder-closed by graphicmall
folder-closed by graphicmall512×512 8.22 KB

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

2.) There is no second.

Cheers, love the work you do!
Z.

80

Finally，that’s how Tana orgnize nodes.

  • nodes：objects
  • supertag：one node can has multiple supertags
  • propertis（can be fixed to certain supertag or shared across supertags）：property can be assigned to a supertag，or just to an untagged node（when user find many untagged nodes have some same properties，than he knows he should give these properties a supertag to bring these related nodes together to form a supertag set）
  • sets：a certain supertag collection，every supertag has a collection.
  • query：smart collection，for creating cross supertag nodes set by advanced filters.

i think currently types+tags（merged）= supertag.

one object can has multiple supertags.

81

Totalmente de acuerdo, es que ese es el gran muro de Anytype.

Si comparas la experiencia con apps como Notion, que son ultra intuitivas y simples de usar desde el segundo uno, la diferencia es abismal. En Notion abres una página, escribes y ya está. En cambio, aquí el usuario nuevo se choca de frente con “objetos”, “relaciones” y conceptos que confunden a cualquiera.

Al final, la mayoría de la gente no quiere hacer una carrera técnica para organizar su vida; solo quieren soltar una nota rápido o guardar un archivo sin complicaciones. Esa fricción inicial es la que mata la retención. Si no aprenden de la simplicidad de la competencia, Anytype se va a quedar siempre como una app de nicho para entusiastas, mientras el resto de usuarios se va a lo que sí funciona al instante.

Lo anterior es lo que la mayoria de las personas me comentan cuando les presento Anytype.

_

I completely agree; that’s the biggest hurdle for Anytype.

If you compare the experience to apps like Notion, which are ultra-intuitive and easy to use from the get-go, the difference is staggering. In Notion, you open a page, write, and that’s it. Here, however, new users are immediately confronted with “objects,” “relationships,” and concepts that would confuse anyone.

Ultimately, most people don’t want to pursue a technical degree to organize their lives; they just want to jot down a note quickly or save a file without complications. 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.

This is what most people tell me when I introduce them to Anytype.