Everything is a... Block?

Disclaimer: I’m posting this as a “Feature Request”, but it’s really a mix of things. Mods, feel free to move it! I don’t really expect the suggestions below to be considered at face value. They’re mostly a way for me to communicate my needs/confusion/thoughts as a new user.

I love the idea of complex systems built using very simple parts. I’m glad Anytype takes this approach, by stating that “everything is an Object”. However, I’m wondering two things.

"Problem" 1

First, the name “Objects”. I’m guessing it comes from the idea behind OOP, which makes sense. But could be confusing for non-coders (especially considering Objects can represent non-physical things).

"Solution" 1

I’d suggest using the term “Blocks” here instead, as most people know what that means and implies (“building blocks”).

"Problem" 2

Second, I wonder if this aforementioned elegant underlying block-based system comes across to the users. My experience is that Anytype feels a bit messy and confusing conceptually.

"Solution" 2

To me it would be much simpler if:

  • Everything is a Block, which can be nested within each other
  • What are now called “Blocks” are types of Blocks (Paragraph Block, Bullet Block, Image Block etc.)
  • What is now called a “Relation” is a Property Block. When nested under another Block, it gives its parent that property. The actual value for the property is given by its children Blocks.
  • What is now called a “Set” is a Data Block (or maybe Aggregator Block?). It requires two children Property Blocks, one for Query (ex: Grab all Blocks containing a Property Block called “Due Date”) and one for View(ex: Calendar)
  • What is now called an “Object” is really just a Block with children Blocks (paragraphs, images, properties etc)
  • What are now called “Types” are really “parent types”, containing one or more children types (as well as any other type of Blocks)

Edit: added last bullet point

9 Likes

If you downvote, please add a comment explaining why.

Is it because you personally don’t like the idea? If so, I’d like to know why. Maybe it will help me (and others reading this) understand Anytype better.

Is it because you think (or know) that the developers are not open to such structural changes? I’d also like to know if this is the case, so I can stop making such suggestions and comments.

Or maybe I explained my idea badly?

Let’s communicate! Thanks.

1 Like

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.

2 Likes

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.

1 Like

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? :thinking::grinning_face_with_smiling_eyes:

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.

1 Like

@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. :smiley: 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.

1 Like

@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.

2 Likes

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.

2 Likes

A post was merged into an existing topic: Terminology and Concepts

@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.

2 Likes