Collections 2.0 Prototype—feedback is welcome

News
,
83

If you have a Dune: Messiah (Book) object and a Dune: Part Three (Movie) object, they are clearly two different objects. They are clearly also two different types, a book and a movie. But at the same time, they are more related to each other than Harry Potter (Book) and Lord of the Rings (Movie). How do you want to draw the connection between those two Dune objects?

Whether you draw that connection on a ‘property level’ or a ‘type level’ is simply a matter of the mental model you use—you can do either. This is not a fundamental incompatibility, different models work for different people under different purposes. Choose whichever you prefer. That’s the power of Collections 2.0, that you have the choice of defining the mental model that works for you.

Again, you do not need to assign multiple types/collections to objects if you don’t want to, and you also don’t need to draw the links on the graph either. In the example, you can have a Dune Book, a Dune Movie, then add a Dune property to the two objects, connect them view a query, and then turn off graph links.

Apologies, I’m still not clear on the difference you’re describing. The ‘collection’ is the main primitive that groups all of the objects together—such as Book collection. Then the ‘collection view’ is the what you see on screen depending on what filters, sorts, layouts that you’ve set up. Maybe you can screenshot specifically what difference you’re trying to reference.

84

I’m unsure if this analogy helps, but think about Netflix.

  • You have movies.
  • You have tv series.
  • You have short films.
  • You have stand-up.
  • You have reality tv.
  • Etc.

We all agree that these are fundamentally different ‘types’ of media. Within all of those options, they have ‘genres’ such as drama, action, etc. Traditionally, we all see ‘genre’ as being a property underneath all of these different types of media. Now think about two different Netflix users.

  • Person A: is a film buff, and is not interested in anything else.
  • Person B: only likes romance and comedy genres, and not interested in anything else.

In an ideal world, how would they design their version of Netflix?

Person A would likely do it as we’ve traditionally seen: at the highest level are ‘movies’ that are broken down into ‘genres’. They would not want tv series, documentaries, etc. to show up in the view at all.

Person B would likely do something very different. They would have two categories at the highest level ‘romance’ and ‘comedy’. And then each of those categories would get broken down into different ‘types’, such as movies, reality tv, etc. In this case, Person B does not care about the ‘type of media’ as much as they care about the ‘genre of content’.

With Collections 2.0, the perspective of both Person A and Person B is equally valid and can exist simultaneously within the same system. The current system of having ‘one type’ that gets organised into ‘various collections’ has a more opinionated perspective (hierarchical in a way).

Again, type defines an object, while we believe it’s more useful for Collections to define relationships.

85

I fully agree here. However:

I think at the end what bothers me can be reduced to the naming. You are expanding the possibilities of the types (one object with multiple types, type inheritance and nesting and so on) but you keep the query possibilities to group objects in arbitrary ways.

Why then not keep the naming as it is right now? You give more power to types, but they are still types (they define what an object IS, and it can now be multiple things at once, or belong to a subclass). You have smart collections, but they are still collections of arbitrary objects.

86

It could also be…

Types = Types

Collection / Queries = Types / Type-Services

Tags = Types

=> Supertype, Metatype, Unitype: Anytype? :thinking:

87

We’ve discussed this in other threads, but let’s look at it from a blank slate. Let’s completely ignore the idea of types, queries, and collections as we know them. For now, let’s only think about objects and properties.

1) Creating an object

Imagine you just watched Dune: Part One. You open a blank page and jot down some notes. At this stage, what is this object? Is it a ‘movie’? A ‘note’? A ‘review’? To the system, it’s undefined. To you, it’s possibly all three. With one object, you don’t need a label yet—all good.

2) Adding definition to an object

Now you watch Dune: Part Two. You start a second note. You realize both movies share a Director, a Cast, and a Genre. Rather than repeating content independently on both objects, it makes sense for the same content to be referenced across both. So, you create properties and attach them to both objects. Great, now there is a connection between them. All content in an object (title, description, blocks, and properties) gives definition to an object. But properties have a unique power: they create relationships across multiple objects.

3) Building relationships between objects

You’re hooked on the Dune universe and start reading the books and playing the games. Now you have many Dune-related objects in your space, which share some properties but not all—the books don’t have a ‘cast’ property and the games don’t have a ‘director’ property. Their relationship via properties is weakening, although their relationship in your mind is clear as day: they are part of the Dune universe.

Additionally, you’ve started creating objects for thousands of other movies, books, and games, and all your objects are now feeling chaotic as properties are not enough. Some relate to each other via their creator (Jane Austen), others by genre (romance), and others by rating (5 stars). But there’s no way to clearly see and make sense of all the objects.

4) Making sense of the relationships

Because properties alone feels restrictive, our instinct is to add another frame of organisation. Naturally, most people will throw all their books, movies, and games into separate folders.

  • :file_folder: Folder: Books

  • :file_folder: Folder: Movies

  • :file_folder: Folder: Games

