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!