Heh… Agree completely with this. This happens to me, for example, when I am trying again Anytype as a daily/dairy PKM app. Coming from Emacs, I notice issues right away. But after a while, my muscle memory finds workarounds, and I don’t notice it anymore, and think everything is fine.
I also do not understand this.
What I would understand, and what happens to me, is that although grasping the concept, it is very hard to work with daily.
Creating new types, changing types/adding properties/selecting proper template/etc. I notice that I use queries/sets not because I want to list objects, but because I want to create an object with specific set of properties/values. An easier/more practical (like a set of buttons/menus) way to create new objects with specific templates/properties/values would make this way easier. Configuring default “type settings” (the way a type appears when creating one) or allowing to duplicate types would also help.
Anyway, listing these things would also make me procrastinate til Xmas, so I won’t do it. Specially because I am hopeful about the new developments next year, and the “paradigm shift”. But I do feel that creating easier ways like mentioned above impact me more than the editor issues (which I easily adapt to).
You’re definitely not using it wrong, having Properties (the new name for Relations) always be space-wide is one of the biggest complains by users. I agree that it is counter intuitive and becomes very inconvenient as soon as your space grows. There is a feature request to fix it: Add support for collection-specific relations
This is one of the biggest advantages of Anytype imo.
My space needs to be chaotic. Collections and folders create friction for me and I need to be as flexible as possible. Otherwise I create knots in my head and think too much about organization.
And it’s not mutually exclusive .
It offers major advantages in terms of flexibility, but also major disadvantages (I can confirm that it quickly becomes a total mess).
The solution would be to define the scope of a property (visible only on the defined collection/type or in any Anytype), a simple switch in its configuration would suffice.
Somehow I don’t get it why some users about the mess. But nevertheless:
There could be another approach then Collection specific Properties: Simply allow folders in the list of Properties.
This way, the user could group the Properties as he want to hold the list compact and clean.
(But I have an even better idea, see further below.)
I believe it is the wrong approach to restrict the scope of Properties to Collections, because it would be totally against the philosophy of Anytype.
Anytype doesn’t depend of Collections in a sense as Windows folders.
An Object can be in multiple Collections.
When creating a new Object, it may belong to one specific Collection first. But later, the user may think that it also belongs to a second or third Collection and link it to them.
What should then happen with the Properties if there’s a discrepancy?
Admittedly, my suggestion with folders in the list has the same problem.
A folder structure is by nature simple a tree structure. An element can physically only be in one folder.
Anytype frees from this restriction and I experience it as an important benefit.
– In fact, it was even the main reason why I left OneNote and looked for an alternative.
My best suggestion to solve the here discussed problem is, that Properties get a “Property Tag” so that the user can give each Property one or more Tags.
The list of Properties then needs a filter option to show only Properties with a certain Tag.
This approach is much more flexible then grouping the Properties in folders.
And it would be much better for the user and also more easy to implement for the devs, then restricting their scope.
– Only my two cents; for me is that all not important.
As I think this is the main point of your post, I’d like to mention that I’ve moved my PKM to AnyType and have been using it exclusively for the past month or so. I listed all my issues and then went one by one and resolved them, either by creating feature requests, reporting as bugs, or finding workarounds. All my main issues were resolved within a couple of days. Some turned out to be caused by the source system and/or the import process (I still find messed-up code blocks and links, for example), so I fixed them in Obsidian and repeated the import process until I got them resolved. Along the way, I learned some AT quirks and “secrets”, looked at the code, and basically solved all the issues that were a bother. Now only the missing features remain (hence, I’d have to counter your argument by asking for more features ).
But I understand your point, lots of good info there and in the comments later, if you stopped using AT in the past months. Now, however, I find that lots of bugs have been fixed. One can really notice that, after Chats, the latest big feature, the overall focus seems to be moving exactly onto what you, and the rest of us, are concerned with. One big item that was mentioned in the townhall was exactly the Editor replacement/rewrite. If there are no major new features on the roadmap then it is obvious that the effort will go into polishing the experience and getting from that Beta status (into which it was recently launched from Alpha! And you keep complaining about issues in alpha software. Come on.) into a Release.
Indeed.
And I take this as opportunity to thank the devs for the hard work!
Especially the last few days was a joy, because they fixed a lot of the stuff I’ve reported quickly!
(I can see it best for my own reports, because the notifications.)
– That gives the feeling that they really care about the feedback.
It wasn’t always so that it felt so; I often couldn’t understand their priorities.
But for the last days I must say that I’m very happy!
It feels so good to see every day some of all these small little issues disappear!
Well.. Adding Properties specifically to a collection is different to restricting properties to collection. If the collection component is confusing how properties are managed under either/both collection and object, then maybe Make Properties First‑Class & Queryable in Anytype might suggest a different explanation of how property/relation can be used for different scopes.
Onto the folders and collections, we should not mix up the two concepts of 1. single source of truth and 2. location of a single element. We can show the same thing at different locations at the same time (like collection), or have a copy of the same thing in another location (like folder). Users can do both in Anytype, as they desired.
If properties are added to a collection, then the source of truth to those combination of properties can stay in the collection object, or can be referenced elsewhere with foreign keys calling for the exact/different combination of data (hence I always suggest relation data model).
If a property is added to two different objects (as collection is a type of object in itself), then it created two contexts for the data of that property. Just like how it is okay to add DateProperty and Date to different bookmarks, multiple objects are shown on that Date, there is no conflict between those bookmarks.
To add, we should not forget Properties are the updated term for relation. Collection-specific relation was the original name for that feature request and folders for relation would be even more confusing. (Although folders/hierarchy might seem the most obvious way to manage tag)
P.S. @Code-Jack Sorry that lately I might seem to be carrying a lot of conflicting ideas because of the distinct definitions of terms, and our very distinct use case. You facilitated a lot of thought process and your words are appreciated. And if you have more thoughts of collection-specific relations, we might want to discuss on that post. Cheers.
As for the original topic of this post, the one missing thing that might lead me to leave is a full single user version, beyond lockdown mode (and perhaps non-digital version of Anytype XDD). Because in UK, Ofcom is saying user-to-user services must also comply with the Online Safety Act (see here for the document) and the possible client-side scanning before encryption ( Ofcom wants to double down on file monitoring in 2026 | TechRadar ). Of course, I am not suggesting Anytype to become such a program (or become paper-and-ink), but who knows what will happen in the future.
Somehow… the biggest complains by users (I didn’t realize a poll of a good sample size have been done, must have been sleeping during it) is the biggest feature that users of other PKM’s want: 数据库全局属性 · Issue #13121 · siyuan-note/siyuan · GitHub
This is translated to english, but still, I think it is very well described the issue:
Someone that used SiYuan, knows the issues of local database properties. SiYuan itself, translates their database, when converting to markdown, as a simple table. It is too bad that the markdown tables on Anytype are very simple, and do not have the features as queries and collections, but if they did, they would be the counterpark of SiYuan databases.
The issue with this, is that the property would still exist in the space, just not visible. I know what you mean (I think I do), similar to variable/block scopes in programming languages, but … I see that as having to do a major development of how Anytype works, and honestly, I think it would confuse a lot of people. (I am not disagreeing, as I use variable/block scopes everyday in programming, and it is “ingrained” on me, but I don’t think its a very understood thing generally).
Question: When saving these “scoped to database properties”, where would they end up? on the database or on the document? SiYuan saves them on the database, meaning that the document does not contain or know anything about the data introduced on that database. Saving them on the document, … well… they turn global, because they leave the database.
For me it is not 2 missing feature but 2 big bugs:
search is a pain in the a… resulting in having duplicates for many objects. Sadly, it is quite random and I did not find which conditions could make it failing
I have several contents stuck in the transfer phase (files, images). Once again, I do not know why it is stuck but it is
Two people I know left because they couldn’t organize into sections and pages like with most other software (Evernote, Joplin, Onenote etc). They can’t get along with what they perceive as a messy “web of explicit links” paradigm.
Personally:
tables suck - it’s hard to create them (onenote makes it a breeze with a single key - TAB), it’s hard to edit them, they’re rudimentary - no formulas, rich views (bars/%), advanced formatting, etc. Hint: make tables [EDIT: and queries] more like airtable, less like Word.
no geographic coordinates support. Most objects have a location and belong on a map (an open source map).
No vim shortcuts or more shortcuts and actions customization. I dont want to rely on the mouse as little as possible. I might just end up making a vim extension but I like the client UI
No dataview or spreadsheets that use object properties as data sources.
In the spirit of @HAN’s answer, which was a little askew from what the OP actually asked but I think is still worth sharing: One aspect of AT’s current design that’s essential to my use and that would make me leave (or at least stop upgrading) if it were dropped is that there’s a way to view connections between objects hierarchically. That happens to be in the side-menu view of pinned objects, which isn’t the essential part - it could be elsewhere, but it just needs to be somewhere. I detailed my use-case in another thread, where I was actually asking if there’s a better version of it elsewhere in the app. I still would love to see such an improvement, but the current implementation has been sufficient.
The reason I’m bringing it up is that I know AT is fundamentally not designed for hierarchy, which @anton has reiterated more than once in this thread, even suggesting that anyone who wants hierarchy should be using something else, like Obsidian. I’ve tried Obsidian and other options, and none of them feel usable for me, for a variety of reasons. AT hits so many marks, including the option of hierarchical organization, but the fact that that feature only exists in one place, in a fashion that seems kind of incidental, makes me feel a little wary whenever an update comes out. I could easily imagine it disappearing for the sake of back-to-basics streamlining or a different approach to the logic of the side menu or whatever. So this is me flagging it as highly valuable to me, grateful it exists and hopeful that that will persist!
I’ll add some reflections here, as it is a nice thread to follow over time.
First, following on my recent comments, I’m happy to say that there are no “2 missing features …” for me any more.
With collapsing headers being worked on and tabs already implemented, pretty much all my pain points are (or will be soon) gone.
What I’ve noticed recently, however, is that AT runs relatively sluggish on an older PC. So, some performance optimization would be great.
Also, I had an issue where the app would not start, or would crash, and/or would keep running and prevent another instance from running (without me realizing that it is a 2nd instance), etc. That raises my blood pressure significantly because AT contains all my knowledge bases and I’m next to helpless working on any of my projects without it. So, some way of ensuring that data is recoverable and accessible in most disaster cases would be extremely helpful. I.e. Markdown files are there no matter what happens to the app displaying/editing it. I know it’s not the same but perhaps having some more separation between synchronizing / editing / viewing content would make things more resilient.
I’m missing the seemingly basic functionality to quickly batch-update lists. For example mark a few cells and paste them into a different property. That would make error correction, exports, transformations etc. waaay way easier and less of a pain.
And overall: more security. Someone can get the qr code or vault key soooo god damn easilly xD Like pls, just put an extra password or so on top of it. Considering there is ANYTHING in your PKM its really valuable, sensitive and you dont want others to easilly get into that.
Give us the possibility to write our own Plugins. I would have made a few already. And if the functionaltiy is essential you can always add it to the core system.
.
).
