My biggest problem with Anytype: waste of time

But you are sitting in a saladbar while demanding a steak!

Then you told that steak is not (or not yet) served but you keep deminding a steak now. The restaurant offers you a veggie meat replacement thing and you complain that this thing is not a steak…

After that you tell them how easy it is to serve steak and how dumb it is that they are not able to serve a simple steak. On top of that, you demand that your needs should be met instantly and the saladbar should serve steak (for free) and they should be grateful for your rude “feedback/demands”, no rewarding it even!

The restaurant (Anytype) has a direction or vision what there menu (app/features) should be, which has nothing to do with how easy or simple that dish (feature) is. A saladbar wants to serve salads, you want a steak go to another restaurant.

A calculator is easy to use are we demanding it to process text documents? No! Besides, your demands differ from my wishes, so what should Anytype do now?

The team doesn’t serve us, they follow it’s own direction and vision and if that aligns with your or my needs use the app, if not don’t. It is that simple!

If the team is open for constructive feedback and feature requests (and they are) they will add features when they see it matching their direction or roadmap!

  1. Supporting “this attribute is only visible within the current database” is just a tiny, tiny user experience improvement!
    It would let me create new databases without stress (right now, I avoid using databases whenever I can).

And you’re telling me this would somehow impact Anytype’s long-term vision? Are you trying to make me laugh?

  1. I tell you I’m not enjoying the experience, and you tell me to just leave if I’m unhappy? If you’re an official Anytype representative, I have nothing to say.
    But if you’re not, then you have no right to tell me to leave!

I think everyone gets worked up over nothing. Please be careful with your messages.

“Waste of time” in the title and several times, “refusal to participate in evolution because it’s a waste of time”, “even a pig would know this is wrong” (I remind you that this suits the majority of users… is this an insult to them?), “it’s downright foolish”.
It can only upset those who want to keep the current system.

And, once again, it’s possible and even encouraged to give a different opinion. I do, I want that granularity of properties too.
Maybe just be constructive and not aggressive.
And never forget:

  • that one’s needs are not necessarily those of others
  • that a “little thing” can be hard to implement.
    Here, you need a lot of interface modifications, core-side modifications, import/export modifications, Android-side modifications. In short, a lot of work.
    In my opinion, it’s still essential. More indispensable than other people’s “indispensable stuff”? That’s a good question, and one you need to take a step back from.

In short, to anyone wishing to move things forward, please do so without violence in your choice of words, and keep in mind the bigger picture (different priorities for each, technical aspects sometimes overlooked, etc.).
This also applies to other posts I see :wink:.
And yes, it’s not easy, I also rage sometimes in my corner when it doesn’t work the way it should the way I want.

:heart::heart::heart:

Sorry, I got a bit too emotional.

But my stance remains the same – I genuinely hope the Anytype team conducts a thorough survey.
I refuse to believe that people can tolerate a clutter of duplicate attributes filling up their space.

Especially those who frequently use the database feature!

At first I used properties as they were intended to be used: I put all the tags in one place. As a result, different tags from different DBs quickly accumulated (in the example below there are “only” 39). Is it a waste of time to search for the tags every time I need to use them? Rhetorical question!

In my country and generation ADHD wasn’t very common at the time, but I can’t even imagine how people with ADHD would work with such a fat juicy mess:

Now I see that the tag “Portuguese” is left over from a template I installed. This is another waste of time: once imported, templates cannot be completely removed, further complicating the whole picture. Maintaining a large volume of information becomes impossible! Or very laborious if it has to be done manually for a smaller volume of information.

This is exactly how I am dealing with properties. If you want to use a lot of properties, you just have to use a clever naming strategy (e.g. with prefixes).

Coming up to a year of using Anytype, and this is frustrating and compelling at the same time - over time, you tweak and refine until you get a system that works for you.

Creating a prefix system to remember and maintain, to waste even more valuable time, would be a temporary solution for me, if I know that the problem is being solved. I saw that there is a topic from 2021. Given the speed of resolving this fundamental flaw for me, I will continue to avoid using Anytype.

I don’t find a single argument for global properties, not related to a specific DB.

But there are no “specific databases”. The Space is the database. And there are queries and collections of data that are existing in that space.
That’s just how Anytype works. I think Notion would be better suited to your needs.

The problem is not whether the information is organized in a DB or in a query (I just checked that this is the new term - I last actively used Anytype at the end of 2023, as seen below).

The problem is the absence of properties that are local or only for the specific query.

I tried to see what some system for arranging the properties looks like, so that I know which one is for which query, but it looks ridiculous.

There may be a case where properties for one type are used for another type (example: apples and pears from fruits are used for sofa and table from furniture, but I personally can’t think of even one such example). Personally, for me it is absolutely pointless to have everything in one place and waste my time “organizing” it: property organization systems, besides wasting time, also make it difficult to perceive information: instead of just reading “Health” I have to strain to understand whether it is “Area/Tag/Health” or “Area/Tag/Study”.

Instead of improving my productivity, the poor implementation wastes my time and unnecessarily stresses me. Sorry!

You can create custom object types and assign object type-specific properties to them.

Thanks for the effort of trying to help me! I know, I can do it and that’s not the problem here.

The problem is that if I want to use the “tag” property, all types will appear in it, for all queries in which I use it. So, I have to come up with unique names, by coming up with a system with which I can recognize them, as other users have suggested. A system like this (taken from another topic):

