Perhaps one way to solve this is to allow more robust filters for Traditional Queries, which allow including arbitrary collections in the filter in addition to other criteria. For example a query like (property[“book”]==”novel”) or (collection==”my comics”) would include (1) all objects that have a property called “book” set to “novel”, and (2) all objects in the “my comics” collection. (1) is dynamic, (2) is manually defined.
That way there can be both automated and manual elements, and multiple collections can be included in a query.
Somehow intuitively I think queries should be on top of collections (queries let you also find/include collections) rather than collections on top of queries (i.e. collections that let you add queries). Mixing the two is ok but Anytype should never get rid of dynamic queries, it’s a powerful core mechanism.
Tags could always have value, but probably much reduced than currently.
Very good goal!
Just hope the ability to add manually objects to a collection (like currently), without being managed by rules, is still possible. If to make a collection of items that for example, I want for this weekend, I have to setup the infrastructure and rules for them to be “auto added”, it would be a regression.
For me, Anytype collection system are like Tana/LogseqDB (super)Tags. In this view, the tags system on Anytype would seem redudant. But I do not find that myself.
I agree with @Shampra on this one: There is value with keeping tags and Tags as Objects. Unless the team vision is even more global/complete. For example, a Tag in LogseqDB, in Anytype terms, is an Object, a Tag, a Collection and a Query(Auto Smart Collection). This for me depends on how the team wants to progress towards the goal of Collections 2.0, and it is not important for me “how” they get there, as long as they do
On the topic of the Base collection, I am an “Inbox” user myself, but that is just personal preference. If the “Base” collection can be renamed, it does not really matter, does it?
Great video! High quality with @kaye showing and explaining the collections 2.0, and the collections 2.0 itself. Lots of little details were explained, and the future looks very promising!!
Just an idea: to change the object title, based on the type
Example: I have an object called “Webdesigner” (type = “role”), where I collect all the actual people that are in this field. And I have an object called “Webdesign" (type = “topic”) where I collect all the information, tools, ressources etc I need and work with. Combining both would be great! But right now, going with two types is better in terms of linking and clarity.
I think there are many instances, in which you’d want to slightly alter the name of an object, to better suite the second, third, fourth, … type its in.
Let me appreciate the works put into collection v.2.0: property and canvas now look more approachable together, and it is great to have power to organise properties; and quickly move onto the complicated things
It might seem a confusion from programming language, but if we use alternative language, there might not be contradictions. Here are two analogies that might help understand the mindset. Let’s start with a simple example.
Physical notebooks and ring binder
Since Anytype is a note-taking application, why not take a reference to the original analog versions In a single notebook/journal, we can have different sections for different purposes: dated pages, project planning (structured, like queried); undated / blank pages (purposes to be specified upon the date / allocation).
Query is like bound notebook; collection is like ring binder. However, we can just tuck random papers into notebook, and delicate a specific section for a specific purpose (query) in ring binder. As long as the indexes/dividers are clear, the purpose/arrangement of each section can respect their own set of rules.
Now let’s move onto a possibly over-complicating analogy.
Legal Principles
Since we are giving rules in the structuralisation of collections, a similar process that exists in the world is the construction of law. (I am only attempting to utilise the language; I didn’t study law so excuse me if the interpretations are wrong). Depending on the countries’ legal system, we have
Everything which is not allowed is forbidden. This resembles traditional query.
Everything not forbidden is compulsory. This resembles Collect Once.
Everything is allowed even if it is forbidden. Resembles Auto Collection, with users’ instructions overriding the original rules.
Everything which is not forbidden is allowed. Resembles Collect Once with filters. Everything can be added, but filters act as gatekeeper.to prevent added object which doesn’t respect the conditions to stay outside of the collection or to be stopped at display.
Allowed vs compulsory (e.g. allowed to drive vs actually wanting to drive vs. must drive)
Included but not display e.g. Add all project tasks in the company, but only show my working tasks.
Reject inclusion when users manually add forbidden objects
Case Law / Common Law, which looks at previous determined cases to tell what the governing rules should be or whether future cases (objects) are applicable. Like the demonstration in collection v.2 prototype video starting from around 8:07.
While these might not be daily life language, these condense what can/cannot show up in the society (in Anytype’s case, show up in collection). To simplify, we have some basic logic:
Filter In rules implies objects can be included.
Filter Out rules implies objects are forbidden.
(Unless) Otherwise specified rules override the formerly given rules.
If we stored details to these specified rules (e.g. manual addition of objects), we can toggle it on/off as needed. Then List can serve both query and collection.
The order to which rules are priorities or governing rules e.g. Constitution vs state laws. In collection, filter in is priority; in query, fitler out is priority. (No matter what name we end up using, as long as we make the logic clear, we can easily tell what is being done)
Moving onto some contemplations:
I feel like we are getting to property as object.
I imagine one thing that I might want to do is to click on Dune (on the Children of Dune object) to reach for Dune object, not just Dune collection. This could then be one part of the implementation for relation as object
How is nesting/hierarchy going to be determined? Is it determined by users or could it be retrieved/calculated?
The complication lies in tag as objects and objects as tags, with bidirectional linking and relation, and possibly relation as object.
To complicate things for multi-type / inheritance, I would want to have a ContributorsRelation in Database collection (parent collection), but then (1) display as author (alias) for BookType, (2) include CastRelation and DirectorRelation for MovieType.
You should already be able to do this in query/collection with advanced filter. First, create a query that doesn’t limit to single object type, e.g. last modified date. Then, add advanced filter. From the advanced filter, there is a “turn into group” option at the three dot button beside each criteria where you can add multiple sub-criteria.
Hi. I’m a long time anytype user. Watched the video by @kaye . It did a good job of explaining how the new collections work, including all the new features. But it felt like it was a lot to take in.
I didnt feel very inspired by it. It seemed like a bunch of features being described to me. I couldnt imagine using them myself. As a programmer i was impressed by the database like approach to the whole thing, but thats pretty much it.
What I would suggest, to get better community feedback perhaps make another ‘walkthrough’ / tutorial video much like this one :
No doubt you’ve seen this video come up in community discussions before. In my opinion it’s so good because unlike most other videos on anytype it doesnt show you a final state, it organically walks you throw a workflow / process to get there, in a way where it makes it click for you, how you could use anytype for your own needs.
I understand that this feature is not ready yet, but if a functional prototype could be created to help walk users through a ‘realistic’ example of how to leverage the new features it would be really helpful.
Case in point, the ‘base’ feature walkthrough clicked for me. I have something analogous to it myself. An inbox where i put things i dont know / bother to organize better
This is why we have to learn from usage. There’s a world where we can package all of it into the (smart) collections system. As you can see from this discussion, the difference between these functions are nuanced and possibly don’t need to be heavily distinguished by different systems/names. The ability to create query (like it is today) will always be there, it’s just a matter of the user experience design around it.
Indeed, we want to minimise any disruption to existing systems that users have set up. I don’t see a scenario where we’d convert all ‘property tags’ into ‘collections’ by default, as that’d create a huge disruption.
This is speaks to some of the ‘mental model confusion’ referenced earlier. If you have excluded A, B, and C objects from appearing in a (smart) collection, will you remember why you did that in the future? Will other users in the space notice or understand the exclusion decisions? Or will they likely just think the system is bugged and missed out querying those excluded objects?
There are ways to solve this (like a list of exclusion/inclusions accessible somewhere), but there is a mental gap to be filled between one user’s decisions and another’s (in the context of collaboration).
Indeed, this would make collections significantly more smart and useful. As @C.c has pointed out, we already have advanced filters. But it could make those specific to each query rather than as a separate advanced filter, because it’d logically make more sense to the user when setting it up.
There is no plan to remove the functionality of queries.
Absolutely, this is the default actually. All collections are effectively a ‘manually-added objects’ until you add smart functionality.
Like with all things, the default name only matters as far that it gives new users a better orientation to learn how things work. ‘Inbox’ is indeed a decent name, but it feels very individual driven. In a shared team space, this may make much less sense. ‘Triage’ is technically maybe the best name, but not the friendliest name.
Yes, our goal is to make the process of adding/removing collections as fast and simple as possible.
I think this would likely add a layer of complexity with minimal benefit. The object titles themselves also form important anchors for search, in-line block links, properties, etc. Having the name be different even though it’s the same object can create a lot of confusion—especially for team spaces.
It’s a user decision. What scenarios do you foresee where it could be retrieved/calculated?
All collections in a ‘nested collection’ series are separate. Likely, we’d implement the ability for a parent collection to include all objects from child collections, but that’d be a user decision. The default would but that objects only appear in the child collection, and won’t show up in the parents.
In that sense, grouping is more of a separate issue to work on. Since all child collection have the properties from the parent collections, grouping would still work based on the same set of properties.
That would be a little complicated, haha.
Thanks for your thoughts. At the moment, we are in the stage of collecting feedback before we go into development. By creating a functional prototype, we will have invested a lot more into ideas that may not be what the community wants. Thus, this is about getting feedback earlier in the process to inform development. The video you referenced is great, but it’s better suited after you’ve actually built it. Feel free to continue following Collections 2.0 in the future when it’s at a stage more clear for what you’re looking for.
I think excluded Objects should appear in the list of filters for the View.
On top of that list appear the general, automatic filters, followed by the filters for individual Objects.
The filter list should show the Object’s title, while hovering the mouse over it should show a tool tip with additional information, like the unique individual Object identifier (to distinguish between Objects with identical titles).
Ideal would be (and I strongly wish the same also for the global search!) if the user could chose what additional information show up there.
For example Tags, a certain date Relation, the description, etc.
While using the global search I have often to deal with Objects that have the same title. To distinguish between them, I need some additional information.
The user should be able to chose which information he gets presented to distinguish between the Objects.
If search finally get this missed feature, the filter list for individual excluded Objects could easyly work the same.
Honestly, my heart skipped a beat when I saw this prototype: it’s everything I’ve always wanted for Anytype.
Quick feedback:
- The approach where “an object can belong to multiple collections and have different properties depending on the context” is absolutely brilliant. The option to show or hide links on the graph is definitely needed.
- Subcollections are necessary. Typically, to manage people who can be friends, colleagues, guests, etc., with specific properties for each sub-category.
- Tags seem redundant to me now; I mainly use them for Queries, so replacing Tags with Collections seems more natural.
- The all-in-one approach with auto-collect seems promising to me: it finally merges the concepts of Query and Collection (current name). Perhaps one option would be to add a small icon next to each item to indicate whether it was added manually ( ) or automatically ( )
Well done and thank you for this superb work in progress, and for this high-quality communication.
Thanks for the video and the prototype Kaye, this is looking good
In the smart collections examples, there’s a lightning button for the auto collect feature. It’s present in the “traditional query” and the “auto collect” examples, but in the “collect once” example there’s a 4 arrows button. Why is that?
It was my understanding that with Collections 2.0 we wouldn’t have separate types for collections and smart collections. Instead, we’d only have “collections”, and the difference would only be turning the smart features on/off. In other words, I expected the lightning button to be present in all collections. Did I get the new system wrong? Or is it just a prototype issue?
Can you elaborate a little further on why you have many objects with the same name and what would you want to distinguish between them? In my mind, the primary collection as a default should distinguish them enough but maybe that wouldn’t work in your setup?
Yes, we’d need to figure out a good system for inclusions/exclusions for auto-collect. Icons and tooltips are helpful on desktop, but a little harder on mobile. Thanks for your feedback.
You’re very astute. As mentioned, we’re currently unsure which approach to ‘smart collections’ is the best one, hence why there are multiple branches in the prototype (collect once vs. auto collect). The difference in UI is not final, it was simply meant to give an impression to the community of how each type of feature could work so (feedback could be given).
Seeing the community feedback so far, it seems like auto-collect and traditional queries are highly valued (with collect once effectively becoming redundant). It’s likely that we’ll try to design both of these features into the same ‘smart collection’ system so it’s easy to understand and use.
Question: do you like the name Collections & Smart Collections?
It’s been a few months since we first officially opened the conversation on renaming types/lists into collections (seen here and here). Now that we’ve also outlined the new architecture and shared a prototype, how do people feel about the name? Does changing ‘types’ to ‘collections’ and ‘queries’ to ‘smart collections’ feel like a step forward to making the system easier to understand?
First example:
I still have 126 images with the name (title) “image”.
This was the standard name that older Anytype versions automatically gave to each image that came from the clipboard.
Second example:
I have a “database” about mushrooms. Many look similar, I don’t know them all, that’s why I use Anytype.
And because I don’t know them all in every aspects, I often end up with duplicates.
There are many channels about mushrooms on YouTube. The creators introduce often 5-10 different mushrooms in one video. I then make an entry in Anytype about each of them.
Let’s assume there is a “Ganoderma applanatum” and a “Boletus reticularus” and a “Tremella” and “Trametes versicolor” among three other mushrooms in a video. I create an Object for each of them.
Three months later I watch another video, from another creator, about seven other mushrooms, but there is also again a “Bloetus reticulanus” among them.
– Do you believe I remember that I already have an Object about this mushroom?
I don’t remember! And so I end up with a duplicate.
This happens often to me. Third example:
In my health study Space, I’ve had accidentally created three or four Objects about “Vitamin D”.
And it can easily happen that there are two Objects “Rhinophym”, or “Giandula lacrimalis”, or (if the title is in German) “Systemische Sklerose” etc.
Further examples:
In my Collection for Maths tuition for school pupils are lots of Objects like “Geometric riddle with triangles”. Or “Quadratic equation”
.
And in my Collection for knots are some Objects with the identical name “Trucker’s Hitch” as well as the similar sounding “Truckie’s Hitch”, as well as some Objects about the at least 6-7 different variations of the “Mofified Trucker’s Hitch”.
And in my Collection for music with many hundred Objects, are alone over 100 songs from my beloved singer Howard Carpendale. From some songs exist different versions, but the version is not always clear. I have for example eight(!) times the title “Nachts, wenn alles schläft” in different or maybe different versions!
It’s impossible to distinguish Objects only based on the name.
It’s a pain to use the global search because it doesn’t show the relevant additional information to distinguish between Objects.
For my principle to store data, I highly relay on the Description, as well as on the Tags.
And in same cases, even all this together isn’t enough, so that I also need to see the Relation “YouTube-Channel”, or sometimes my own date Relation “Datum”, because it helps me to distinguish between very old entries and newer information.
And to be clear:
Off course, the View in a Collection, or a Query, doesn’t have this problem!
But the global search has it.
And if the filter for Views gets the feature to exclude single Objects, it will have the same problem as the global search, if it shows only the Object’s name and/or maybe the cryptic Object identifier.
It would be such an enormous and obvious benefit if (for example) the global search would finally show more relevant information about the Objects in the list of results (at least while hovering the mouse above the name) that I don’t get it why such an easy to implement and indispensable function still not existes?
Understood. This is a related issue that affects Collections 2.0 but really is its own thing—search results and its identifiers. Indeed, much room for improvement here. While having description, date created/modified, tags, etc. alongside the search results can help, it wouldn’t necessarily solve the other challenges you’ve brought up. As an example, we have hundreds of ‘screenshot’ titled objects/images in our search results, and no additional identifier would really help us sort through them. Let’s break that topic out separately from Collections 2.0 — I agree that it would impact the inclusions/exclusions objects display but this issue should be resolved regardless.
As you see, most of these images are at least tagged.
And each of them (*) have a different “Added Date”.
(*) Ahem, not really “each of them”, because there was a time when Anytype has messed up “Added Date”, as well as “Creation Date”.
Furthermore, these dates are generally not reliable, because after exporting and re-importing a Space, these dates are also shreddered and replaced with the date of the import (a scandal in my opinion, btw.!).
Because of that, I normally use my own date Relation “Datum”. But not all of my older images don’t have it.
Edit:
Also the backlinks are different, although not shown in the screenshot.
The backlinks give even more valuable information then the other Relations that my screenshot shows.
I hear you that adding these other data points will help you with identifying objects—and we should work on that.
I’m simply adding the point that this isn’t a comprehensive solution for the greater issue (space bloat) which happens in larger spaces with many users. As an example in our own team space, we have hundreds of ‘image/screenshot’ objects without relevant tags (nobody is going to spend time to tag them, because it’d also require many different people to do so). Also information like date creation/modified wouldn’t provide much value either. In general, there’s a lot of work to be done to mitigate this bloat issue caused by multiple users and poor naming/tagging of objects.
Anyway, I digress. Let’s tackle that in a separate topic because there’s a lot to unpack.
Oh no!!! Not at all!
It makes everything way more confusing, if you ask me.
Especially you shouldn’t redefine existing names. It brings obviously pure chaos in this forum.
There are still users here that use the old term “Set” instead of “Query”.
– That’s not dramatic. But it would be dramatic if a Query now becomes a “Smart Collection” while the old Collection suddenly no longer exists and, instead, Types are suddenly called “Collections”!
Really, the idea is (very, very diplomatically formulated!) “wired”.
I’ve said it often and I repeat it: use UNIQUE names!
Whatever you do, I urge you to use names that are impossible to confuse with something else!
I was fighting like a lion against “List”, because it can be confused in many ways and that makes it very hard to ask for help or giving help.
If some of us recommends Anytype to a friend or college, it’s in my experience already more then hard enough to find excuses for the many flaws and hard to grasp concepts.
But if even the forum fails if he tries on his own to find help, then good night!
I couldn’t agree more. UNIQUE names are extremely helpful, whether for existing or new users. Existing users get confused because they mentally associate the terms with something else, and it takes a while to rewire those associations. With new users, things are much easier to explain.
Let’s take Microsoft as a negative example:
In Microsoft Teams—commonly referred to as “Teams”—“Teams” are created and managed within “Teams”… how on earth am I supposed to explain that to a user in a way they’ll understand…
And Microsoft seems to have an almost compulsive tendency toward double naming.
It’s so incredibly confusing. Please don’t do that!
For images, having a larger thumbnail (and an even larger preview when you hover over it) would be extremely helpful!
I’ve mentioned this before, at least regarding adding existing images (especially when there are hundreds of images with meaningless filenames… it’s hard to find the one you want with just a few pixels of visibility).
For example, in search results, Notion displays the location and modification date, as well as a preview.
I think there’s room for improvement here compared to Notion’s solution, but the fact is that we have the information to help find the desired item.
I’d like to extend this feature to all links to Anytype items:
search (to make it easier to find the right item)
/image, /link, etc., for the same reason
AND links within a Card-format item (because, yes, having useful information rather than just the name—which is sometimes generic—would be very, very helpful)
Like this FR : Show featured relations in card
This is amazing! Regarding the idea of merging tags and collections, I think a Tagged Collection can be the solution. Then we will have Traditional Queries, Collect Once, Auto Collections, Tagged Collections. The tagged collection should have a different layout than others, like roam research tag showing all the tagged objects. In future we can also use this layout/view to see tagged blocks (A block which is tagged after the sentence for example).
Similarly this approach can also be used to see links/backlinks of the object in an ephemeral collection view, maybe via a button on top right of the window.
In a single notebook/journal, we can have different sections for different purposes: dated pages, project planning (structured, like queried); undated / blank pages (purposes to be specified upon the date / allocation).
) or automatically (
)
