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.
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.
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.
There may be other terms that are as good or better - I just disagree with a choice of “block”
There ra my be other apps (like Tana) that have found better solutions to the problem of describing this
Some work on the AT documentation could do a lot to clarify the syntax and structure for new adopters.
At this stage, it’s essential to recognise that new users to AT must invest some time in learning how AT works
I expect that, in the future, prefabricated templates (maybe a different term) will be available for AT (possibly via 3rd parties, possibly for a fee) that will enable a new user to get started straight away with (e.g.) a study plan, a building project, an academic dissertation etc., obviating the need to figure out how to build one from scratch. Notion has.a vibrant template marketplace on this basis (I’m not plugging Notion but just using an example I’m familiar with).
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 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.