Indeed, negative reviews should come with explanations.
So from my point of view, your 1st problem is not, as Objects refers to tangible and multiple function while Blocks doesn’t. Except for lego’s, minecraft and so on.
About your second point, I need time to think about as I waited to get the database update to really jump-in Anytype, So I have to test it in details.
It is possible that some people have stopped at your first problem. You should have dissociated them.
Thanks! Yeah, you’re right. Maybe I should have kept those separate…
Not sure I understood! You mean Blocks have a more limiting definition than Objects?
My guess would be that most (non-tech) people think that an Object is a physical thing, and that’s it. Meanwhile, a Block can be that as well, but also a metaphorical unit of anything (thus the expression “building blocks” being used even for subjective concepts; for example: “Color, composition and contrast are the building blocks to good design.”) But that’s just my guess… Only way to know for sure is with some AB testing.
Precisely.
I don’t think so because Anytype isn’t a physical store, so even newbies can’t expect to handle physical objects, even Techies who collect NFTs.
I think you are wrongly right, so shall we see the definition.
building blocks: A basic unit from which something is built up.
It’s like a blank page, you can do anything from it. The thing is anything is the opposite of specific. An Object as a specific function at it’s core.
Would we both be graphic designer? 
For sure, a bit difficult at this scale, but I love the idea! AB testing features inside software’s or SAAS may be the future of development, for real.
@AyneHancer Ok, I get what you mean.
I guess it’s hard to know what would make more sense to most people without doing some user research…
To be honest I don’t really care what the actual name for this fundamental unit would be. 
I just assumed most non-tech people don’t “get” what an Object means, but that’s just my guess.
I don’t mind calling it “Bloop”, for example. My main point is that I think it would be best to have the “everything is a Bloop” approach be reflected in the actual UI (instead of having Object/Blocks/Sets/Relations, they’d all be Bloops).
That way, if I want to add the book Sapiens, that is a Bloop. If I want to add author information, I add a Property Bloop called “Author”, having as a child another Bloop named “Yuval”. The Property Bloop “Author” is a Bloop on itself as well (ie. I can click on the word and be taken to it) - I can use it to write my general thoughts about book authors, for example.
My gut reaction and reason for a downvote is that I had no idea what a “block” was or how it would relate to items in anytype, and describing pages as individual “building blocks” is not at all a metaphor that helps me visualize/mentally navigate my map of anytype pages. Separating pages into different “objects” that have different “relationships” between eachother clicks for me immediately and feels intuitive and congruent with how these pages are constructed and used within anytype.
@wyattlrose Thanks for explaining!
In Anytype Blocks are the “paragraphs” within an Object, for example.
But my suggestion is just to use the same term to address an Object, Block, Set or Relation. Doesn’t have to be “Block”.
What do you mean by Page?
Forgot to link this here. I made a new post with a proposal that is broader, related to this one:
@qualquertipo I think the discussion about nomenclature/terminology deserves some more attention as it lies at the core of Anytype’s concept. My guess is that the Anytype team at the very beginning of conceptualising came up with an initial structure and then built on top of that, leading to additional concepts that required their own name.
I agree with your notion (heh, pun not intended) that it might be good to simplify the terminology to get back to its core. For me, the most important concept within Anytype is that there is no hierarchy for Objects, Blocks and Relations themselves. There is an hierarchy for Objects / Blocks / Relations and their Types. And there is an hierarchy between Objects and Blocks as an Object can hold Blocks, Block currently cannot hold Objects (although that might change with Inline Sets).
I think renaming everything to a single name reflects that when Objects and Blocks become more alike or equal.
This could also lower the learning curve for new users, hopefully without making communication about the different concepts more ambiguous.
Hey @sambouwer sorry I didn’t reply to this earlier.
Yeah I agree.
From the developers perspective it’s probably difficult to change these things (especially since they probably have a lot of plans/ideas that we don’t even know about). But it’s good to let them know what we think, so they can take it into consideration when they’re making design decisions.
@Jeroen is it OK for you if I move your comment with your 2 cents to here: Terminology and Concepts? I think it would be a great addition to the general discussion of how we name things.
What’s described here seems to more like a traditional outliner, and that + types is pretty much Tana.
My two cents:
I don’t personally think that objects are that hard to understand, and also, blocks are just not the same things as objects in current Anytype nor do I think that they will become the same thing anywhere in the near future. If blocks were to become objects, they would just end up being one of many many types of objects that already exist.
I agree that blocks should be like objects and that we should be able to transclude other objects into blocks repeatedly, but proper nesting is something that currently goes against Anytype’s philosophy iirc. Transclusion are like links, so they are fine.
And like I’ve mentioned in my previous post, the rest is just describing an outliner that uses supertags which is, again, not something that Anytype is trying to be at this point.
Edit: I’d just like to clarify that I would very much love if Anytpe went the way of Tana and made blocks objects themselves, the same way they made relations into objects recently. Outliners are super flexible in both building what you want and and accessing what you want.
Thank you. I think this will only become even more important once block embedding is introduced. This article makes the case for this model really well, IMO: link
Agree with this. To me “blocks” implies a structure - it might be a block of text, or it might be a “container” for another item (I’m avoiding using the word “object” 
) such as a video clip or formula or whatever. That’s certainly how it’s used in other apps such as Notion, Roam & Logseq. Using it here would create a different kind of confusion.
That quote is in the context of current Anytype. I was just explaining how currently blocks != objects.
Structure wise, I’d check out Tana if I was you. Everything in Tana is a node which are similar to blocks in Anytype. An equivalent to AT objects are supertags. A supertag supercharges a plain node by adding fields (relations) and some other features, but the supertag still acts like a normal node. A supertag is basically just a node with extra features. In contrast to that, in AT there is a hierarchy between blocks and objects where blocks can only be placed in objects while in Tana there is no such hierarchy. Some other outliner apps like Roam still have this hierarchy with pages and blocks.
How Anytype could implement this is to just remove the constraint where blocks can only be nested inside objects, and to make objects work similar to how blocks work now.
Point taken. I was (not very clearly) making a semantic point.
What AT calls an object is more than what Notion, Roam and the rest call a block. I think that calling AT objects “blocks” will confuse users migrating from other apps, because the term block will be what language tutors like to call a “false friend” - a word that looks like it means one thing, but actually means another.
I think the term “object” makes sense because AT exposes pretty much everything to be managed by the user and so a term that can be used for any component seems helpful.
That said
Finally - let’s not forget we’re still in beta (well, will be in a few hours!) - some of the stuff coming down the pipe might clarify or change some of this.
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.