I don’t want to maintain such system, because it is time consuming and in a large property it is even more time consuming to search and consider which property belongs to which query.

In conclusion: this is one of the dealbreakers that keeps me away from Anytype. I need more automation (with API), reminders, repetitive tasks… I realize that this is very complex for development.

Obviously, this naming convention involving “namespaces” must come from professional users, such as most programmers.
If Anytype wants to reach a broader user base (ordinary users), it should reduce the complexity of attribute management.

Even though this may involve significant development challenges (and possibly require partial code refactoring), it must be done!

I believe that at this stage, Anytype should invest more effort into solidifying its foundation and polishing the details.
That is ten times more important than jumping on the hype train to develop some bullshit AI features!

Having every possible feature but all of them being poorly executed — that clearly shows a lack of confidence in the product’s positioning or in the team’s own capabilities.

Notion, as a massive centralized system, has access to abundant data and strong development capabilities.
Think carefully — do you really think you can beat them in the AI field? That’s absolutely impossible!
After all this time, is it still unclear what “differentiator” has allowed Anytype to survive and stand out?

If I were part of the Anytype management team, I would pay close attention to the AI field but would not rush to launch AI features.

  1. AI is important, but it’s not the most important thing for a product like Anytype.
  2. The current stage of AI development is still early and exploratory. Let others blaze the trail — then Anytype can follow with a clearer direction, avoiding waste of resources due to trial and error!

It is obvious that Anytype userbase have a wide range of needs and therefore functionalities that the application should provide. Therefore, my last hope is this:

If the implementation is good, I’m sure I’ll quickly get plugins for reminders, repetitive tasks, one-click content import (books, movies), etc. Anything that expands functionality but also saves time. This will be a huge leap and will move Anytype a long way forward!!!

It’s kind of hard for me to accept that, in order to increase my productivity, I have to service Anytype, instead of Anytype helping me. In this regard, properties are a core functionality and should be addressed by the Anytype team.

One could also argue that you aren’t using Anytype efficiently. Instead of fighting how Anytype works, perhaps you could also find other more efficient ways (that are also more universal) to structure your work. Paradigms that are true to Notion or other apps often don’t apply here.

Unfortunately, that’s exactly the case. Beyond general talk, the only solution that works for now is to create and maintain a “breadcrumb” system, there’s a screenshot above. If you have another suggestion that includes “efficient use” of Anytype, I’ll be happy to consider it! Thanks in advance!

Sorry dear @krst but here I must disagree with you.
OK, you sentence may be partly true. But it is an undeniable fact, that Anytype shredders every day our time because of half baked implementations, in combination with completely missing basic features, in combination with bugs.

Often we run from one workaround into the next. We try this concept, then that concept, not knowing what’s the best and what’s the consequences.

The missing backlinks for images is one of these points.
If everything else has backlinks, why not images?
I forces me to give each image at least a unique name and maybe Tags, so that I can perform a global search for the Object’s that contain them. But how cumbersome is that???

Btw.: “renaming an image” is another time shredder.
It is way too cumbersome, AND too slow, to edit an image’s name and properties inside an Object.

Another point is the still not implemented combination of Collection & Query.
It could be a long awaited “revolution” of my navigation concept. But instead I was running from one workaround to the next.
Actually I use Collections for adding new Objects, but Queries for finding existing Objects.
But this is really only a dirty workaround. In fact, it is cumbersome.
Only Collections create hairlines in the Graph. I wish, also Queries could do that. OK, there is a way that they do it, but it works with Relations instead of Links. – That’s not how I like it.

Unfortunately we have only these two ways to link Objects together. And that’s already another point.
With more “levels” or “planes” for linking Objects, we could have in principle some really smart filters for the Graph and for search.
“Show only Objects that are connected on the business plane!”
We don’t have such features. If we really need such functions, we need to think and think and try this and that way to get something similar. For example Queries with filtered Vies in combination with a Tag regime and so on.

– And this is what the users criticize.
We need much too often to think and to try one thing after the other, because Anytype’s foundation still lacks some bricks; also some of the existing bricks are made only from mud and aren’t able to carry wight.
We have Tags, yeah. But we can only tag whole Objects. Not single Blocks.
Tags are also only one dimensional.

But I better stop here.
There are much more (and also better) examples. And I strongly believe you know it well for your own.

Yes that might be true, but you mention a lot of things that don’t have anything todo with this specific topic (properties that only apply to one specific collection vs globally available properties).

Kayovas wrote this:

And you answered to him:

And I disagreed with you, because I think kayovas is right: “the poor implementation wastes my time and unnecessarily stresses me”.
– I see this sentence as general, not as limited to a specific issue. Because the title of the whole thread is general: “My biggest problem with Anytype: waste of time”
Therefore I gave some examples for things that shredders our time, again and again, every day.

Alone the missing backlinks for images!!!
I need them!!!
Things that could be (and should be) done with a single mouse click on a backlink, needs an absurd effort instead!
Every image needs to be named (also this is much too cumbersome then necessary) and instead of a single click we need to do a global search for the Object that uses the image, but it isn’t granted that we will find it this way.
– Why on earth don’t images have backlinks???
They can have Tags and whatever Properties, but no backlinks.
I simply can’t understand why this basic thing wasn’t implemented from the first day on!

This is a great example for a “poor implementation” that “wastes our time and unnecessary stresses us”!

you pick my answer and the phrase I quoted out of context of his post where I got that quote from.