This is the obvious solution, but it’s driven by a lifetime of habit more than true helpfulness. For example, imagine a friend is interested in Dune and asks you to give a recommendation on where to start. What do you do? With all your Dune objects split into book, movie, and game folders—this is a huge pain in the ass. So, you need a way to cross these single-dimension boundaries and view all your Dune objects.

Imagine you embark on writing a romance novel and you want inspiration. Again, all of your romance-related objects are split across different buckets. The same thing would happen if somebody asked for a list of your favorite authors, most highly rated media, etc.

We should ask ourselves: why is the categorisation of ‘book’, ‘movie’, and ‘game’ of persistent higher importance to you than ‘Dune’, ‘romance’, or ‘personal favourites’? Depending on what you need and when, different models of organisation have more utility to you. At times, you do want to see all your movies in one place. At other times, you just want to feel inspired by your highest rated objects across all mediums.

Our relationship with objects is fluid

Types, Queries, Collections… these are all just semantics for different ways we make sense of our objects at any given time, for any given purpose. Instead of hierarchical folders, Anytype’s system ‘groups properties together’ and performs an ‘object categorization’ function through them. It doesn’t matter if they’re in the same group via a rule-based query, manual selection, or a mixture of both.

Your relationship with your objects is fluid; the context determines why they’re together in the first place.

Thus, naming one form of object categorisation a type, another a query, and another a collection is an exercise in defining the ‘how’ more than the ‘why.’ By merging these terms, we aren’t just simplifying the vocabulary; we are building a system that reflects how you actually think—where the reason for a connection matters more than the technical method used to create it.

@AFoletti TLDR: we’d rather have one name because these functions have a lot more in common under this new framework. ‘Collections’ was simply the best choice via community poll and internal discussions.

88

And here comes my last bid before town hall:

What about ‘Perspectives’?

Because that is what they actually are: Various perspectives on the same thing.

Like this, it makes totally sense to have the same object shown in different places.

And they could be led by Tags as headers.

=>

P-Tags

Petags

PTags?

89

I really like this new structure; it solves several of my problems and simplifies my work overall. I set up something similar in the current version of the system, but it requires a lot of manual work.

And when I recommend AnyType to friends, I realize that no one will bother as much as I do, so they’re unlikely to use it. But in the new structure, everything is already organized as it should be.

I have a version of your unsorted objects that you called “base.” This is a very important feature when you want to quickly add something without worrying about where to put it. Also, the automatic categorization suggestion is fantastic; I really wanted it. I can’t wait to work with the new system.

To create a set of different objects, I use a filter by property. It’s not very convenient or intuitive; in some cases, I need to add an additional filter to exclude what I don’t need.

I also really like the idea of ​​nested objects. I also use a similar sorting method based on the multilist property, but it’s not very convenient because there’s no category-subcategory relationship. As far as I can tell, the new structure solves this problem.

Thank you guys for your work! :heart:

90

.. or

Anything?

91

What about Classes from Object-oriented programming - Wikipedia ?
And inheritance ? Cant Anytype go this way?

92

Hi there. I’m not sure if this was already discussed (the thread got pretty long), but a basic word search didn’t return any results, so I’ll ask.

Is something like a “Rollup” feature part of Collections 2.0? I need it for a few different things, here are some use cases based on the Dune example from the prototype:

We have (correct me if I’m misreading the concept):

  • The Dune franchise is a parent collection

  • It has child collections: Books, Movies, TV Series

  • Each title within those collections is an object

I want to:

  • Use case 1, Aggregated rating: I want to rate all Dune books individually and see the average rating surfaced on the Dune Books collection page and rolled up further to the Dune franchise page to see the average rating of the entire franchise.

  • Use case 2, Progress tracking across children: Say the Dune franchise has 50 titles total across books, movies, comics, games, etc. I want to set a status on each title (like in a Kanban view) and see an overall progress indicator on the parent collection page, e.g. “13% of all titles done”. Drilling into the Books collection would then show “64% of books done”, and so on recursively.

  • Use case 3, Automation based on aggregated status: Taking the previous example further: when 100% of child objects reach “Done” status, the parent collection itself automatically moves to “Done”, so it shows up correctly in a Kanban view without manual intervention.

One more thing that’s not directly related, but important at the architectural level:

  • If I organize a collection with multiple levels of parent-child relations, e.g. Franchises → D → Dune → Movies → Dune: Part II, when I’m on, say, Dune: Part II page, I’d like to see the full path as breadcrumbs somewhere in the UI (top navbar, sidebar, etc.) and be able to return to any level in that chain.
  • In order to implement multi-level parent-child relationships, two-way relations seem essential: when object A adds object B as a child, object B should automatically add object A as its parent. I’m new to Anytype and just starting to explore it, but from what I can tell this isn’t currently supported.

