If I create properties for different DBs, they appear everywhere! I waste a lot of time trying to figure out which property I need (the example here is from a test database; in a real database with many properties, there may be dozens with the same name):
Properties are global. Once created they can be used everywhere. This is one of the main concepts, everything can get connected for example with properties. You could have notes or pages or whatever type you want with the same property.
Why even having multiple ones when they all do the same I would ask back?
I used to use Anytype for everything I could think of to include. Over time, all the collections and sets grew a lot and it turned out that I had properties with over 20-25 elements in them. Some of them were even repeated, since I wanted to filter elements only from a given DB, and not from the entire content.
To search every time I decide to include one of the elements in the corresponding property…
Anyway, thanks for the clarification. I haven’t used Anytype for a while, now I decided to see if anything has changed. Apparently it won’t. And using templates is another nightmare: I imported it with its properties and, if you want to remove it: welcome to manual removal and guessing…
Sorry for the probably mixed terminology, but I can’t keep up with all the renaming.
Make attributes only effective within the current database (like in Notion) – this is a suggestion that many people, including myself, have raised. But I have no idea why the Anytype team has been so indifferent to this. It’s been so long, and they still haven’t made any changes!
Maybe they think their approach is the only right one.
To this, I can only say: this isn’t just a bad idea – it’s downright foolish!
It is not foolish @GuoJing it is a different approach to organizing.
Anytype doesn’t have isolated databases like Notion. Anytype is one global “database” where you can add, filter and organize everything you want and that takes a bit of getting used to. The “databases” you speak of are just advanced search queries.
Yes, there is a lot of improvement to do when it comes to the UI but the tech and approach behind it is solid.
I for one would not want isolated “database” properties!
I don’t want that either. This is why in fact I use Anytype, so that I can combine everything with anything. This is so powerful that I cannot use something else essentially as I can’t have global sets another applications where I can query everything, including isolated database objects (which for me just doesn’t make sense).
I have a star rating property. Being global, it allows me to call up everything that I think is great - a query for anything in there that is rated 5 stars. I like being able to do that.
With others such as genre, I just add a prefix like “literary genre” or “movie genre” to allow them to be searched but differentiated.
I think it is because you don’t understand the concept that Anytype is compared to Notion and from what I read is you are better of with Notion for your usecases.
Notion has isolated databases, Anytype doesn’t have any databases. It has search queries that search your entire space and that is the core of Anytype everything is global in your space. That those search queries have views and interface like Notions databases doesn’t mean they function the same way.
Adding isolated “databases” to Anytype doesn’t feel in line with what Anytype is and most likely will not be added.
You seem to be frustrated about this in the way you word your posts and that will not help. This functionality has nothing to do with being a simple concept or not but all with the direction and vision of Anytype that sadly is not in line with yours.
I guess because it would be extremely inconvenient otherwise for me personally.
After using Anytype I tried out something like Notion or Appflowy and I could not twist my head around that databases there are isolated things. I could not do anything with the objects outside that database. It frustrated me quite a bit and I did not know how to utilize this.
If Anytype would consider this request it potentially would create a new type: local database or something like it, where everything is isolated. I’m not sure if this added complexity (that I would think would suck up quite some time and resources) would benefit what Anytype identifies with.
I think the solution would be to add a scope to the properties: by default, they’re global, but a simple “Set as local” checkbox that makes them visible only on the current object type would suit everyone, I think.
Other solutions exist, but they are more complex (property tree, for example).
But it’s like all requests, whether it’s taken into account, under consideration, scheduled for a day, planned or just nothing… no idea.
If I’m in a collection and add a property there and click on the checkbox local, what would happen then to the object that I created there in that collection?
This then would have a property that only applies to that database though and is otherwise globally available. It would then need to reflect in the right sidebar and in its type settings that this type also -could- contain a local property. If a person then does this a lot of times, the type could get pretty messy with a lot of locally available properties that are not available otherwise.
Perhaps the local property then just needs to get added to that specific object and the global type would not list this (not sure if that’s a good idea).
Or the objects in that local database are not global objects and also just local objects and would not exist otherwise in anytype.
All this thinking adds a lot to the UI and UX and could cause a lot of friction if not done right.
instead of just bitching around @GuoJing how about suggesting real solutions how this could get implemented and perhaps get familiar why Anytype does things as it does now in the first place.
As a regular user, I don’t have the relevant professional skills.
I can only raise requirements – I don’t have the ability to come up with solutions!
And let me emphasize this: Anytype should be bringing us gift boxes to thank us for our complaints!
It’s like when I’m dining at a restaurant, and the owner offers me a free meal in exchange for filling out a feedback form.
Most likely, I’d refuse – because it takes up my valuable time!
I don’t go into a restaurant if I don’t like their menu .
Spoil: I don’t use Anytype for my data yet.
But I love the restaurant’s view and their wine list, so I’m participating in the hope that my dish suggestions will one day be on the menu.
Really, don’t hesitate to vote and participate in the post above if you’re in the same situation!
Even this discussion can weigh in the balance, if the team passes on reading.
I’d also love to limit certain properties to one type (like tags, which I use a lot, but not with a common list), so I fully support this request but I’ve learned that my needs aren’t necessarily everyone’s.
Entirely with you on this Shampra. I understand that this is how Anytype works, but I also see and support @GuoJing’s point, I too would love the ability to make certain properties confined if possible. Both sides are valid.
I too am not using Anytype as my main because it doesn’t have most of the features I need yet, so I can’t speak on the intricacies how of this should be implemented UX wise. Am using Notion and have no problems with properties confined to each database (I sort of prefer it too).
Just some thought: if we have all properties be global like how it is now and we’ve been using Anytype for decades, would the list of properties just become overwhelmingly messy with too many superfluous values to choose from?
Aside from the FR that Shampra linked above, I see there is another somewhat similar FR for this (thanks @filip). I have voted for both, but whether or not it’ll eventually be implemented who knows…
I don’t like the “menu” at the Anytype “restaurant,” but the damn restaurant owner keeps insisting, “Our dishes are green and healthy,”
so I decided to give it a try.
If they truly believe in the principle that “software should be simple and easy to use,” then they should meet our needs sooner,
instead of filling my space with a bunch of attributes with the same name.
.
