Collections 2.0 Prototype—feedback is welcome

News
,
158

In philosophy, there’s a school of thought called essentialism, which I believe you’re effective subscribing more heavily to. You believe a book has a set of properties that are more essential to its definition than other properties. While Collections 2.0 allows for this perspective to exist, it additionally allows for other perspectives to exist—which is that certain properties matter more to me in certain scenarios (context).

To stretch this even further, it’s really just a matter of subjective preference for your mental model. I’m certain many people would argue for file+folder tree hierarchies as being ‘the way’. While many of us here feel that object-based networks are much more intuitive. You believe that all Objects only have one Type. Others believe that objects depend on context.

Think about it from first principles. Ignore semantics. Don’t think about Types, Queries, Tags, and Collections—just think about what is happening. I’ve explained it above so I don’t want to beat a dead horse, but I can answer your proposal directly: “let Queries combine rules with manual membership.” In this case, what is the difference between a Query and Collection?

  • Container A: has objects only based on rules membership. query
  • Container B: has objects only based on manual membership. collection
  • Container C: has objects based on both rules + manual membership. auto-collect

In the current system, we have A and B. By your argument of not ‘merging things’, we can call C another name. But why? Why even bother having three names at all. This seems more of an exercise in semantics than the goal of the product: to group objects together based on our mental model—not technical implementation. That’s why we just call them all Collections—you decide what should be in there, it doesn’t really matter how.

A key point: merging things does not mean you lose any functionality. Everything exists, it’s just a matter of the experience designed around it. If you only want a rules based query with no manual membership, you can.

I see it as being the other way around. Basic users will only use one collection on the majority of their objects. It is power users that will really use multiple collections, nested collections, etc. The latter is more complex, which is why it won’t be the default. Simple is typically the default, which is one collection.

As mentioned in the other post, the bigger benefit is that this new system gives higher flexibility and reduces system lock-in. You can evolve/transition your system more easily when you’re not constrained by one type.

I don’t understand. You can create a collection called ‘note’, set it as your default, and then every object you create on the fly will just go straight into that collection. It is exactly the same as it is today. I think you may be thinking that the new system is dramatically different from how you operate today. It isn’t.

You can always choose the version of Anytype you like and never upgrade. However, in the long term, you’re better off finding a better product that suits your needs.

Thanks for your questions and input. :slight_smile:

It is clearer, but certainly not something that’s in scope for Collections 2.0 haha. Tangentially speaking, it is architecturally interesting from an AI agent perspective of mapping decision flows and surfacing outcomes.

159

Am I missing something important? I feel like the new approach is still essentially (Multi-Types | Types) + Properties + Queries + Collections, so I don’t quite understand how the “Organization happens before creation” issue is being resolved.

The pressure of “design failure” might be mitigated, but it seems this is only because supporting multi-types allows us to create types in smaller units. While the burden of managing an individual type decreases, there is a potential risk that the overall structure becomes more complex due to an over-proliferation of types. It feels like a trade-off.

Eventually, we might even need rules just to manage these types. For example, if product categories in a shop keep growing, the “Products” type might split into “Book/Products,” “Cloth/Products,” etc., increasing overall complexity. When you realize the problem and try to redesign the entire structure, having so many granular types could actually become a bigger burden.

While the new system might make adding types as easy as on Instagram, the task of defining those types and filling in property values remains the same. I worry that this sacrifices the system’s structural backbone to support expanded features. I’m not sure about flexibility, but simplicity seems to actually decrease. It might look simple at first, but it may not be the case in the end. I personally think it might be a better direction to address flexibility and simplicity through an innovatively fluid UI/UX.

160

CONTEXT would be a good name to use in place of 'COLLECTIONS?

161

I believe I’ve exhausted my ability to explain in text the benefits and differences. More words won’t add much more at this point. :laughing:

If we observe the conversations from the architecture thread to this thread, I see that tangible experiences help to bring people along the journey. At some point, we just need to get people to use the new system/product. I don’t think everybody will like the new system. But as we’ve mentioned, since there is no functionality loss, and the community is largely positive, we’ve mostly addressed our internal concerns.

That’s an interesting option, I didn’t even think of that at all. Lol.

162

Hey, this is indeed a good idea!
This suggestion brings two similar ideas into my mind:

  1. Topic
  2. Theme

As a non native English speaker I’m not sure what’s the best option.
But in any case, I would modify the therm a little to make it unique so that the search function in the forum doesn’t deliver irrelevant results.

