You can set up properties like “is part of.: ..” or "∈: … " or"module of:… " and then set up a filter and sort them in a view of a collection or query.
This is how I do it, btw.
And as Property I use an additional Multiselect-Property (tag).
ALL my Objects have a general Mulstiselect for the first level of data organisation.
For example, my music gets the Tag “Music”.
But my music Objects have two additional Multiselect Properties that other Objects don’t have:
- Artist
- Genre
This way, I can for example filter my music for “Kraftwerk” in the Property “Artist”.
But if I want to see all music in the Gerne “Electronic”, no matter which artist, I can also do it by using a filter for the genre.
It works. But it is not optimal, honestly.
It would be much better if there would be only the general Multiselect that can do everything, without having thousands of Tags in the list. – I need the possibility to “tag the Tags”.
I mean multidimensional, oi nested Tags.
As I understand all the discussion about the new concept around Tags and Collections 2.0, the team already works on such a solution (maybe an even much better solution then I can imagine) and it will come soon.
Btw, the complexity must be immense!
There must exist solide functions for reorganizing such things as nested Tags etc.
That’s really not trivial! – Indeed, it’s horribly complex!
Yes, one could say it is a completely new and much higher level of complexity then everything we have today.
Even without collaboration and syncing etc., must it be the pure horror to program such stuff.
Years ago, I’ve programmed an inventory management system for supermarkets. I would say it was on eye-level with Anytype as it was two years ago (in some aspects further, in other aspects less advanced).
But it clearly didn’t reach the level that Anytype soon will have when the new features come!
This multidimensional and nested stuff, that’s also flexible all the time in reorganisation of the data, causes lots of Gordian knots in the brain, I can tell from own experience!
It’s somehow like the Theory of Relativity: you simply don’t have a fixed point anywhere.
And imagine you get a power loss on your PC during the reorganisation of the data structure, just while the syncing still runs and that just while someone else collaborates on your space …
I have the utmost respect for the developers if they manage to pull this off!
Tags as Nested Collections
As shared in the recent Town Hall, I added a short clip to the first post on how tags could be adapted with nested collections in the new system. As mentioned, you can use tags as a property (like today) in Collections 2.0 without the need to change anything. However, I believe for those who would like more organisational power with their tags, using nested collections (and hiding collections display) would be an alternative approach.
Breadcrumbs & Flow
I agree with both of you, @Shampra and @Code-Jack. Improving the navigation between linked objects would be hugely beneficial to all users of Anytype, especially to those who are coming from apps with tree hierarchy structures and breadcrumbs (99% of people). At the same time, it’s actually incredibly difficult to do well because there is no inherent start or end point to the navigation—which is difficult to create convenient UI for. While it’s unlikely that an object-based navigation system would ever as convenient/simple as folder trees and breadcrumbs, I do think there is notable room for improvement.
One idea I had was to allow users to define ‘priority links’ between objects. When there are priority links set on an object, the system can render a faux breadcrumb structure on the UI that makes it easier for the user to navigate. There are many issues with this though. One, it’s cumbersome. Two, it requires manual setup. Three, it’d only be used by power users. Four, it’d not scale naturally in a space with evolving complexity (since it’s manual).
Another idea is that nested collections could simulate this type of navigation. What’s problematic is whether or not it makes sense to enable branches and infinite depth for nested collections. This could create all sorts of other issues.
All that being said, we could try to simply improve the UX and ease of use of the current flow implementation and not rework the underlying structure. That’s an easy win. Alas, too many ideas, too many bugs, and too little time. 
I apologize if a similar proposal has already been made in the past.
Since queries act essentially as concepts like Smart Collections or Dynamic Collections, I would like to propose changing the concept of the currently-in-development “Collection 2.0” to an “Object Collection”.
Looking at the development intentions, I understand that Collection 2.0 is being built because a single document can simultaneously have multiple types (properties), even if its core essence (the body text) remains the same. While I understand this reasoning, I don’t think it’s entirely intuitive. As soon as I read the explanation, my first thought was: “Why assume the body text is fixed?”
It is highly likely that the body text contains descriptions specifically related to the added types. If a type is later removed but the related description remains in the body, it could easily turn into an awkward, disjointed document.
The “Object Collection” I am proposing looks very similar to the current form but has a fundamental difference in its core concept.
For comparison, here is the approximate structure of the current Collection 2.0:
<title>
#type1 #type2 #type3 ...
<body>
To help explain, I will apply the “Person Example” to the body text and add some sample content:
Tom
#peer #nuclear_family #family_of_origin
<H1> Personal Information (#peer)
...
<H1> Info about nuclear_family (#nuclear_family)
...
<H1> nuclear_family Timeline/History (#nuclear_family)
...
<H1> Info about family_of_origin (#family_of_origin)
...
<H1> family_of_origin Timeline/History (#family_of_origin)
...
The content grouped under each H1 is closely related to the type noted in the parentheses. In this scenario, if only the type tag is deleted while the body text is retained, the document loses its context. Conversely, adding a new type without adding sufficient description to the body could also be awkward. (Of course, an object might only consist of properties without a body, so it’s not always awkward, but it often will be).
Furthermore, timelines or histories usually contain a substantial amount of information even when written as independent documents. A single document trying to handle multiple massive timelines like this would be a nightmare to navigate.
This is the “Object Collection” I am proposing:
First, three separate documents representing different types must be created in advance:
Tom
type: peer
<H1> Personal Information (#peer)
...
-------------------
Tom
type: nuclear_family
<H1> Info about nuclear_family (#nuclear_family)
...
<H1> nuclear_family Timeline/History (#nuclear_family)
...
-------------------
Tom
type: family_of_origin
<H1> Info about family_of_origin (#family_of_origin)
...
<H1> family_of_origin Timeline/History (#family_of_origin)
...
In this state, if you create a new “Tom” object using the Object Collection type and add the three types (#peer, #nuclear_family, #family_of_origin), it generates the exact same view as the Collection 2.0 example above.
Because an Object Collection is simply a view that aggregates multiple separate documents into a single document interface, I believe the implementation would be much simpler. Also, the displayed content is dictated by the order of the types. Changing the order of the tags changes the order of the body content, like this:
Tom
#peer #family_of_origin #nuclear_family
<H1> Personal Information (#peer)
...
<H1> Info about family_of_origin (#family_of_origin)
...
<H1> family_of_origin Timeline/History (#family_of_origin)
...
<H1> Info about nuclear_family (#nuclear_family)
...
<H1> nuclear_family Timeline/History (#nuclear_family)
...
I believe this approach would also result in a much more natural and logical structure within the Graph View.
With a well-refined UI/UX, we could realize the philosophy of atomic notes simply by writing directly within the Object Collection view. Let me give you an example of the workflow:
- Create a ‘Tom’ document of the Object Collection type.
- Add an existing type. (Let’s assume the ‘peer’ type is added).
- The basic components of that type are automatically added to the body. If you write content in that section, it is actually saved to the ‘Tom’ document of the ‘peer’ type.
- Add and name a new type (e.g., ‘nuclear_family’). Setting up its properties defines the new type. In the background, a ‘Tom’ document of the ‘nuclear_family’ type is also created.
- Write a rough structure using H1 tags within the Object Collection view, and assign it to the new type via a right-click menu. This defines the format for the ‘nuclear_family’ type.
- Now, just like in step 3, if you add content to that section, it is seamlessly saved to the ‘Tom’ document of the ‘nuclear_family’ type.
Additional Suggestion: Hiding Types
I also propose improving the current feature that hides types. By toggling the type name, users should be able to cycle through 4 visibility states:
- Show both Properties and Body
- Hide both Properties and Body
- Show Properties, Hide Body
- Hide Properties, Show Body
Thank you for reading my feedback!
Thanks for taking the time to write/share your idea in such depth. I’m curious to hear the community’s response on how helpful/desired this solution is.
For me, I would simply keep information that’s specific to the type in a property—thus, if that type/collection gets removed, so does the content. While I see your solution is additive to the system in place (doesn’t have a direct tradeoff for the most part), I see it as having a lot of complexity without necessarily having a lot of benefit. This certainly sounds like a feature that only power-users (even on the extreme end) would be utilising. But I could be wrong.
If I understand it correctly (big IF), it has a big advantage and feature: it would allow to add properties and links to a specific object:
- link directly to Tom (family_of_origin)
- Add a custom property in Tom (nuclear_family)
- Add Tom (peer) to a custom “smart collection/query”
It would kinda be a pretty good workaround for “linking to blocks” instead of whole objects and could be great for transclusion (on another object, embed Tom (peer) but not Tom (family_of_origin) and (nuclear_family))
Definitely interesting! (if I understand it correctly)
@kaye
First, as I am not a native English speaker, I am using Gemini to translate and communicate. Please note that there might be misunderstandings due to mistranslations. While I don’t know how the actual implementation would turn out, I thought my proposal was quite easy and intuitive from a user’s perspective. However, since you don’t seem to feel the same way, I was worried that my points might have been conveyed incorrectly. If there is anything you don’t understand, please feel free to ask me for further details.
The advantage of the method I proposed is that we can avoid the existing (and in my opinion, unintuitive) approach where multiple types are assigned to a single object, while securing immense flexibility in an intuitive way. Documents can maintain the consistency of having only one type, just as they do now.
This approach is much simpler than the current one. The core of this idea is that it is simply a ‘View’ that allows you to collect and see multiple documents on the same topic all at once. Because I believe this method is easier than the current system, I find it hard to understand why it seems like a feature only for power users. I would like to know what part made you feel that way.
In particular, I’m not sure what you meant by keeping information in a property. My idea is a structure that controls not only properties but also the body text (I’m not sure if this translates well)—which contains document content that is not suitable for storing in a property. What you can write in a property doesn’t have much to do with this idea. The content you can write in properties works identically in both the existing method and my proposed method.
It would kinda be a pretty good workaround for “linking to blocks” instead of whole objects and could be great for transclusion (on another object, embed Tom (peer) but not Tom (family_of_origin) and (nuclear_family))
This is exactly what I intended!
- link directly to Tom (family_of_origin)
- Add a custom property in Tom (nuclear_family)
- Add Tom (peer) to a custom “smart collection/query”
These would be excellent use cases as well. Depending on the implementation, it might also be possible to add separate body text, additional properties, or links directly within the Tom (object collection) itself. Personally, I hope it turns out that way.
To help clarify, let me provide a new example. I’ll use the ‘Children of Dune’ example from the video.
Currently, the document seems to only have properties related to the ‘online shop,’ while the body text only contains information about the Book itself. In this state, if a shop manager wants to add sales-related details, relying purely on properties is insufficient.
You could force things like monthly sales volume into properties, but as these accumulate, the number of properties would grow excessively, which doesn’t seem appropriate. Also, how would you describe a specific event like, “Influencer X mentioned this on Instagram,” in a property? Should we tweak the property structure just for one special case like this? Personally, I would want to write that kind of detail in the body text.
However, if these kinds of descriptions keep accumulating, eventually the body text will contain far more shop-related information than content about the book itself. If this happens, is it time to separate the notes? Since there are likely many different books in the workspace, if only this specific document is split, it would break consistency.
A novice shop manager looking at this might misunderstand and think, “Why is sales information missing for this book?” or (if the type was completely separated) “Is this book not sold in our shop?”. Because the document structure is inconsistent, it would be hard for them to guess that the online shop-related content for this specific book was separated into another note. You could patch this up using links, but that’s just a clumsy workaround.
My proposed method covers this scenario perfectly.
As long as users understand the concept that an ‘Object Collection’ is simply an aggregation of documents, they will naturally know that a separate document for the ‘online shop’ exists. When descriptions for each type become lengthy, instead of being overwhelmed by endless scrolling and straining to find the specific section you want, you can simply think, “This document is too long; I only want to read about this specific type,” and open just that individual document. Conversely, when there isn’t much content, you still have the advantage of viewing all the types’ contents together in one combined document view.
I hope this scenario provides a clearer explanation of my proposal.
If we restrict all type-specific information to just properties, we are treating Anytype like a simple spreadsheet, losing the immense value of a block-based rich text editor.
While we’re rethinking the UI for Collections 2.0, could we also look at improving the Sync Status indicator?
Currently, when in local-only mode, the ‘crossed-out globe’ feels very ‘disconnected.’ It would be great if the new UI included a small visual pulse or icon to confirm when local P2P sync is active between devices. It would give a lot of peace of mind to those of us moving away from the cloud nodes!
I’ve made a more detailed post about it here: Indicator for P2P sync
I understand that maintaining a single type is still technically possible in the new system. However, my point is not about technical feasibility, but rather about how Collection 2.0 will be perceived and adopted by the general user base.
When a product introduces additional features, most users naturally assume that it is the “better” or “recommended” way to use it. In such an environment, assigning multiple types to a single document is likely to become the default behavior for average users. Consequently, maintaining a “single type per object” workflow will be confined to a small minority of power users who already have a firm, established methodology for data management.
This leads to a fundamental question: Is allowing multi-types truly a better methodology? My feedback is that it might not be. While it may seem like “supporting more features,” I believe this approach treats edge cases as core logic, which can result in unnecessary architectural complexity.
Personally, I believe a system that provides high scalability through a few, strict rules is superior. Instead of adding layers like multi-types to handle exceptions, it is generally better to keep the core structure simple and intuitive—similar to Object-Oriented Programming (OOP)—and let scalability emerge from that clarity.
The “Object Collection” I proposed offers more versatility with a much simpler structure. Even with this approach, it is very easy to configure a setup where a document appears to have multiple types. In other words, I believe it is structurally superior (upper compatible) in every aspect compared to the current direction.
The only real challenge is the need for deeper consideration in designing a natural and convenient UI/UX. While splitting the same topic into individual documents for different types is scalable, it can certainly be cumbersome. We need a UI/UX that allows for smooth and intuitive interaction.
The ideal experience should be so seamless that users feel as though they are editing a single document, while in reality, the data is stored across multiple documents according to their types. The concept should be clear: “The user can treat the whole as one document, but also has the power to control individual parts as needed.” (For instance, when creating a query for an online shop, you don’t always need all related information; exposing unnecessary data only adds confusion.)
I hear you. This is an open forum. If others agree, they will chime in. If they don’t, then that’s feedback in itself. I have already responded to your original post and am happy to give others space to provide their input.
I don’t see it that way.
From experience, I see a lot of users using their tools in a basic way, even though these tools offer powerful features (which I consider to be “better”).
It’s even a struggle at work, when users do things the way they’re used to rather than tapping into the apps’ full potential.
Without looking too far, here’s an example that will resonate with some: Anytype doesn’t have real folders, but many users stick to that model. Yet Anytype strongly promotes other ways of working.
Even with multi-type support, I’m sure many won’t seek out that complexity and will stick with simple types.
In fact, I explained to someone yesterday that you can create your own types in Anytype (he was annoyed at having too many items in the “Page” type) 
.
Oh, there are certainly people like that. I might have overgeneralized a bit, but that case seems slightly beside the point of this discussion.
Let me revise my premise a little. In the context of users who need this feature or are exploring various functionalities, my argument is still valid. Users who utilize features minimally, like in the example you mentioned, wouldn’t be significantly affected regardless of how this feature is implemented.
It would be better to focus our discussion on the premise of users who actually need this feature.
If a user without a firm philosophy on note management methodologies decides to manage their notes in earnest, it seems very natural that they would consider the app’s default features first.
Further down the line of collection infrastructure, I hope we can do something like this:
In a concept or model object, I explain the definition, and the multiple steps or qualities/characteristics. Then these steps become reusable properties for future case/situation objects.
To analyse if the model is applicable to the case, I can create a collection which lists out a short alias for these steps, then make systematic evaluation. If we have multi-dimensional relation, then I can checkbox and explain its relevancy or execution details.
That means it would be nice if the an object can sublimate and “become” an object type with contents being the properties; this way we can organise properties under their own respective context.
In short, this approach emphasises on object as type, more so than type as collection, because compressing type into collection forbids block editors for properties.
First, I want to say thank you to the team for sharing this so openly and inviting feedback at the prototype stage. The willingness to rethink something so foundational takes real courage, and the writeup makes the reasoning clear.
I’ve been sitting with the proposal for a while, and I wanted to share a few honest reactions — not as objections exactly, but as places where I’m still struggling to follow the logic. I haven’t read the full thread, so some of these may already have been addressed; if so, please feel free to point me there.
1. Where does the “context-free” information live?
The proposal frames objects as defined by their context — “context, not category, defines the object.” I find this beautiful as a philosophical statement, but I keep getting stuck on a practical question: where do we put the information that doesn’t depend on context?
A book is a book whether it’s in a library, a living room, or an office. Its author, page count, and ISBN don’t change with the shelf it sits on. In the current model, that information lives on the Type — it’s the stable core. Under Collections 2.0, it sounds like that core moves to a “primary collection.” If so, isn’t that functionally still a Type, just renamed? I’d genuinely like to understand what I’m missing here.
2. What about objects that aren’t related to anything yet?
I do a lot of fleeting writing in Anytype — morning pages, half-thoughts, random word lists. These aren’t related to anything when I write them. Sometimes connections emerge later; sometimes they never do, and that’s fine.
If the central question becomes “what is this object related to?”, I worry this kind of input gets treated as an edge case rather than a first-class use. The proposal does mention an “unsorted” state, but I wonder if the design center can stay friendly to undefined, in-the-moment capture.
3. Could the underlying needs be solved without merging concepts?
Reading the proposal, the user pain seems to be roughly:
-
Too many choices (Type / Tag / Collection / Query) for newcomers
-
Objects can’t easily live in multiple contexts
-
Properties from Collections/Queries are treated as second-class
These all feel real. But I find myself wondering whether they require merging Types into Collections, or whether they could be addressed by extending Collections and Tags while keeping Types intact. Someone earlier in the thread suggested allowing queries to combine rule-based filters with manual collection membership, which felt promising to me — it keeps the conceptual separation but lifts the practical limits.
It also makes me wonder if part of the “four-choice confusion” is actually a documentation and onboarding challenge rather than an architectural one. The four concepts answer genuinely different questions (what it is / how it’s tagged / what it’s grouped with / what rule selects it), and once that’s clear, they stop feeling redundant — at least in my experience.
4. A small worry about what gets lost
One thing I love about Anytype today is that Types give objects a home. A Book object knows it’s a book, so I know where book-specific information goes. If Types dissolve into Collections, I can imagine ending up with many overlapping Collections and no clear primary home for each object’s intrinsic data. That’s roughly the shape of how Notion databases tend to sprawl over time, and part of why I came to Anytype was that it felt different from that.
I may be overweighting this concern — and I realize “primary collection” is meant to address it — but it’s the part that gives me the most pause.
None of this is to say the proposal is wrong. The team has clearly thought through this much more deeply than I have, and I’m sure there are answers to all of the above that I haven’t yet absorbed. I just wanted to share where my own understanding is still catching up, in case it’s useful signal.
Thank you again for opening this up to the community.
In the context of "Books", your book is indeed a book.
But in the context of “Items for my holidays” it’s simply an item that has a wight and a volume. In this context, it isn’t interesting what’s the ISBN, or who’s the author, or what it costs.
You only need to know what happens if you put this item into your luggage.
And in the Context “Everything about Star Wars” the book may appear or not appear, depending on the book’s topic.
If it appears, its interesting to which episode it belongs.
Neither its ISBN, nor its author, nor its weight & volume is interesting in that context.
And in the context “Things that I want to buy as soon as possible” its interesting how much it costs.
It’s not interesting how much it weights, nor what volume it has, nor about what Star Wars episode it is.
And if you run a shop where you sell books and other items, you want to know how good it sells.
In the context “Best sellers in my shop” you are interested in how often you’ve sold it in the last time period. And you want to know how much you still have on stock.
It’s not interesting for you about which Star Wars episode it is, nor who’s the author, nor the volume.
But you need to know where you can order more pieces of this book and what it costs there.
Of course, it must always be possible to see all its Properties.
But in specific contexts, you need to see only a few of them.
And you already know the principle, because the Views in Collections and Queries already do exactly that.
You define which Properties you want to see in the View, although the Object has more then these few Properties.
Such Objects will automatically appear in a certain Collection that automatically gathers unconnected Objects.
I believe the new concept will make it easier for beginners.
They don’t need to think so much anymore.
They define the features for a certain context. Later, if a different context appears in their mind, they modify what’s needed for the new context.
It will always fit to every possible context.
Thanks for your questions, I’ll address a meta level point before diving in the details. On the surface, Collections 2.0 seems like an exercise in simplification, however it’s fundamentally more about flexibility and smoothing out the journey. The destination is mostly the same.
One of the big problems with Anytype today is the mental front-loading and system lock-in. Before you start creating, you have to think about what Type, what Properties, what Views, what Queries, etc. Organisation happens before creation, which is not a good thing. Additionally, after you’ve set up your system, and it turns out to be unsuitable, it takes a lot of effort to rebuild it. This makes the ‘stakes’ too high, which causes the average person to just give up. Most veterans here are reluctant to recommended Anytype because they know it’s too complex.
Not only do we believe in this multi-context approach to objects in Collections 2.0, the other big benefit is that it lowers the stakes of whatever organisation system you take and doesn’t lock you in as much as Types + Properties + Queries + Collections. Yes, in the new system of everything is a Collection (with smart functions) does seem like simplification—but at the heart of it, it also enables a more flexible system that is less rigid. In short, it’s more adaptable to your changing needs overtime.
We hope it’s better for both newcomers and veterans alike—it adds simplicity/flexibility without taking away any power.
Thanks for your fantastic explainer. I hope Collections 2.0 does accomplish that in the end… 
Context live in the collection properties, as @Code-Jack has outlined. The example you used is not ‘context-free’, it’s simply your ‘primary context’. What is actually ‘context-free’ is whatever lives inside the object body, as the different collections/context is applied to the object and its body (the content).
This is exactly what the base/inbox collection hopes to solve. If you want an even less defined ‘in-the-moment’ capture without any features, you can create a default collection that all your newly created objects go into and you manually sort yourself.
Indeed, all four are distinct and not redundant. However, the separation between those features are based on centered how something is technically achieved. It’s simply not intuitive for the average person, and as mentioned, it creates strong boundaries between them. Queries vs. Collections breaks down once you can mix rules + manual aggregation. Types vs. Collections breaks down once you can have multiple types.
Some people find object-based notetaking to be problematic, and need to feel secure in files+folders. I can’t say what will happen for you, but I believe that this is not going to be an issue—just use one collection for every object in the new system. You don’t have to adopt multiple collections onto one object if it doesn’t suit your mental model of the world. For me, one type per object is actually very problematic.
I don’t necessarily agree with this. In 2026, I’ve noticed that many people still don’t use text styles for apps like Google Docs—even though it’s a clearly better solution. Designing a canonical experience for any app is important, but allowing flexibility for different user preferences is also necessary. Collections 2.0 is as simple in practice as applying tags to a file—something that most people are used to even from social media. The benefit is that all of those tags/collections can stay simple or expand into a much more powerful system.
Not sure I fully understand it, but in what scenario would this be helpful for the object content to become the properties?
@Code-Jack @kaye ,Thanks for the detailed reply — I’ve taken some time to sit with it, and I wanted to share where I’ve landed, even if I haven’t fully landed.
On the “context-free” point: I follow the reasoning that ISBN and author could be framed as “primary context” rather than truly context-free. But honestly, this is where my thinking starts to give out a bit — the framing feels like it stretches “context” to cover almost everything, which makes “context-free” less useful as a concept. I’m probably not equipped to argue this philosophically; I just notice that “this is a book with this ISBN” feels different to me from “this book weighs 400g for my luggage,” even if I can’t quite articulate why.
On the base/inbox collection for unsorted captures: I appreciate that the option exists. But functionally, “an object that belongs to the unsorted collection” feels different to me from “an object that simply is a Note.” The former defines the object by what it doesn’t belong to; the latter lets it stand on its own. I realize that’s a small philosophical difference, and probably not one most users would notice.
On the four concepts being technically motivated: this is the part I keep going back and forth on. I think there’s truth to it — the boundaries between Query, Collection, Tag, and Type aren’t always intuitive. But I also notice that the proposed solution (merge them) and an alternative solution (extend each within its current role, e.g., let Queries combine rules with manual membership, let Types carry multiple Views) seem like they could address the same user pain. I’d be curious to hear more about why merging is preferred over extending — there may well be good reasons I’m not seeing, but right now both paths look viable to me.
On the “just use one collection per object” reassurance: I hear it, and I appreciate it. But I’d gently note that defaults matter — even if power users can opt into a simpler workflow, the surrounding ecosystem (templates, tutorials, community norms) tends to gravitate toward the default. So “you don’t have to use it” isn’t quite the same as “your way of working will be preserved.” I don’t say this as an objection so much as something I hope the team is weighing.
Where I’ve landed personally: I think my hesitation is more about taste than logic. I like the current primitive, manual approach, where an unsorted Note simply is a Note, and where I link contexts manually because that linking feels like part of thinking.
That’s a preference, not a refutation of the proposal. If the design direction shifts toward context-defined objects with automated assistance, I understand that’s a legitimate choice — it just may not be the tool for me anymore, and that’s okay.
Finally, What I’d like to ask, more practically, given how foundational this change is:
- Robust export tooling — so users whose mental models don’t match the new direction can migrate their data cleanly to other tools, with structure preserved as much as possible.
- Keeping the current structure available, perhaps as a “Classic” mode or long-term legacy version, for users who prefer it.
I realize either of these has real support costs and may not be feasible. But for a change of this scope, having a graceful path for users who prefer the current model — whether that’s staying or leaving — would mean a lot.
Thanks again for engaging so openly.
Even where I disagree, I appreciate how thoughtfully the team is approaching this.
Let’s say we are making decisions. We have a few models that we can use for the final decision.
Each decision is its own decision object.
Decision Model/Theory is the general system that can be used in decision making. This model involves four steps: (1) formulate, (2) evaluate, (3) appraisal, (4) refinement. These four steps can become properties under decision theory, which can be reused whenever decision is generally made.
- For other users looking at the object, they might not know what decision theory is about. So it is nice to have an object explaining these steps/properties in blocks/canvas.
Because the decision is not straightforward,
Cost-benefit analysis needs to be done. We can have another model object which explain cost-benefit analysis and have a different group of properties that can be introduced to the decision object: Cost property and Benefit property. These 2 properties can be categorised under Step2 of decision theory.
- Here we have sub-properties of properties.
Fortunately or unfortunately, emotions influence the decision making.
Emotional choice model need to be consider. We have several properties: (1) emotion, (2) influence of emotion, (3) strength of involving that emotion (4) bias/weakness. The latter 3 properties exist depending on the involved emotion.
- This will involve multi-dimensional relation, which each emotion is a key property with its sub-properties.
- Or relational data model, this one decision comprises several foreign emotional choice objects referencing from emotional choice collection.
Now because decision time is short,
Recognition-primed decision had occurred. We mark the decision time and the imagined scenario. Afterwards, we revise the efficiency and accuracy of the decision. We check which past experiences had been considered. We can create a list/collection of relevant experiences, then checkbox if considered for that specific decision.
- Efficiency and accuracy can be a group of properties for revision; Each row of experiences and checkbox which contribute to the overall outcome to decision efficiency (aka sub-collection).
- Different to collection 2.0 prototype which nest collection emphasises on nesting and inheriting properties, sub-collection could mean a list of object which determine the results of one property.
Then it turns out the decision involves/involved
Multiple-criteria decision making. For each criteria, we can have different decision models and its respective properties for each criteria, e.g. criteria 1: cost-benefit model, criteria 2: recognition-primed decision, criteria 3: emotional choice model. Since we are dealing with different models, we can forget the details, so It would be nice if clicking on the property will show the section which this property is elaborated in its model object.
Hopefully it is clearer this time. As always, sorry for making things difficult again 
