I don’t know what you mean by this:
- What are now called “Types” are really “parent types”, containing one or more children types (as well as any other type of Blocks)
I agree with the concept that Anytype would be better off having a proper OOP hierarchy all the way to the basic text paragraphs, so I voted this. However, I’m not sold on the idea that they should be called Blocks, but I also don’t have a better suggestion right now.
The more i rely on Anytype for writing long text, the more i need this feature. The main thing for me would be to add tags to blocks so i can search and find much more easily.
Didn’t you mean To blocks?
Whoops yes, thank you for flagging. I edited the original post
Well, the whole point of this post is to have both be one in the same.
Hi!
Thanks for the input @qualquertipo, it’s good food for thought!
In general I think you’re describing something more akin to outliners, and/or Tana. If AT is too much friction, those might be a better fit. Given that there is a subtle hierarchy of objects and blocks, I think changing all the terms to what you suggest would make it more confusing. Here’s my 2 cents:
It’d be interesting to have a background study on Anytype users: who came from other apps and which, which struggles they have, and to correlate that to the experience with the current terminology. We get tight formatted based on what we’re used to using, so my impression is that functioning so different while being a carbon aesthetic copy of Notion really hinders the learning curve.
“Objects” and “blocks” seem to align with that the team is trying to build so I wouldn’t rename them. What I think is lacking is complete documentation explaining these terms and use cases being built along. Charlotte did a great job with the tutorial videos for quick reference, and in the future I’m sure the documentation will be added to.
“Object”, understood as Information you’re entering into anytype, categorized (Typed) as what you’d first think about (An instrument object, a store object, etc)
“Block”, understood as a building blocks within Objects. Default line, that can become objects if you choose.
Sets, collections and relations I’d suggest the following:
“Sets” understood as “Grouping of objects based on what you ask of Anytype to find for you” would be renamed to “Automatic group”, “automatic set” or “Automatic database”
“Collections” understood as a grouping of objects of your choosing, without any input from Anytype, would be renamed to “Manual grouping”, “Manual set” or “Manual database”
“Relation”, since it implies relating to something else, can be misleading. While that can happen and be visible in the graph view, most of the time they’re effectively used as properties, which aren’t always “relating” to something. I’d agree with changing it to “Property”
For context, I’m a therapist and used Notion and logseq when starting with Anytype. It all clicked once I looked at Anytype as something on its own.
(Now that I think of it, we use the term “objects” (internal and external) in psychoanalysis… that might have had something to do with the ease of understanding 
)
Agree and object relations theory too 
. The mobilisation of objects and relations are so fun. Blocks as objects is like ego state as parts of person. With blocks as objects, it is possible to analyse contents as compartments or whole object.
I would take a second thought before depriving unlinking relations into property, cause it could eliminate the possibilities to more functions. For some tags are just pure indications, but theme tags (e.g. philosophy) can be upgraded to objects (or areas in graph if ever implemented).
Especially with the potentials of relation as objects, like how a meeting object listing blocks of incidents, which are transference - relation pattern, for predictions of behavioural outcomes (reusing blocks as objects in a relation format). While we don’t need to use transference or object relations theory to understand everything, we also don’t want to eliminate the theoretical framework or prevent the usage of such implications.
P.S. I personally constrain myself from using property like relations to retain the potential of relations and graph usage.
Yes.
I posted this as a feature request here because I want Anytype to have this feature. If you don’t agree, no problem!
Of course! @qualquertipo I apologize if what I said came across antagonistic (sp?). It wasn’t the intention.
Generally Anytype being more like Tana or outliners would be a dream come true, it just doesn’t seem to be a design priority of the team given the roadmap and town hall discussions (why I suggested looking into Tana if for now it’d work better with this feature set)
These FRs and your contribution are great to let them know what we’d like to see someday, and come up with more ideas 
If “blocks as objects” is difficult to implement due to architecture constraints, the alternative feature request that I’ve just created is meant to address some of the needs behind these suggestions here. Please check it out and comment! 
No worries!
I was just explaining that this FR is not just a “cool extra feature that would be nice”.
The FR is ultimately asking for a new type of data model. Unlikely to happen, I agree. But that’s the FR.
As I just posted in Link to blocks + Transclusion / Synced blocks, this issue has been heavy on my mind for quite a while now, and I wanted to dedicate as much time as possible this week to solve it as straightforward as possible.
I believe I cracked it, by addressing the user needs at the parent ‘List object’ level rather than at the child ‘Block’ level. Take a look at a this FR suggesting Sets and Collections to help solve much of this.
This works with mostly existing Anytype functionality, and more straightforward than my related initial FR above from yesterday. Here’s a mockup:
- current List view of multiple objects,
- proposed new “Document” view that collates multiple objects into on List object (Collection/Set): Would you mind sharing what you think about it?
WHAT DO YOU RECOMMEND
an option to tag any branch (example: task) of that tagged page to be able to organize these task with other task in one task set
HOW COULD IT BE DONE
By add on/off button or checklist to tag branches of tagged page.
REAL WORLD USE CASES
Save time consumed in tagging each branch of the tagged page .
It seems this is a specific case of the more general idea of being able to nest Objects. Essentially this would mean that any Block is an Object (and/or vice versa).
There are a few conversations already going on related to this, such as:
Mods have been consolidating similar FRs under a single FR, so votes on them accumulate (rather than be scattered across several FRs). Not sure if this has been done to this topic.
To mods: By the way, how does the team assess popularity of a FR? Is it just by Likes to the main post? It should also count likes to any posts thay have been consolidated under a post, right?
Good points.
There are several discussions on how to nest Objects and how to apply (a change to) a Relation to the Objects and its children:
- Hierarchy in Sets (Option to have rows in Sets be nested (and foldable) based on page hierarchy)
- Discussion about “Nested Objects” in general (Nesting Objects/Sets inside each other)
- Bulk edit (Bulk Editing of Pages / Documents )
- Multi-select (Add multi-select to sets )
On your point of assessing popularity, as far as I know, priorities are set by:
- The roadmap the team already has defined (reworking Relations, inline Sets, rework tagging system, etc.)
- Survey data and in-depth interviews with users
- The amount of likes a topic has
Note that I’m basing this on my experience and not on any official communication from the Anytype team.
There are plans to activate a voting plugin to make it easier to upvote a topic instead of separate posts underneath a topic as those do not count towards the likes of the topic itself. A lot of work has been done to clean up stale bug reports and feature requests, and to split/merge/refine feature requests where relevant. As there is a lot of other work to be done like squashing a lot of bugs (introduction of the Nightly Testers program), working towards feature parity (introduction of the Release Train), and self-onboarding (to reduce workload of the team needed for the current onboarding proces) to name a few, there is no ETA yet on when the voting plugin will be rolled out.
@Mohamed_Elkiey could you confirm whether the topic linked by @qualquertipo is indeed a more general feature request for the feature you’d like to see implemented?
Rereading the original post, in order for it to be contemplated by my FR (nested Objects) I guess there’d need to be an option in the tag filter to “Also include objects whose parents has the tag”. (Hope that makes sense)
@qualquertipo
Your original article are full of terms that made me confused , because my technical Info is very weak 
If you can explain your idea with simple terms , it will be helpful
Sorry for that. To be honest I’m also unsure what you mean in your original post.
I guess the main idea in my feature request is that everything should be an object, and that these objects can be nested within each other.
For example, let’s say you create an object called “Tasks for home”. Then within that you can add tasks (which are themselves objects).
Regarding tags, if I added the tag #home to the “Tasks for home” object, then later created a Set containing all tasks tagged #home (as well as all tasks with parents tagged #home), this Set would contain all the tasks within this “Tasks for home” object. Hope that makes sense!