I’ve been trying out Anytype for a bit now, and I’d like to share my first impressions, as seems to be the tradition around here ;-).
I think I’m probably in the minority of Anytype alpha testers in that I’m coming at it from a more-or-less fresh perspective, having not used any other similar tool such as notion or obsidian or roam for long enough to consider myself proficient at it. As such, I hope I can provide a unique perspective, untainted by prior experiences .
I really like Anytype’s object-first approach. As someone who dabbles in programming a bit, this paradigm was fairly easy for me to wrap my head around. That said, I share the concern I’ve read from in a few other places that it may not be as easy for someone who doesn’t come from a programming background, especially if they also don’t have experience with a similar tool like notion. I remember when I was learning about OOP, the difference between a “class” and an “object” was really hard to understand at first, and I fear there may be the same problem with new users for the difference between and object type and the object itself. If a new user is simultaneously trying to find their way around the UI (which is not a super easy feat either - more on that later) and trying to figure out what in the world “objects” are, and why they have types, and what is a “template”…I think you get the picture. I’m not sure how to address this issue, and maybe it doesn’t turn out to be an issue at all, but those are just my thoughts there . It’s possible that documentation will fix this, but I know not everyone reads docs . Maybe more video tutorials would be helpful as well.
Now about that UI. On the positive side, it does look nice. Unfortunately, it’s not really easy to use. The idea of centering everything around objects and the only structure being the links between them (i.e., the “graph”) is cool conceptually, but isn’t really a great experience in practice if that’s the only way of viewing object’s relationships to each other. There are some things that logically “belong” to another object (for example, an assignment “belongs” to a class). Having all assignments nested inside of a class in the UI would make navigation in particular a lot better.
I think the idea of the relationship model being a graph is that relationships between objects should be thought of as many-to-many first, rather than one-to-many (which is what the “tree” model is, where objects have at most one parent, and parents can have many children). The tree model does not work well for many-to-many relationships, and so it is very limiting in that way. However, the graph model makes navigating one-to-many relationships overly complicated, so it is very limiting in that way. So here’s the question - why do you have to pick one? Anytype is not meant to be simply a note-taking app, so avoiding the tree layout as the primary conceptualization for object’s relationships to each other makes sense. However, while that paradigm certainly doesn’t work for all object types, it just as certainly works much much better than the graph paradigm for conceptualizing certain object types (like the relationship of a class to an assignment, as mentioned above).
So here’s my suggestion - add a toggle for relations to objects labeled something like “parent”. If this toggle is on, then the object will nested under that object in the side panel. The child object would not be removed from the graph, and would still be able to have other relations to other objects, but this parent-child relationship could be considered conceptually as the primary relationship. The object should still show up in all the places it would before - in the recent panel, in favorites if it’s starred, in the graph, etc. Maybe in the graph though, there could be some way to differentiate regular relationships from this parent-child relationship, like with an accent color or something. That way you can easily find all objects that belong to another object, right there listed with all their “siblings”. You never would have to go searching for the notes for the last assignment for a particular class, because all you have to do is expand the class and see the most recent assignment object at the top of the list.
This is obviously just one suggestion for how to handle this. Any solution that would increase the users’ ability to organize their objects in a more rigidly defined way would solve this problem. Again, I’d like to stress that I’m not suggesting this as a replacement for the graph view, but as a complement to it. The graph is awesome for getting a high-level overview of all the relationships between all of your objects, but not so great when you really only care about the ones that belong together based on one specific type of relationship (such as all the assignments for a class).
Other than those two things, there are a couple of things that I would expect to be fixed before the first public release. These are both acknowledged by the team, but I’m just chiming in to say how important they are in my opinion.
The first is the inability to delete relations. It’s very easy to end up with a junk-load of them when just tinkering around, and then not being able to delete them is a big problem. I’m not sure why this is such an issue - maybe because it’s hard to handle what to do if you try to delete relations which objects are still using…but it seems like you could just pop up a window asking if you want to remove these from the objects, and give the user a chance to cancel. But in any case, whatever the reason is, this is, in my opinion, a deal-breaking issue for usability, and definitely an issue that should be solved before public beta.
The second is embedded (or “inline”) sets (ref: Support for inline creation and display of sets). This is one of if not the most upvoted feature request I’ve seen so far, and for good reason. This is probably the #1 blocker for feature-completeness in my opinion. Similar to this, the ability to embed pretty much any type of object, with the ability to choose which properties/relations to display, and have them updated automatically when the object changes, would be an awesome addition as well, but this is more icing on the cake and not as necessary in the short term in my opinion.
NOTE: The above suggestions are just my opinions for what I consider to be necessary before Anytype is set loose to the public. They are not my “demands” to the development team, who I know are working extremely hard to add features while ensuring that Anytype remains good quality software. I’m just providing feedback. I am fully aware that the development team is fully within their rights to accept or reject any and all of my suggestions.