Therefore I suggest “Themebox”?
Or, maybe even better: “ThemeSet”?
These two suggestions sound a bit more fluid on the tongue then “Contextbox”.

163

This is my favorite idea yet. It makes so much sense!

164

Actually, both words are fine. They’re just different perspectives on the libraries, that link to their respective objects.

In the end, it’s just a question which perspective you want to emphasize.

Actually, I like perspectives a lot, too. Since it describes the different views on the very same object.

165

You must admit that Books is a PRIMARY collection for a book. Other collections you mentioned are secondary.

And a primary collection in Anytype can be a Type.

I think you all are overthinking this. Types and Collections can co-exist together in Anytype.

166

Sorry I’m late to this discussion, and apologies if this was already answered and I missed it.

I like the overall design of Collections 2.0, especially the concept of assigning multiple types (and their associated properties) to an object. However, I have a specific workflow that I want to make sure will still be possible.

Say I have object A with properties 1, 2, 3, and object B with properties 4, 5, 6. Right now I can put both objects in a collection, set it to list view, and connect properties 1-6 - then I’m able to see all the respective properties of each object.

Using your examples, maybe I want to add a book and a movie to a Dune collection. But I want the collection to appear as a list where I can still see the author, publisher, pages, etc. for the book and the director, producer, runtime, etc. for the movie. Can I do that in Collections 2.0?

167

I’m pretty sure that flow should be unaffected. This seems to pertain mostly the information an object can hold, not a collection’s representation.

On the primary type matter, I understand the angle: A book is a book. True, of course, but depending on the context either a superclass or a subclass might be more relevant to a case. For example, the book object could be more useful seen as a source, a resource, a print, a manual, a guide, etc.

Some objects will not have as clear-cut “primary” types. For example, an apple is an apple, of course, but it can also be a food or an ingredient, with no clear primary type for some people. You would likely not have an apple type because an apple collection would be pointless.

I guess it boils down to flexibility. A user who considers an apple to be primarily an ingredient can work within the system that allows for multiple equally-valuable types, a user who considers it both things equally cannot work without extra redundancy (duplication) within a system that enforces a primary type.

168

Yes, in case of a book, one can say that it is primary a book.
But it’s not always clear.
For example, in which Collection does my cousin belong?

  • As my cousin, he’s my family member.
    – Therefore he would belong into a Collection for family members.
  • But he’s also my customer, sometimes I repair things for him and write invoices afterwards.
    – Therefore he must appear in my Collection for customers.
  • And He’s also my supplier. Sometimes he delivers me spare parts.
    – He belongs into my Collection for Suppliers.
  • And let’s assume he and myself are in the same sport club.
    – Therefore he belongs also in a Collection for sport buddies.

Which Collection is “primary” in your opinion?
In principle, I could use only one Collection aka Type and configure different Views with different filters.
But if I open the Object I need to see different kind of data, depending of the context.
In the context “sport buddy” I don’t need and don’t want to see the delivery address that I need if he’s my customer.
And if I look for him as my customer, I don’t need to see his birthday, nor the links to his wife and child.

169

Contact? Or people?

170

If the conversation has landed on the need for some people to have a ‘feature name’ for the main defining collection an object is in (be it ‘Type’ or ‘primary collection’), I think we’re in a good place. I don’t want to exhaust this point because it has been discussed multiple times in the thread already, but the key points are:

  • You can only use one collection if you want, effectively making it a type.
  • You can change the primary collection if you want, effectively making type selection possible.
  • You can use multiple collections and not care which is the primary, ignoring the need for types.

Everybody should be happy. :slight_smile: Nobody needs to enforce how you interpret your own system.

What I will emphasise is that this conversation is about single types is very flat. We’re discussing a ‘book’ object, which really doesn’t change much—it doesn’t span across collaborative or time dimensions. Think about discussions in a company, research notes for a multi-year study, content creation team workflows, management of film production, etc. These can all have much more complex contexts that change over time as circumstances change.

If your system doesn’t require taking into account these dimensions—just use one collection. It’ll be exactly the same as the way you use Types today.

171

Seconding the existing use of collections as a folder system, which at the moment can be deeply nested. Would not want to see the ability retired.
What’s great about its structure at the moment is that it’s rootless, so I can have an object nested in several file trees to match my mental model in searching for it at the time. As long as new collections can have branched nesting collections as children, as is currently supported, no issues!

Edit:
Come to think of it, curious how this would actually solve the inheritance problem of types, similar to Tana’s Supertags. What’s beneficial about those is that if I, under this new system, have two types (person, and friend which is a subset of person), I need only assign “friend” to Jeremy Smith if I want him to inherit the attributes of both person and friend. Should it be expected that the nested collections work similarly?

