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.
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).
I’d suggest using the term “Blocks” here instead, as most people know what that means and implies (“building blocks”).
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.
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)
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.
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.
@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.