On the Present Single-Type Set Paradigm

Sets don’t make sense (to me). Why do I have to assign my Set one specific type to draw objects from? I don’t understand this at all. There’s no requirement for me to specify any one tag I want the objects of which to be listed in the Set, before I even create it, so why the inconsistency? Types, as with object icons and titles (now manifest with the new Note layout, simply an object without the Title relation), should be treated like any other relation. Each of them merely represents a selection of templates, a list of previously assigned empty relations, a layout and a title. What this means for me is that I can’t create different views, in the same Set, displaying information about multiple object types I frequently use. I just don’t see the necessity for every Set to have a Type. With the goal of consistency, non-Type relations should be able to have their own Sets. If you think that sounds awfully limiting, to the point at which you don’t see yourself having any use for this breed of relation-specific Sets, this is why I disagree with the current paradigm. I think Notion sort of got it right. They don’t force you to declare any arbitrary properties, but they also treat pages linked to pages and pages inside of databases as if they live there and aren’t simply links; this latter part isn’t great, so good on Anytype for avoiding that. Notion’s approach means you can’t aggregate pages from anywhere—they have to exist in that database. Anyway, I still like there’s no expected minimum filter in Notion. Anytype essentially requires you to declare this one specific relation, in effect restricting the objects you can view in a given set immensely—all thanks to some permanent default “Type” “Is” “X” filter. I also find it annoying that I can’t just Ctrl+N to create a new object while inside of a set and that I can’t complete my tasks from list view. So, what are your thoughts on this?

17 Likes

Once sets from relations gets released, you would theoretically be able to create sets which displays objects of various types matching a certain criteria for a relation and thereby removing the type = <name> imposed filter in place now. So you could even use a set to list all objects you’ve created ever in Anytype using a relation such as created by = <username>


I’m not sure how the team is planned / has planned to handle the feature, but it would be immensely great if sets are decoupled and exist as a special object type. What I envision the flow is to be as such (after sets from relation and inline sets are released)

Creating a set from dashboard

  • User creates a new page from the dashboard using the + icon. The type is set to the default page they selected in the settings
  • The user then changes the type to a set
  • The set displays all the objects ever created in anytype, except the internal types, etc.
  • The user uses the already existing filter to display what they want. This should now contain a new type of option which should help one to filter objects only matching a type

Creating a set inline

In the / menu, there must also be a sets option which would create an inline set, the other operations are the same then, all the objects are displayed and the user can then just filter them to their liking.
It would be also easier to migrate the current sets to the new flow. Since the filter is now more explicit and user controlled


I’m not saying all objects created should be displayed. Without any filters, I though all objects created by the user will be displayed since there is no criteria to filter them :sweat_smile: The other way to handle this would be:

  • To display no objects in the set unless a type of filter or a relation filter is used but that is not much useful and would require an explicit filter such as <Created by is not empty> to list all objects
  • To populate with a default critiera. i.e, <Type of Default Page> when created from the dashboard ane <Type of the parent page type> when created inline
9 Likes