Thanks in advance! Happy to clarify anything if the examples are unclear.

UPDATE:

Found a mention of rollup and automatizations in a different thread (the Collections 2.0 architecture outline), so I think that partly answers my question.

That said, if you could elaborate on it (especially the navigation part) or give a rough idea of when it’s planned to be implemented, I’d really appreciate it. I’m trying to decide whether to move my system to Anytype, and if so, when to plan that migration.

94

This is not correct. In the example, Dune, Books, Movies, etc. are all their own collections. They do not have a parent-child relationship as a nested collection. In the prototype video, the example used was Online Shop > Products — this is a nested collection where the properties of the parent collection can be extended to the child.

In all three of your use cases, it would be possible in the new Collections 2.0 but they are different features within Anytype (rollups and automations). When it comes to specifics of your use case, it would not work exactly in that way. You are thinking of the system as being hierarchical, when it is not—everything is still an object. You can accomplish the same outcome, but you simply would set up a either different collection or view for each of those ‘hierarchies’.

Building from above, Anytype is not hierarchical, so this frame of thinking doesn’t apply to the system underneath. While we can implement breadcrumbs to a certain extent, they are not a file path per se.

Again, it’s not hierarchical so it depends on what’s trying to be accomplished here. You can take a look at some online materials about ‘object based notetaking’ and that should help you to understand what the system is like.

‘Nested collections’ provide some ideas of hierarchical behaviour (which I can understand), however it’s not inherently hierarchical. This is why at one point we even considered if ‘joint collection’ is a better name because that’s what’s happening on a technical level.

This topic is subjective and has been ongoing for a long time. If there isn’t much community support for a specific alternative option, we’re not exploring others naming at this point.

As mentioned previously, using such a common word will likely cause more confusion than anything else. Case in point, the very sentence I just typed. :stuck_out_tongue:

95

So what about "Any-Thing" or “Any:Thing”?

Shouldn’t be, used too often in regular texts. :slightly_smiling_face:

96

Feel free to use a different thread. At this point, I’d rather we focus the conversation at the functionality/system at hand than continuing the naming debate. I’m mentally fried on this topic for now lol.

97

Thanks for the reply :sign_of_the_horns:

I see your point, but may I ask what’s wrong with a hierarchical structure? When it comes to complex projects, it’s one of the most effective ways to organize everything so it’s intuitive and easy to navigate.

Allow me to give you an example from my professional background (building production systems, processes, and workflows, as well as product design):

  • Let’s say we’re building an abstract App. The only effective way to make it feasible and manageable is to decompose it, because “App” is too big of an entity (or an Object, if you prefer). So we break it down into Modules (e.g., profile, chat, feed, etc.).
  • Those are still too big to work with, so we decompose each Module into Features (the ability to do something within a Module, for example, text formatting in the chat Module).
  • And even those guys are too big, so we break them down further into Actions (primitively: formatting text as bold or italic or whatever in text formatting Feature in the chat Module).

Now we have the whole App decomposed from top to bottom (or however you prefer to see it), basically making Actions work items, while their parent entities are simply containers. To navigate through it, you need… well, hierarchy. As we established, our App consists of Modules, Modules consist of Features, Features consist of Actions, so if the structure is flat and all of those entities are on the same level, it becomes vague and unclear, which makes the boundaries of each object blurred. Therefore, each level needs to be clearly contained within its parent, making it easier to manage and focus on. Of course such a structure needs clear navigation features – breadcrumbs that show all nested objects (App / Module / Feature / Action) in the chain, and/or a tree in the sidebar.

It’s kind of similar to the Atomic Design approach, which you’re familiar with, of course (Atoms → Molecules → Organisms → Templates → Pages). A more casual example would be organizing any files in folders:

  • If you have a catalog of, let’s say, books, you need it to look something like this: Franchises → D → Dune → Books → Children of Dune. Children of Dune and “Books” are not on the same level. It can be done in different ways (for example, by media type via tagging), but conceptually, “Books” is a folder that contains related content.
  • The other thing is that the same object, in this case, a book, can be part of multiple branches, e.g. Books (a general category, not the same as within the Dune franchise) → Genres → Sci-Fi → Children of Dune. And that is kinda the case shown in the Demo.

However, I’m not arguing with your vision, just curious. And if my input gives you something to think about or helps you solve problems you’re facing while designing the app, I’ll be happy. :blush:

98

Nothing is wrong with hierarchical structure, and you can organize your objects in an hierarchical way in Anytype, but you don’t have to. :slightly_smiling_face:

Basically, a hierarchy can be established by links and backlinks.

The basic object links to its child objects and so on.

Like this, you can have a one dimensional hierarchy or a multi-dimensional network.

99

