With “Querytable”, you are immediately losing a large number of non-tech savvy users. It’s a very inaccessible word. “Query” itself is a little out there for many people.
“Search” and “saved search” are both very accurate and super accessible!
Hello, thank you for your suggestion, Right now our thinking is to make a new type of layout which we will call a LIST. Lists could be custom (collection) or smart (set), this way you also will be able to have specific types and templates for objects with layout list, like “Reading list” or “To-do list”. Would be happy to get your thoughts on it.
Hello @anton,
I would like to share my thoughts with you. However, I don’t yet see exactly the picture what the team has in mind with this new “List” layout.
In fact, as of today, I can see only very little use for Collections.
I found out that it is easier and more practical to work with tags and fix a Set in the filter settings to certain tags, than to work with Collections and create visible links in the graph.
My current workflow is such that I have only very few Collections, which I mainly use to create new Objects with the appropriate template.
This results in a basic structure in the graph view. But apart from that, I only use sets for the daily “database query” work.
I no longer use the various filter settings of the Collections at all. Sets do the job for me.
In the early days, I worked more with Collections. But I found it rather cumbersome to link existing Objects to Collections or to change existing links.
It’s much easier with tags. If you do it this way, you don’t have these visible links in the Graphview, thats right. But I don’t really care about that very much.
The Graphview just looks cluttered and chaotic if there are a lot of links running all over the place.
I find it more useful if the graph only shows the basic structure.
It’s clear anyway that there are all kinds of cross-links.
If Graphview had more useful filter options, things might be different.
But anyway, it’s too inconvenient to set such links and change them. The benefit of being able to see them all in Graphview is too small (at least at the moment).
It may be that I will think and work differently at a later date, when Anytype has more features and the workflow is simplified.
From my point of view, however, there are more urgent issues at the moment.
One of these important issues:
I can’t currently see any way, for example, of including the name and address of a “Human Object” in the form of an invoice. The whole relationality is still too limited.
But i’m curious that the team comes up with! 
I really like this idea, for three reasons:
- It means that we can create many types that are sets or collections. For a long time, I was advocating for collections to be first-class objects so we can create templates. But having them as layouts gives us even more flexibility to create many types that are collections, with their own styles and relations.
- It makes a lot of sense to have sets and collections be united under one thing because they fulfill the same mission: displaying a list of objects.
- I love the name “list”! It’s simple, accessible, and to the point. Sets and collections are indeed lists of objects so it makes perfect sense.
Just one comment: rather than “custom lists” and “smart lists”, I would just have “lists” and the option to make them smart. This would greatly simplify user experience and remove the possibility of confusion.
Hello. My workflow is exactly the same as @Code-Jack’s. I personally do not have any reason to use collections (or the future “manual custom lists”), at least for now.
That being said, I think that having one common layout, be it called a list or anything else (list seems OK to me), makes sense, all things considered. If we put the logic as lists being objects which collect existing objects in the whole space, and you can either populate them manually, or through queries, the user base of Anytype could find the whole concept more intuitive to work with, I assume. We would no longer need to wonder whether to create a set or a collection. You just create a list and populate it as best as you can.
I second this. I think that making the lines between sets and collections as blurry as possible would be beneficial. It would be great if making a list being a set was just a question of adding a query on top of the existing list, be the list populated manually or collecting based on some criteria. But then again, you basically end up with just current sets, only extended by the option of adding objects to sets manually (as in “linking the objects to the set”). The objects can be then further filtered on, as in the current sets.
In the beginning I thought, the PARA concept would be “the big thing” to bring more structure into the chaos off my thousands notes off all kind.
But in practice I found out, that PARA doesn’t work for me.
Too much thinking all the time: “can this called to be a project?”
Or “does this better belong into resources?”
So I skipped PARA.
I also skipped to create Bookmarks on their own.
It works better for me to paste my URLs in Notes (as Bookmarks).
This made an own Collection for Bookmarks obsolete.
Now I haven’t anymore two differnt places for Notes and (separate) Bookmarks. There are only Notes now. Whenever I look for anything I ever saved from the Internet, I look into Notes.
I store them in a Collection, yes.
But the Collection serves not as the place to find them.
For my daily database queries I use a Set that filters the Notes. This way I even find Notes if they are not in this specific Collection but elsewhere.
It makes sense to store all Books in a specific Collection. So one can say: “all my books are here”. That’s a use like a folder in Windows.
But I found out it makes no sense to work with too much “folders” (Collections) for two reasons:
- Some Objects can belong to more than only one single Collection.
(OK, we have Links and so on, but they are awkward to use in daily practice.) - We have a database in Anytype, we can use Tags and filters!
That solves the problem with the hassle “this Object belongs into this and that and also that”.
Tags solve this problem. No need for many Collections.
Now I only have a few Collections left, for the broadest categories AND for creating new Objects with the fitting Template. The rest make the Sets.
In short:
Collections are used for creating objects AND for storing them in a broad structure for having a nice graph view. (Less is more!)
But Sets are the thing to go for the daily database queries, to find a specific item.
Because Sets can catch everything (and that from all over the place); the rest of the job does the Set’s filter.
So, a Set can do everything for queries. For daily use.
Collections are more static. Create an Item in it and the new item is automatically included in that Collection and there is a visible Link in the graph.
If a Set could do this job also, there would be no reason for Collections to exist.
All these visible links all over the place (if you link an Object to more than one Collection) confuse more than they help.
A complex graph looks fascinating, no question. It’s a real fun to “surf” in it.
But to be honest, the real use of a graph view, with all details, is marginal.
It’s better to hold the structure as broad and clear as possible (like a tree-diagram), without too many folder-like things like Collections.
Hello @anton
I think I get now, what you mean. I just was about to make a feature request for a new view in Set & Collection. Seems you have already such a thing in mind with your mention “Reading list”?
Let me explain what I miss at the moment:
Let’s assume, we use fa Set for a daily journal. There are many entries in such a Set (one or even more per day), often only short ones (sometimes only two or three lines, oder maybe a few of them).
If we now want to read what has happen in a specific time period, we have (at the moment) to click each single entry that is included in our filtered Set.
It would be much better if we could switch the view in a new “reading mode”, so that all entries “expand”. Now we could read them all in a fast way, like a longer Page, without further need for clicking on each single entry. Just scrolling in the expanded list view.
If you have something like this in mind, with your aforementioned “Reading list”, then I really really really like this idea!
The practical benefits for everyday use would be enormous!
At the moment, a Set is very good at finding and listing entries quickly. But to be able to read them quickly in their full length, the aforementioned feature is missing.
A possible way to implement this:
Simply implement a new button in Set & Collection: “Reading mode”.
After clicking on it, a long page opens in which all filtered entries in the list appear full expanded, one below the other.
So you don’t need to change anything on the Set & Collection (apart from the new button). Just implement the feature to merge the data from the filtered List (each entry full expanded) into such a temporarily Reading Page.
100% agree.
In a Type, one defines properties/attributes.
Each property/attribute has a type of its own, as is the case now: text, select, etc.
One of these types for a property/atribute is a RELATION to another object.
The point made that if you put a date, and other objects also use a date, they are related…I think this is confusing.
In Object Oriented Programming we have the concept of ‘simple types’ (such as dates, etc) and complex types, which are basically objects (well classes really, from which objects are instantiated) a user creates.
As for ‘sets’ - anyone who calls it a database does not understand unfortunately how (relational) databases work. You define a structure (table) with fields. This is not what a set does.
A set is more like a query. The ‘view’ part of it would be your SELECT statement and the filters would be your GROUP BY, HAVING and WHERE clauses.
Using a name of ‘Search’ or Query’ is more appropriate, because sets also do not make permanent modifications to the data. Just like a relational DB query would not do.
So, Search/Query and then the concept of ‘Views’ within that makes perfect sense.