172

@kaye Please. Just name it Types. You may add: Composable Types. That’s it, two words and all is said.

In my perception, “Collections 2.0” feels like a sectarian word creation that disregards years of well-known type theory.

A part from this, it might still make sense to have one-off collections. It might make sense to extend Queries with such a one-to-many relational bucket and rename them to Collections to shave off one relational concept.

Don’t mix Types and Collections(Queries+Item Bucket). Please :slight_smile:

And if you really want to develop a “great unifying relational theory”, you can take it from there, step by step.

173

I misspoke:

  • Collection is a good user-facing name for a “Type Composition Bucket”

Furthermore:

  • I want such Collections the target of Object field restrictions (probably in addition to raw types)

Inlined Smart Collections instances:

  • should not exhibit collect and autocollect features to avoid side effects
  • need instance-level filter which operate in addition (AND) to each per-view filter.
  • should populate the Created in Context field from the current (surrounding) object
  • [Created in Context = This Object] then should be the system default for instance-level filter
  • should be resolved on the API as an object of arrays keyed by the instance view’s internal name
  • have a view-config and that config should be coercible from a template to all it’s template instances (if they retain an inlined instance of the smart collection), e.g. “Template > Inline Collection > View Config > Make this the view config for all instances of this template”
  • likewise, individually: “Adopt view config from template”
  • should not waste height estate, if there’s only one single view (“All”) → collapse to a title pill
174

Hi @kaye!

TL;DR: I’m a dumdum. One of those people that keeps trying to use AnyType and fails repeatedly. Would like to participate in the “how to name things to make them easier to understand”-discussion, but cannot due to my dumdum-ness.

Longer version:

I used to be an avid Notion user, until I got privacy-conscious. I discovered Anytype very early on, attended a zoom onboarding. I think during Covid times?

Since then, I’ve really tried to get into Anytype. Over the years, i’ve tried multiple times. But I kept getting stuck on having to think what “object” I needed. What a set was. What a collection was. I felt like I needed to be a programmer to understand it. I just wanted to make a page and get writing/designing, not having to think about what the page meant in the whole structure. It was overwhelming, and I felt very dumb.

This week, I realized I had a use case (university notes) that Anytype would be perfect for. So I came back again. I watched that video by PianoMacPower, and for the very first time, it clicked. The only thing I was confused by was that sets and lists weren’t mentioned (because I remembered getting stuck on them), but I finally understood how I could use Anytype for my use case and how to organize the objects and collections (still annoyed that I couldn’t just call anything a page, but still).

I might be a dumdum, but I also am a software enthusiast, so I watched your latest community town hall.

First, I was so happy to hear about the inbox. Finally, not getting stuck making decisions about structure before I even start. (Btw, if you rename this to something non-descript like “base”, I’m going to scream).

But then. Collections 2.0. Everything that I had been trying to understand for the last hours, days, even years. Completely overhauled.

No biggie, it will be easier. Right?

I have watched the whole community town hall and have read a lot of this thread. And I still don’t understand it. And the discussions of how to name things are VERY interesting. There are people here that use Anytype in a way us Notion Normies really can’t follow.

All of this to say, I feel like a dumdum like me COULD have valuable input, explaining how I (don’t) understand things and why I kept trying and then moving away from Anytype, again and again.

But I don’t even know where I can give that input, since I can barely understand the discussions here. I can’t give meaningful replies to people here, and I can’t suggest names since I still don’t understand what the things discussed actually do.

Is there any way dummies like me could give input as well? I feel like the naming and categorizing is what turns people like me off, and I really want to use AnyType and see it succeed.

Thanks for all the effort <3

175

I’m another late-to-the-party user, but this type of capability is exactly what I’ve hoped for since migrating here from Tana. I’ve read many of the comments and feedback, and I think people can adapt and understand this structural change readily. There may be a few who can’t initially, but the continuing educational process will assuage their concerns in a relatively short time. And I agree with @Code-Jack and others: Smart Collections and Auto-Collect will be powerful, and I’d likely use this most often, if not all the time (but here, you have the option to choose either avenue).

The real value I see is the perspective that most everything I do in life is either defined or influenced by my relationship to that person/place/thing/thought. And that’s exactly how I see this evolution of Collections into Smart Collections. The nesting/parent-child definitions of data elements is simply a relationship between such elements, so that makes sense to me. I’m really looking forward to this iteration of Anytype.