There have been many nights where I’ve lost sleep on whether or not we should have just used a simpler system like hierarchical folders—rather than the complex system we’ve deployed. Alas, we are where we are. :wink:

There’s nothing ‘wrong’ with hierarchical structure—they’re very effective as you’ve described. However, every system has a tradeoff. What folders gain in structure, they lose in fluidity. That is, folders care about where items are located. While in an object-based system, it cares more about how items are connected. They are fundamentally different approaches with their pros and cons.

If you’re into hierarchical folders, I would say you should save yourself the pain and use a different product. Anytype is fully in the object-based system, which means you will constantly have to ‘hack’ your way into hierarchical setups. It’s certainly possible like @Zak-from-Zork mentioned, but it gets cumbersome as your system grows in complexity.

Nested collections is actually something I really wanted to drive into the product because I know how many people are used to folders, and this system gives them a more familiar ground to do things like project management. However, it’s still not a tree hierarchy system.

Anyway, I’m not here to convince anybody on which system is best. Anytype is object-based, so it can never do what folder-based systems were designed to do well. But if you’re into the object-based system, then this is the conversation for you. :slight_smile:

100

I think I’ll wait for Collections 2.0 with rollups, automations, and object-dedicated chats and see if I can build my system with those tools.

Thanks for the replies, and good luck with the development :sign_of_the_horns:

P.S. Btw, object-based and structure-based approaches aren’t mutually exclusive. It can be both at the same time – where objects are located and how they’re connected.

101

Yes, you absolutely can have ‘hybrid’ approaches to a certain extent—but they’re still not the same.

A good (and popular) example of this is Notion. They have a folder-hierarchy based system at the core, and you’re also able to have properties on pages in a database and cross-reference those pages onto other pages (connect them). Additionally, you can have ‘synced blocks’ that pull reference data across different pages. This feels considerably more ‘connected’ as a system than Google Docs. However, this is still a fundamentally tree-hierarchy system. If you delete a page that has another page nested inside it, the ‘children’ will also be deleted.

Anytype (and other object-based systems) don’t have a location at all for their objects. We can emulate structure through views, categories, queries, etc. (like Collections 2.0) but the system principles on a technical level are fundamentally different. Structure is emergent, not imposed by ‘where an object is created’ like it is in tree hierarchy systems. We cannot suddenly implement location for objects, file paths, etc. in the traditional sense on top of this object based system. If you delete an object that has another object linked inside it, the linked object will still exist.

Anyway, I digress. This is a much larger topic that has many online materials on. :slight_smile:

102

@dnlvspr I somehow don’t understand you, sorry.
In my opinion, a hierarchical structure has only disadvantages, but no advantages.
In fact, I left OneNote because it offered only a hierarchical, folder-like structure and this was on the long run not flexible enough for my needs.

A simple example:
Let’s assume I have three “folders” for my contacts:

  1. One for family members.
  2. One for customers.
  3. One for suppliers.

Normally it’s clear which person belongs into which folder.
But now there are guys like my cousin. He is of course a family member.
But he also runs his own business and is sometimes my supplier.
But sometimes he’s also my customer.
– In which folder should I put him and everything that has to do with him?

If I put him in all three folders, then there is a lot redundancy.
And if I use virtual copies with only one original and some links to it, it leads always to chaos and becomes more and more cumbersome (at least in my experience).

Anytype gave me finally the freedom I wanted and needed!
It simply doesn’t matter where Objects are physically located.
There is never redundancy. Each Object exists only once. But but I can put it into as many Collections as I want.
– Not to talk about Queries; a Query will find him no matter where he is and no matter to what he’s connected. And I can have as many Queries as I want.

In my opinion, it’s an immense failure of the whole Windows file system, that it doesn’t work as Anytype does!
There is no flexibility in the Windows file system to organize data (like for example images) in a meaningful way. No matter what one does, it often doesn’t fit to the actual needs.
It was the same with OneNote.
Hierarchical structures are in my opinion a relic from the early days of computing.

If you use Tags, you could see them as “folders”. But, admittedly, Tags are actually still limited. It’s actually not really possible to built a kind of a hierarchical structure with them. But the team is working on it, the situation should become better in the very near future.

103

@kaye, @Code-Jack You’re talking about folders in the classic sense, like in Google Drive or most operating systems – a multilevel tree where an object is “physically” placed in a dedicated location. I agree that such a structure isn’t usable. I meant to use folders only as an example to illustrate hierarchical organization, where objects can be clearly arranged relative to each other. In other words, I was referring to the ability to present such a hierarchy as a kind of “view”, not the underlying architecture of how objects actually work. I guess that wasn’t very clear from my post – my apologies.

In my example, the hierarchy (Franchises → D → Dune → Books → Children of Dune) doesn’t prevent the object (book) from appearing in multiple “branches” at the same time while still remaining a single object.

That’s what I’m referring to here: