Latest feedback about some significant drawbacks

[C.c]

@Logic

I don’t understand what you’re referring to because Relations already are Objects. For my part, I was referring to the Blocks as Objects. I’ve corrected that part in my post and think I’ve explained it much better with visual exemple.

I agree that look really nice and I especially like how you have display all contents within that ‘block object’.

See FR treat relation as objects.

Perhaps we can understand if something is block and object in different ways, bringing all functions to relation, block and object

	Relation	Block	Object
Ability to reference else where of its contents in original state	✕ e.g. content for lyrics relation of a song object cannot be reused in journal object, aka not connection point	✕	✓
Applicability of the structure else where	✓ relation type can be applied to multiple objects	✕ no structure; but should block contain format e.g. callout or inline template?	✓ as template
Whether it can contain attributes or relations	✕ e.g. Currency of Price	✕ enables block tagging in the relation way	✓
Appearance / Location of relation	◐ Partial - Must have space between relation name and its content & sometimes feel like cumbersome additional pane	Not supported	◐ Partial Favourite relations must show below title or at the top
Whether it can link/mention to other things (using @ or /link or cmd+k with highlight)	◐ Partial - only limit to relation that contains object, not text	✓	✓
Inline / in-text input	✕ must use pane or clicks and not streamline	✓	✓

---

@Logic

4. Sets should merge with Collection and be able to query different Types and Relations

I like your proposed layouts. It is not easily visible the query matters if it is hidden in filter. I have to enter in myself to see it

I certainly think query should enable multiple objects / relations.
But I still think collection and set are two different things.. One is query; another is manual categorisation. I believe collection is the solution to people wanting folders, but not multiple things.

This point illustrate a part of the irreversibility - since users already well adopted a previous way to manage their contents. But I suppose if set supports query of multiple object types, then it is only an upgrade to set, nothing will change for collection / manual selection of objects.

@Logic

Types/Relations could be hierarchized by Sub-Types and Sub-Relations

I supports these features every much.

@Logic

I’ve deliberately placed a tag with the identical name “Softwares” and in this situation, if you enter Software in a tag search, you’ll get a display of the closest relatives of each of these tags so you know which one you want to refer to and therefore add.

Would FR disambiguators enhance your management in a non-tag way?

@Logic

an example of how to use Tags

I suppose you could create 4 different relations of who, what when, when and where, and use the relation type which allows objects? And if we have FR build title from relation, you can push German onto Berlin object, perhaps it will partially solve your sub-hierarchy situation.

@Logic

One of the primary functions of tags is to enable quick reference, retrieval and indexing.

Quick reference and retrieval: If global search is well functioning and displays relation as well, querying should not prevent you from getting to where you want to reach. Both the object type or the relation of type should do the job finding object of software. And may I suggest adding supports to querying multiple object as relation input to Search? ← this help find articles that contains 2+ concepts.
Index? How do you index with tag? Indexing to me means identification down to every single object, like zettlekasten or library catalog..

---

@Logic

I don’t believe in community votes because there’s the unfair “First Mover Advantage” inherent in most voting systems, which only amplifies over time.
Besides the way forums like Discourse are designed, which relegates old topics to oblivion and encourages no one to explore them.

Well, wouldn’t this make sense? The older the topic and people still support it, the more priority it deserved, and so more accumulated votes reflect this.

But perhaps can we ask Anytype Team to occasionally revise backwards - from oldest creation time? Or if we can add oldest display onto #Forum, it should encourage people looking at older posts? And if people find the need of old feature request and start to create new one, they would be greeted by similar topics on the right pane of writing. Ultimately, features are usage based, not voices based.

Different to electing political leader, the effect of one vote is unseen. Your one vote matters on the forum. Just one vote get the topic to the voted list.

See what @Filip did to get what he wanted on track .

@Filip

I will sacrifice one of my votes so that hopefully this starts gaining some traction.

---

@C.c

• What features you want wouldn’t work if they are not implemented properly?
• What other features will need a solid ground of the above 6 things to work?

Sorry I didn’t make myself clear. I meant what would someone build up and expand its functions of these 6 points from your way and from other way? In other words, one indicator of irreversibility is the team has constructed something from it and the new function depends on it, the other new features would not work because the foundation is different. e.g. A treehouse won’t work if your foundation is a river. What’s your treehouse?

---

P.S. See how I am finally learning and finding the use of tags in this post to address blocks with their relations to topics​:rofl:… but if it is in Anytype, I probably just want to link or mention it.