I think they managed to add a lot in a year and a half. Since the beginning of this year, in a closed alpha, it has been massively tested by users.
The most interesting thing happened in September. They switched to a model somewhat similar to Fibery: types, relations, sets. And on top of that is a suite of apps that expands freely.
I’ve been an alpha tester of Anytype for about a year now, and am also currently consulting with them. So I’m glad you bring it up. I think in the long-term their goals overlap with Fibery, but for a while yet it is in practice more of a personally-focused tool. That said, I think their Types, Relationships, Sets (i.e. “views”/collections) approach has some interesting implications and benefits that may be worth evaluating and learning from (both what works, and what doesn’t).
I too have tried Anytype. They seem to have boiled everything down to objects and relations.
This has a simplicity which is appealing, but it also seems almost dogmatic in its universal application. For instance, a person object doesn’t just have a birthday, it has a date of birth relation to a date object.
For the more simple object properties, this seems to me to be an unnecessary contrivance.
Personally, I like the distinction between inherent properties of an object (what you might think of as simple fields of an entity in Fibery) and relationships, which are connections between objects (or entities).
If a person has a d.o.b. relation to the 4th May 1985, does that mean that the 4th May 1985 has a ‘was born on’ relation to the person (and maybe other relations to other objects)?
What about a simple integer property, e.g estimated task duration. In Fibery, this is just a number field, but Anytype would seem to treat this as a relation to an integer number object
I agree wholeheartedly with your concerns! Remains to be seen whether they can figure out a way to make this tremendous flexibility actually A: intuitive to use and B: distinctive/advantageous enough in the end-result capabilities, to justify the greater complexity/lack of structure to guide users. I think more flexibility is needed, beyond even that provided by Fibery, but that does not necessarily mean “total” flexibility (i.e. everything is the same type of primitive with the same options/functions). Several companies are somewhat going that way, Remnote actually is something of an example too (“everything is a Rem”), just as Roam (“everything is a block”). And I have yet to see it made truly intuitive for the average person. Knowledge/DB/coding enthusiasts love it though.
Totally agree with you @Chr1sG on the object-relation dogmatism. Despite the “simple” concept, it is anything but simple to build the data structures and apps you have in mind. And yes, a date is an attribute, not a relation IMHO.
With Fibery, I was able to wrap my brains around the concept in minutes, and it took me another few minutes to build the first functional core app for my needs.
Now I have a fully working project/kanban app in Fibery that was super quick and intuitive to set up.
With Anytype, whenever I start something, I never manage to end up with the app I had in mind.
The only killer feature for me is that data is local-first and encrypted.
For now, I stick with Obsidian for documents and Fibery for planning, project tracking, and daily kanban. A great combination for me.
But I am happy to give them some more time to make the Anytype UI more intuitive to use.
They are still in alpha, which in itself means that this is not the final look of the app.
In any case, they are interesting for their concept and architecture. And they did not abandon the development of the application, despite the “long distance”. So it’s worth watching them.
I spent an hour in AnyType and here are my thoughts:
It’s almost not possible to build process management tool inside. There are no Views (Board, etc) and you have only Objects. I imagine they will add Views later, but so far it’s not possible.
I think they “stretched everything is an object” concept too far. For example, Relation is an object itself. It’s not intuitive. It may be so under the hood, but it confuses me… I might want to create different Type of Relation. Is it possible? Unclear…
There is a concept of Type, but surprisingly there is no concept of Field. It makes Type design a very complex cognitive task. I have deep experience in all no-code concepts, but I struggled to build a new Type to handle Invoices let’s say. You have to think with Templates, but even in a template there are no Fields. It’s very hard to capture Numerical data and Dates are objects? Insane… Templates idea is quite good BTW, the problem is in execution.
Maybe as a personal life-organizer it works better, I didn’t tried to use it this way. There are many ready-to-use objects, like Book, Article, etc, so it might be attractive to keep everything here, but I am not that kind of person…
I do like the idea of a distributive and fully controlled system, but in its current state I don’t like the execution based on items above. They should find the balance between internal complexity and UI. Now you have an access to the guts of the system. Blocks editor is also good though
Indeed, the whole ‘everything is an object’ gets too crazy for my tiny brain.
So, a relation between two objects is an object, and an object type is an object.
Which means if you want to create a relation between a task and an assignee, you’re linking two objects, each of a specific type (=object), using a relation (=object) of a particular type (=object)
Yes, this is more an issue of terminology than anything, I think. I have told them that using “Relation” here is not ideal and causes confusion.
Yes, this is exactly right. The “database” features (Relations, Sets, Types, etc.) were only added a few months ago, so there is still a lot of work to do to make it intuitive and easy to use. Lots of work is happening internally on this stuff.
I find anytype quite interesting as to me it is the closest any of these types of no/low-code tools have come to a true graph/tripplestore. But I agree that by simplifying the model to everything being objects and relations they have created a lot more complexity. I am hoping that a happy medium would be achieved in fibery, more akin to a property graph (per various request like Relationship properties).
As @Chr1sG said, I think entities should have attributes which are basic primitive types (as fibery does currently). However, I think having an ability to actually define/contextualize the nature of relations between objects is something that is sorely missing. For example, being able to relate people/contacts in a CRM app to each other and defining their relationships (e.g. coworkers, introduced by, …) without having to create many relation fields or defining these a priori is quite important. The ability to also add one-off relations without having those become permanent parts of the schema is also something that should be adopted from anytype as it would simplify the UI quite a bit (i.e. reduce number of fields, tabs, windows, etc).
I also think that at some point, it may be necessary to “spin off” entity attributes into standalone entities/types when some nuances or complexity needs to be captured (e.g. what seems like an inherent property might be more fluid than originally thought). I don’t think any existing tools provide this ability (you always seem to have to create a new field and copy things) but I think it really helps with reducing complexity when designing systems up front as you do not have to consider every possible case and accommodate them. One of the areas where this comes up for me frequently is actually the name/appellation of things. Names can change or the same thing could be called by many different names. Being able to capture and retain this in any knowledge system is absolutely critical in order to prevent duplications and having records that are out of sync. You can achieve this by making notes in text areas and using search but you end up losing context, consistency and an ability to actually do some analysis in the future.
One final note with respect to dates: I actually do think that having a relation between entities/objects and dates can be quite useful when you would like to understand historic context. Imagine being able to see all the occurrences/events that coincided with each other. I think as you add more content to the system, this will become more and more interesting.
Yes, although Fibery’s existing “Select” Properties/Attributes (both single and multi) are essentially their own Entities. So there seems to be some of that capability already, which is interesting. A generalized “promote to Type/Entity” option would be interesting…
This sounds more like an “alias” feature would be useful to you. I’d find it handy as well, although I haven’t seen much/any other mention of it here. It’s certainly extremely important in general PKM.
Yes, absolutely! Although most tools that take advantage of this simply use a page with the date as the name to handle it. It’s less abstract than a “date relation”, as Anytype has. This in combination with the “backlinks” feature lets you visit any date page and see everything that happened on that date. Of course if you don’t have a true date “concept”/functionality associated with that “date page” and it’s just like any other page, then indeed you can’t do more sophisticated things like e.g. a timeline, or date calculations that involve that “date page”, etc. So there are benefits to the “date as relation” concept. I do think there is probably a better, more intuitive way to handle it than Anytype does currently, though.
@Oshyan as always very insightful. It is interesting “running into you” in various places on internet.
That is the perfect way of describing it. Maybe it should be feature request!
I totally agree that “alias” feature is quite important (I always think of it as the “owl:sameAs” relation. However, I think with appellations, sometimes it is necessary to extend alias to go beyond this entity may also be called “x” or “y”. There are sometimes other critical information that need to be captured, such as the period where the name was in use, the language, the region where it was used, etc. I know that these don’t really seem to matter in a context of a project management tool, but as you said it is quite useful in knowledge management systems. My area of work is in management of municipal park systems and I actually find it indispensable to know what different parks/places were called in the past (and when) whenever I am going through archives of reports and drawings.
This is a very interesting point, and I think it starts to demonstrate where the “everything is an object” approach might have more utility. In that model, like Anytype, the name itself should be an object (“relation” in Anytype), and you should then be able to have history for it (like full document history, but for each object). This seems the simplest way to solve the specific “when was this name?” case, but it doesn’t handle the “region, language”, etc. So then going a step further, I guess you must create a “Name” Type of Object, that has a Date Range property (field, or “relation” in Anytype), a Language property, etc. Then you connect your Names to your parent object, e.g. the park you want to track the names of. Then you need a way to specify which is the current name. I guess you could do this with a Field of the Park object that is a Relation to the Names. With another field for “past names”, that has the rest. Hmm. Is that the beginning of an approach to handle this? Is it too complicated? Could it be made simpler or more automatic? If so, how?
The simpler solution is just to have History Type with Name and Date Range fields and have a 1-* relation to Park. Now you can create new History Entities for any Park entity with Name and Dates when this name was valid.
Indeed! But this only solves part of the overall described need. There is a tension between creating dedicated functionality for things vs. overall flexibility, I think. However “history” seems like a fundamental capability, so I agree it should exist and would be an important part of the solution.
If you could then add fields to a history object/concept, you could potentially take care of some of the other needs described, e.g. location a name is used, etc. Then you need a concept of date ranges being referenceable as a “thing”, in a sense. Perhaps this is where “named versions” come into play, or something similar. Thus you can create “This name was used from this date to this date in this location and language” type of “named versions”. Maybe that is not the best way to solve it, I’m unsure. Just thinking out loud, really.
Edit: @mdubakov I replied before you finished editing your response. So if you then add fields to the History type for language, location, etc. I guess it solves it?
So if you then add fields to the History type for language, location, etc. I guess it solves it?