Delete sets as a standalone object type. The word and concept “set” should be removed from Anytype.
Add an option, inside collections, to query objects by type or relation value.
ADDITIONAL CONTEXT
Anytype is confusing to new users. Very confusing. Sets are among the most confusing aspects. But a set is just a collection of object (specifically, a filtered collection of all objects of one or several types or relation values). There is no reason that “set” should be a standalone object type. It adds nothing other than confusion.
With collections gradually becoming more powerful, it should become the primary way of organizing objects. Merging sets into Collection would make onboarding of new users and use of Anytype in general significantly easier and more accessible.
A set isn’t a collection of anything. It’s a saved search. By all means, let’s think about whether a different name would make sets easier to understand.
It’s a saved search of… objects. It collects objects from one’s space based on one’s search query, and displays these objects together. By any possible definition of “collection”, sets are collections of objects.
Set are like view.
Collection are like database.
We need both of them, but pehaps not with their actual form/name.
We need set/view, a view that can be applied to the entire anytype or just to a collection (this filter is currently missing).
Sorry to push back, but really, to me sets and collections are just two different methods to arrive at the same results: a custom display of objects present in the user’s space.
Sets use queries while collections use links. So it’s a difference in how we arrive at the same result.
That’s why I’m definitely not saying we should get rid of queries. I think querying objects is a critical method (I use it a ton and in many cases, trying to replace sets with collections would be a nightmare). I’m just saying that those two methods should be merged into a single object type, and because Collections are far easier to grasp to new users, sets should be merged into collections.
I’m not saying they’re the same. I’m saying they fulfill the same function (collect objects) and that merging them into a single UI would be a drastic improvement in terms of user experience, accessibility, and ease of onboarding.
I believe under the hood collections and Sets are technically the same, where the query for a set is defined by Object Type (a Relation) or the presence of a (user chosen) Relation and a Collection is a query of user defined Object (hidden ID Relation). You could argue that they are the same and that linking an Object to a Collection is the same as adding a filter option to a Set to show just that Object (query on Relation “Object ID” with value in a array of user defined ID’s). On the other hand, you could argue they are different as the current UI of a Set does not allow mixing of multiple Relations (either in the traditional sense as an Object Type Relation), while a Collection seems to allow this by the use of a hidden Object ID Relation.
I am excited for the new search and I have nothing against your vision.
However, please don’t break current features of Sets. They better suit my use cases and I would be sorry to see them be nerfed.
Is UX improvement included (but not mentioned because there are many at each step )?
Like drag and drop into inline collection which I regularly miss .
.
