Everything is an object?

Talk
, ,
1

According to the philosophy of Anytype, everything is an object. However, during the daily use of the software, I can feel there is a large cleft between objects and collections.

If I create a ‘task’ object, I can add different blocks in the editor, but I cannot view the objects in the content of the task in the grid view, calendar view, etc.

On the other hand, if I create a ‘collection’, there is no way for me to add any blocks as its content.

If ‘everything is an object’ is real, shouldn’t ‘collection’ be a function or a mode of any type of object instead of a separate entity?

2

The differences you describe are about how specific object types are designed to function in the interface. The principle “everything is an object” refers to the modeling approach, not to all objects having identical layouts or editing capabilities.

Could you share a bit more about what behavior you would expect instead? It would help to understand the workflow you have in mind.

3

An object having links to other objects is naturally a collection of the linked objects.

For example, I have created a task A. Within task A, I have subtasks B, C, D. Currently, when I want to view ‘all the subtasks under task A’, I need to create a collection or use a query to contain the subtasks B, C, D. However, logically, this is actually redundant, if you consider an object is actually a collection of the objects linked to that object.

Of course, ‘everything is an object’ is a philosophy borrowed from OOP. If we follow this analogy, what is the role of the ‘collection’? Should it be a ‘special object’ or a ‘layout/function/mode of an object’? Or can it be both?

6

Push

9

Your general desire is understood and seems to be a common expectation across various users. If I had to break it down into something simple, there is a desire to create hierarchy via folder/dropdown behaviour —which is particularly desired for task management.

It’s true that this isn’t simple to do in AT compared to a basic to-do app. This type of behaviour is not where Anytype shines. But we could create some interesting UX solutions for this. Mentally I’ve been contemplating a lot on how we might implement a ‘folder’ like object that contains everything within it, that would still not create conflicts in an object-based system.

10

If you could use links and backlinks on desktop and mobile the easy way you would be pretty close already.

By this I mean defining also different kinds/types of links should be possible. Similar to

And with respect to

I found my solution by having pages, collections and queries that have the boolean attribute “directory” activated.

And bear a folder icon. :grin:

11

A widget can show hierarchical structures clearly, even with circular references.

image
image291×462 9.18 KB

I do not understand why this is not implemented in the collection UI.

12

No, it can’t.
It’s an illusion.

It is, in principle, impossible to depict a mesh structure (that Anytype uses) in a hierarchical way.

This was often discussed.
Some users don’t get it, but I repeat: it is – in principle – not possible.

There are solutions that give the illusion of a hierarchical view. But such solutions come with a prize. They don’t represent the reallity anymore.
Either such solutions list certain elements more then once in the hierarchy. Or/and they break loops apart and “hide” the real complexity of the structure for the user, trying to show only the most important part.
I don’t like such attempts at all!

It’s much better if the users finally try to understand the difference between a simple hierarchical structure (like the file organisation in Windows) and the much mightier and much more beneficial mesh structure that Anytype uses!

A hierarchical structure is like plain text.
While a mesh structure is like Wikipedia, with cross-linking to anywhere, back and forth.

A spreadsheet is excellent for displaying two-dimensional data sets in an X/Y matrix.
But if you need a third dimension, or even many more dimensions, the concepts comes quickly to a limit.

A hierarchical structure, like Windows uses for the file system, is by principle two-dimensional.
You can reach each end point with two coordinates.
While Anytype’s mesh structure does not even have a clear nameable amount of dimensions! It has more then two, that’s clear, but you can never definitely say how many – it depends from the concrete structure you have, and this changes all the time, because each added or deleted link changes something in the structure.

There is no clear start point in a mesh structure.
(In Windows, there is!)
Also, there is no clear end point. An Object CAN be an endpoint at the moment, but as soon as you link to another Object (that may already have further links), the situation has changed.

An Anytype Object can have multiple incoming links.
That’s again a huge difference to the much simpler Windows file system, where each Object has only exactly ONE parent.

It’s no problem to show a structure, where each Object has just one parent, in a hierarchical way.
But it is not only hard, but impossible, to do it in Anytype!
There simply is no underlying hierarchy. AND THIS IS A MIGHTY BENEFIT!!!

-- Don’t try to organize your data in a hierarchical way!
Get this idea out of your head, you have a MUCH more advanced tool here with Anytype!

Enjoy the benefits that Anytype offers to you!

13

A tree is just a subset of graphs. How the UI displays the structure is just a graph traversal problem. The software designer can have the freedom to pick a suitable mode for a certain functionality. Saying the graph structure is mighty is like saying a stem cell is mighty. Yes, it is, but it still needs to differentiate when necessary, when we need eyes, a nose, limbs, etc.

14

In short, because this hierarchical structure creates two problems:

  1. It gives the user the wrong idea of how objects are actually organized in the system, which can lead to ‘I thought I deleted this, why is it still here?’ — among many other issues.
  2. In simple setups the hierarchy can seems fine, but when it gets complex it really breaks down—especially as you try to delete and move things around (it won’t behave as you expect).

@Code-Jack actually put it quite well, by even implementing this hierarchical solution it comes at a cost — so we also don’t like it. But many users (such as yourself) often request for it. So we’ve left it as a widget structure for now to help with some high level navigation—which can prove helpful. But if we were to implement this further and also include it inside collections, people may start to use it entirely as a folder-like system—which it inherently is not.

We actually have something interesting cooking in the oven on this exact topic, we will share more during the next Town Hall.

15

I see. So this is a design on purpose to avoid misunderstanding.

16

Yes. By implementing these ‘familiar ux features’ from the files/folder world, it helps to orientate new users. But it comes at a cost: they don’t actually learn the object-based system and are unable to use Anytype properly.

This is one of our biggest challenges that we’ve put countless hours/days into thinking about. But as mentioned, we may have some interesting solutions both with Collections 2.0 and something new we’re thinking about.

17

Sounds awesome.

Is there any perspective when the next town hall could be?

18

Not only a design choice. It’s simply impossible to do it properly.
Whatever the team cooks at the moment (what Kaye has mentioned), it will never be a proper hierarchical representation of a real mesh! NEVER!

As mentioned, every imaginable “solution” comes at a cost.
It’s like with plain text, it simply can’t transport a speakers intonation and motion as it was originally given.
A transcription comes with information lost.

Or same with a translation – you can translate an English text to German and vice versa.
But try it with a A poem that rhymes …
You can transport the bare meaning, but not the rhymes. If you try it, you need to reformulate things, and that comes with the cost of some losses in the meaning.

A mesh structure ich richer then a hierarchical structure could ever be. You simply can’t press that into an hierarchy without losses.

Some users with less expectations and only simple uses cases, wouldn’t recognize these losses and simply be happy with what they get.
But others would at some point realize that something is odd and then loudly complain in the bug report section.
And because the team simply can’t do the impossible, such users would blame the team; they don’t understand that the problem is one of principle.