Yes, we’ve considered this actually. Creating a ‘Tag’ collection and then tags in nested collections. The user can then ‘hide collection on all objects’ so that the tag collection itself doesn’t display on the object—behaving similarly to how some users are using tags today. We also need to do a deeper dive on how this would work when you tag blocks.
This seems like a more confusing way to express the same thing. There are properties (Genre, Status, etc.) and property values (Science Fiction, To Do, etc.). A type/collection is can be viewed as nothing more than a group of properties that you apply to objects. Indeed, one way to look at it is that properties and the property values are on the object. However for people’s mental models, it’s simply easier to view the properties as being part of the type/collection that you apply to objects—because that’s the context for how they’re used. For example, if you have a ‘Category’ property, it’s very important to know which collection that property is part of because its highly influences the values (People Category, Movie Category, Project Category, etc.).
The terms are being used as they are conceptualised (and in some cases, they are interchangeable due to the merging of primitives). There has been a long debate on the names already in the past, feel free to reference it here.
We have considered sub-collection as well as joint-collection as names. It’s not set at this stage, but we’ve used nested-collection at this stage.
Yes, I won’t comment on every name alternative comment because we’ve already gone through this exercise. ‘Collections’ was the far away community pick at the time and there seems to be little interest in the unique names proposed so far. It’s a subjective and opinionated conversation understandably.
In some ways, you are completely right. Nothing much changes and you can continue to use Anytype as you have been. However, for those who benefit from this more flexible approach, Collections 2.0 will likely change how they organise their entire spaces.
If an object can be part of multiple types/collections, there is no fundamental difference between a ‘type’ and a ‘collection’, they are just words referencing the same capabilities at this stage. But yes, agreed that there absolutely needs to be an intuitive interface for managing all of your primitives: objects, properties, templates, collections, etc.
I could not agree more. This is why I occasionally even write (smart) collections because they’re actually fundamentally the same thing just with add-ons. But like with most things and past habits, it just depends on people’s mental models. I can understand that people using ‘types’ for years finding it hard to view it in the same way.
Indeed. I hear you. We need to be cautious in our development and implementation. And before we make any drastic changes, we should ensure that we don’t cause data corruption without recourse. I hope that this open and continuous communication on Collections 2.0 shows that we understand this is not something that should just be launched without proper consideration. Your concerns are very valid nonetheless.
Technically this can be done with ‘views’ where objects that don’t have certain property values would not display in a view. Then you can setup a seperate view that surfaces all of these ‘invalid’ objects.
Indeed, this is the direction we’re heading towards—especially with the community feedback thus far on really wanting Auto Collect.
I understand where you’re coming from, and it’s totally fine if you want to view it that way. That being said, both types/collections are just ‘labels with a group of properties’ that you attach to objects. For the most part, people are talking about ‘objects as pages’. But we actually have other primitive classes (chats, etc.) that are inherently different objects. I don’t want to go into that though because it will convolute an already complex discussion.
Yay! 
Indeed. A big challenge has been the names for these conceptual shifts to existing users, and then thinking of names that make sense for somebody entirely new.
We’ve considered using ‘type’ and ‘sub-type’ however it’s neither a unique name nor is it intuitively clearer than ‘collections’ to new users. As a comparison
- An object can have multiple types, such as a Book Type and a Dune Type.
- An object can belong in multiple collections. such as a Book Collection and a Dune Collection.
This was a wonderful and thoughtful post. Indeed, it does actually reflect a lot of our thinking about information architecture. We focus a lot more on the relationships and context that objects have, not just the ‘boxes’ that they’re in. It allows for more fluid and useful information. There was a consideration to calling everything a ‘tag’…need to think further.
Indeed, I feel similarly.