Alright, here we go, here is my feedback on primitives after testing it on v0.45.12-beta. Sorry for the long text, this is a big update and I have a good amount of feedback 
The good
- The overall UX improvement is substantial and significant. Primitives will make it a lot easier for people to wrap their head around Anytype and how to organize it.
- The right-hand sidebar (RHS) looks good, works well and is very convenient. It’s a great addition.
- The hidden properties in the RHS is a nice touch to keep things clean and simple.
- The query inside each type is incredibly helpful, and it’s a smart way of integrating it: just a simple in-line query. Love it!
- Renaming “relations” to “properties” is great!
- I really like how the place to manage templates is a bit more hidden now, to make types more central. I think that makes a lot of sense given that templates aren’t as critical now that we can apply property changes to all objects of a type.
- Overall great release. As I mention below, I think there are important things to improve in order for the aims of Primitives (improving Anytype usability and accessibility) to be achieved. But this release is a major step in the right direction! Kudos to the whole team
The small stuff
- I believe that it was a mistake to rename Sets to Queries. While technically correct, a “query” is an obscure term for most people who are not tech savvy or familiar with data-related work. It’s nice to see that “List” is slowly replacing “Collection”, but the original idea of renaming “Sets” to “Smart List” is still the best solution to make it as accessible as possible. The reason List/Smart List is a great combo is because new users only have to learn one new concept (List), with two variations (regular and smart); but Query/List will sound to people like two entirely different concepts that aren’t related.
- In the RHS:
- It’s unclear what “Database name” refers to. “Database” isn’t used anywhere else in Anytype, as far as I know, so I have no idea what this means.
- There are some properties that I want visible at the same time both in the header and in the sidebar. This is because when I open the sidebar to work on properties, I don’t want to have to go back and forth between the header and the sidebar; and I want to know that there is a space (the sidebar) where I can quickly see all object properties without having to think about which ones are in the header and which ones are in the sidebar. A system like we had previously, where we would ‘favorite’ a relation/property to add it to the header, was preferable.
- “Set up” is vague and confusing (is this to set up the object? the type? the sidebar?). I suggest using “edit type” instead (though as I mention below, I don’t think it’s a good idea to make it so easy to edit a type).
The big stuff
Properties are still overwhelming
When working on or with properties (adding a property to a type, filtering a query/list, etc) we still see the full list of properties that exist in the space. This is confusing because we’re talking about dozens (maybe hundreds) of properties, including system-properties and properties we cannot delete.
While the renaming of relations to “properties” is a step in the right direction, having so many properties that are displayed each time we search through our properties, edit a type, or set up a query/list is overwhelming and confusing.
My suggestion to fix this is that by default, properties should not be space-wide.
- This has already been discussed extensively, but Primitives don’t fix this: if a property is created as part of a type, it should be exclusively visible in that type or in Queries/Collections columns that include that type.
- More generally, there should be a clear difference everywhere in Anytype between:
- Type-specific properties, which are user-created and should only be available for that type unless the user “adds to library”.
- Space-wide properties, which are user-created, are stored in a “Library”, and can be added to any type or query/collection. This is a very common way of managing space-wide properties (Asana does this and many others).
- System properties, which cannot be deleted. Because those cannot be deleted and are not user-created, they should be clearly marked as system properties and separated, otherwise they really get in the way and add confusion.
I am convinced that this separation between three kinds of properties would make a huge difference in making Anytype more usable and accessible.
Managing types should be centralized
- Currently, editing a type can be done from within any object in the RHS. This is incredibly dangerous now that changing a type affects all objects of that type. There should be more friction to edit types.
- Ideally, types would only be editable from inside the type’s page.
- Clicking “Save” should also display a warning to make clear that these changes will affect all objects of that type.
- More importantly, having type editing in the RHS of any object blurs the line between object and type. To newcomers or users who aren’t very teck savvy, this makes it more difficult to clearly separate object and type. Instead, types should only be editable from inside the type’s page.
- Because editing a type doesn’t happen on a daily basis, it’s okay for it to take a bit more work and require going to the type’s page. Having type management in a completely separate space will make it a lot easier to conceptualize types to new users.
- It will also make general management of a space tighter: from inside an Object, only the object can be edited; to edit a type, you need to go to the Type’s page.
- Instead of “set up” or “edit type”, there could be a button that says “manage type” and direct the user to the type page (instead of letting the user edit the type right there in the RHS).
- There needs to be a full screen list of all types. To manage types, we need to go in the LHS, scroll horizontally through tabs, select the Types tab, and then see the list of types in this small, crammed space. This doesn’t reflect the importance and centrality of types in Anytype. Managing types is a critical task and it we should have a comfortable UX to do it.
Need to be able to delete all types
- With Primitives allowing us to apply changes to all objects of a type, types are becoming even more central as the unit of organization in Anytype. But this means that we need to be able to delete default types. I never thought it was a priority before, but now that I’m investing more time into organizing my types, it feels frustrating to have all these extra types I will never use and cannot delete.
- For example, I created a space to build a CRM. That space will only ever have the CRM and nothing else, because I want to keep it super clean and separated from everything else. But keeping it clean and neat means minimizing the number of types, and yet I have all these extra types I will never use.
- I don’t see a reason for Note to not be deletable. Shouldn’t Note be a layout instead of a type?
- If there are types that cannot be deleted because they are central to Anytype (eg. file), they should be clearly marked as “System type”.
More appearance options for header properties
- I never liked the way favorite relations were displayed in an object header. It’s too small, too crammed together. So for the past two years, I simply minimized my use of favorite relations and instead added relations to the canvas of each object. It didn’t matter if my relations were in the header or in the canvas because objects had to be individually updated to add new relations.
- But now that types are getting an upgrade, I really want to use featured relations / header properties: I want to make sure some properties are visible for all objects of the type, and have all objects updated when I edit the type’s properties. But because of the way header properties are displayed, I am for now sticking to having properties in the canvas, which really sucks. It would be great to have the option, for each type, to decide how header properties are displayed. The way Notion displays properties is nice.
For reference, this is one example of how I use canvas properties instead of header properties, and the kind of appearance I would like to see for header properties:
