Difficult to create/modify types and properties (~Notion database properties)

What’s the point in having objects of a Type if all the objects of the type at the end of the day are all different with each their own set of relations… This is just a mess.

To further clarify, they aren’t. Every relation you add to a type is also added to every Object of that type (afaik). They are just not added to the Canvas. The Canvas is just a visual user-facing “page”. Click the relations panel and all the new types you added to the type will already be in there.

And the point of having individual relations on individual objects is that some relations don’t need to be on all objects of a type. Objects in the real world are fluid. Some objects of one type have their own unique individual properties. That’s how the real world works, and Anytype is meant to convey/map out real-world object relationships. It is also necessary to provide the fluidity for things like note-taking, class-specific information, and many other things. And it allows for extensibility quite easily, like I already demonstrated previously with me extending a default type.

To solve the problem you are describing, imo, would be to add a feature to synchronize templates with their object canvases.

Yes, I know the relations are there in Anytype’s objects after adding to the Type, but having to open the relations side-panel to see/edit them essentially make the none-existent

No it doesn’t. That doesn’t make much sense to me. The relations panel is one click away and is editable and accessible by the user. How is it non-existant if it’s existant?
You don’t actually have to open the relations panel to edit them because you can add them to the canvas and edit them there.

All the problems you’ve mentioned I think can be solved with shortcuts and synchronization instead of making Anytype more limited or less customizable: Things like adding synchronization between templates and object canvases, having a “/” shortcut to add a relation directly to a type, and having a “/” shortcut to create a new type. That, and maybe making the relations panel more visible.

Removing the distinction between the Canvas and the relation panel, imo, would not be the way to go, because this distinction is useful. This is why on feature requests, it provides a section to talk about alternative options you’ve thought about or tried, because they want you to think about alternatives that won’t break things or introduce any new restrictions.

1 Like

Sorry if I don’t have all the correct Anytype terminology down yet. I’ve tried to be more keen on it in the following.

To me am still talking about the same thing: the hassle and unintuitive aspect of using Relations (properties) in order to use the Set (“database”) feature. It requires too many steps if you’re working in an iterative manner compared to knowing everything in advance and then building a system never to touch it again (waterfall model).

Yes, but every Relation you add to an Object of a Type is not reflected back to the Type - they just reside in that object alone. If I wanted Objects to fall outside of the Type they were given I wouldn’t make them of the that Type to begin with. What’s the benefit?

I have no problem with versatility, but to me the idea with Types is to provide structure. If this structure can be completely disregarded and insures no control then what’s the point? Then just make a bunch of templates and forget about Types.

What’s even the difference between a) creating a Type and a template and adding the Relations in the template only vs. b) creating a Type and adding Relations to the Type? Because if we get the feature with template-sync I would not bother adding relations to a Type, but just add them straight in the template.

My point is that there is always a limit to how many steps something can have before it goes from easy to use to hard to use/dealbreaker. E.g. when opening an object I only see the Canvas. I then have to take the step of opening the Relations. If I write something on the Canvas the Relation panel closes. So I can’t take in the Relation panel information while working the Canvas even if I wanted to. That’s why this to me is none existent/not workable. Also, I have a hard time imagining adding Relations to a Type and not wanting to see this information. Probably the Relation information is going to make up 90% of the Object of that Type.
I’m fine with adding them to the Canvas manually if we were talking about creating a page from scratch, but I’m talking about building a Type which I thought would save me the hassle of reinventing the wheel for each object of that Type. Giving me consistency between Objects of that Type, so one doesn’t look like a banana, another one a dog, and a third one an equation on dark matter. I would have created those three as three different pages/objects not belonging to a Type (or being three different Types).

I need Types to be able to use Sets, which is what it all boils down to for me. From Notion I know how much I use and how often data boils down to something that can be worked/viewed in a “database”/Set/table. I’m just trying (or rather) failing at getting this rolling in Anytype.

I’m definitely not trying to make a case for making Anytype less customisable. I’m just utterly flabbergasted at what I thought would be a prime Notion database killer feature being close to unusable, as again, this is what I believe(d) would set Anytype apart.
Also, I think you are right that synchronisation would alleviate some of my struggles. Hopefully it would be two-way, so I wouldn’t have to go all the way back to the template every time I’m working in an Object and figure out I need to add something.

Sorry if I don’t have all the correct Anytype terminology down yet. I’ve tried to be more keen on it in the following.

It wasn’t about you not having the terminology. You said nothing about things being “reflected back” in your OP, only that the UI had too many steps (which we can agree on btw). So you cannot saying I didn’t “address” your issue originally when you didn’t even bring up that issue to begin with!
Your OP talks about adding properties to types not showing up but properties within templates do show up. Your OP post doesn’t talk about wanting to modify types/templates after the first use, or about synchronization, or about things being “reflected back” or about there being a shortcut to quickly add a property to a type from within the canvas, or anything other than the fact that there’s extra steps to add properties to types because of the required use of templates - which I agreed with to a certain extent.

You can post a different issue, that is fine. But I’m now answering your different issue.

Yes, but every Relation you add to an Object of a Type is not reflected back to the Type - they just reside in that object alone. If I wanted Objects to fall outside of the Type they were given I wouldn’t make them of the that Type to begin with. What’s the benefit?

I already explained the benefits. And again, Objects don’t fall outside the type they are given. An Object has every property the type has, but a type does not have every property all of its objects have. I don’t understand the confusion.
Some chairs can have cup holder types, but not all chairs have cup holders, and yet we don’t say cup holder chairs are not chairs because they have extra properties than other chairs! It’s called sub-classing (or even extending classes within OOP programming), except there’s no type hierarchy within Anytype.

If this structure can be completely disregarded and insures no control then what’s the point?

It’s not completely disregarded. It can be disregarded if the user chooses so, but there’s no reason why the user must choose so, and being able to do this has nothing to do with whether Types have no structure, because they do. That’s why I compared this to prototype programming (heck, even OOP programming has this with virtual/overridden methods).

My point is that there is always a limit to how many steps something can have before it goes from easy to use to hard to use/dealbreaker.

Yes, I agree. This is a different problem. The amount of steps can be improved, but you do not have to do that by removing useful features. This is why I literally mentioned:

That, and maybe making the relations panel more visible.

Also, I have a hard time imagining adding Relations to a Type and not wanting to see this information. Probably the Relation information is going to make up 90% of the Object of that Type.

But other users might not have a hard time imagining this. Anytype is more than just a database program… Canvases aren’t there to just list out all of the properties, you can add way more to canvases. You can duplicate property fields, you can add connections without them even being within a property. You can add images and videos and audio, etc. You seem to be set on Anytype being a database-only system.

I’m fine with adding them to the Canvas manually if we were talking about creating a page from scratch, but I’m talking about building a Type which I thought would save me the hassle of reinventing the wheel for each object of that Type. Giving me consistency between Objects of that Type, so one doesn’t look like a banana, another one a dog, and a third one an equation on dark matter. I would have created those three as three different pages/objects not belonging to a Type (or being three different Types).

ADDING PROPERTIES TO A TYPE AUTOMATICALLY SHOWS UP IN THE RELATIONS PANEL OF ALL OBJECTS OF THAT TYPE. You HAVE THAT CONSISTENCY ALREADY.

And now you are using a strawman to make my argument look worse by coming up with some weird reason for using a feature Anytype has instead of talking about the actual reason you might want to use that feature - which is subclassing.

Objects can have individual properties. Just because they do have individual properties does not mean they don’t follow the type specified! What if I had a chair where me and my friends wrote our names on it. Does that make it not a chair just because it has an extra individual property that all other chairs might not have?!?!? Of course not!
This feature only disregards types if you chose it to do so! But It’s not a requirement that you do!

Again, I’ve already talked about features that solve your problem for how many steps are required to add properties to types, and by making relations panel more visible, etc.

What’s even the difference between a) creating a Type and a template and adding the Relations in the template only vs. b) creating a Type and adding Relations to the Type? Because if we get the feature with template-sync I would not bother adding relations to a Type, but just add them straight in the template.

I’ve already explained this. 1.) You can already add relations to a type and they are automatically added to all objects of that type.
2.) Templates are there to automatically set the visuals of a canvas on creation.

Templates are not necessarily about what relations something has. They are primarily about the visuals of the canvas. And secondarily, you can add relations not within the type for sub-classing/extension.
So, the reasons are:
1.) Extending default types by creating templates
2.) Sub classing by creating templates for each sub-class. and
3.) Different visuals for different objects.

And if you want to talk about Sets - that’s a completely different thing that is more database-style and has no relation to templates whatsoever.

Firstly, I need to apologize for coming off extremely strong and bunt above.

I’m going to further demonstrate to you uses of having individual objects have their own properties with some more realistic examples:
1.) Let’s say I make homemade knitted scarfs and other objects and each thing I made can have it’s own unique characteristics. Or sometimes I might not have all of one knitted scarf. I can make a “Knitted” type with a “Category” property within that type. In this case, there is sub-typing within the category property. But then I can add structured individual unique properties to each individual handmade knitted object. In a db-only system, this information might be specified under just a textual “Notes” field, but with Anytype I can have structured individual properties for each object, and these properties can be shown right on the graph!

2.) Let’s say I have a “Book” type and I have different genres of books. Some genres, like fantasy books, might have properties that other genres don’t have. I can create a subtype with a template for the “Fantasy books” genre in case I end up having more than one Fantasy book! A property like this might include “constructed languages” or something else.

3.) Note-taking. Each note is completely different, but they are all still Notes. I would want to be able to collect them all as one type, but each note can have different connections based on the content of what the note talks about.

4.) Wiki! Within a text wiki, you would usually connect to things by just linking to other pages within the wiki. Instead, Anytype has ways to directly link to other Objects! So I can have wiki pages that link to other wiki pages, images, audio files, notes, other Objects, etc. And these would be individual links, and not all wiki pages must have them. In this case, what links you have is on an individual basis, and is decided when you’re writing the wiki page, so just adding the object to the canvas would do and you don’t have to add a property to the type for every single one of these.

2 Likes

Valid points. But for someone like @nesdroc who is used to notion, it might be certainly hard to transition into this alternate modelling of data which is what I guess the OP is talking about.

The last time I used notion is more than 2 years ago, so I’m not sure if this is how it still is. But when I used it, a table and all of its templates share the properties. i.e, adding a new property to a database will list in under each pages of the database as well. However, in notion, I don’t think there used to be a way to add the relation inline inside the canvas though. In order to model data in this way in anytype, one has to create a template to display all relations at the beginning of the page, but when a new relation is added to the type, it will not be added to the list of relations and one has to manually edit the template to add it. Manually adding it to the template does not add it to the previously created objects from that template as well.

This is also true for the reverse, deleting a relation from a type does not remove it from all the previously created objects. This behavior makes sense, but might be confusing for new users. Whereas in notion, removing it from a database removes it from all its object as far as I can remember.

The best way to handle this preserving the current flexibility is to:

  • Display a popup asking a user whether to add the relation to the type when a new relation is added to a set or an object. This way, if the user selects no, the current flow is followed whereas if they select yes,the relation is added to the type itself which inturn propogates to all the objects of that type. There is no feature request for this AFAIK, please feel free to create one for it after searching if any such exists. If not, I’ll raise one in the next few days
  • This has to be done for deleting a relation from a type page as well. When you remove a relation from the type page, all the previously created objects of that type will still have the relation. This makes sense because deleting relation from all objects of that type is a destructive change since it might contain some value. But since the user acceptance is required through a modal, this is not a problem and would make it easier to remove relations from multiple objects as well
  • As far as templates are concerned, it is only used as a blueprint during object creation. Therefore instead of syncing it with all of the objects created from it, which makes the object coupled to the template, it would be better to have an option to apply a template to an object. By this way, when you update a template, you can apply it to a page whenever you feel like it and only when needed

Anyways, here is the one for template sync

And the one to apply manually

These are useful features which would improve the experience of the vast majority of users. Other niche features which only few would require could be made as a plugin by the community once the plugin system is out. Therefore, one could even make a plugin go mimic the notion experience on anytype

Anytype is certainly flexible, but being flexible should not be a reason to have bad UX. The best way for Anytype is to be

Simple By Default, Powerful When needed
- KDE

5 Likes

I think you’ve linked some really great suggestions.

People can argue all day about how the current way is similar to whichever concept in programming, but at the end of the day, what matters most is usability. Objects are grouped into type because of their similarities, books have similar properties to other books, class notes have similar properties to other class notes etc. and having similar relations and properties reflected across objects of a type is the most straightforward way of thinking about it for lay people. There’s a lot of extra effort in going back to add a new relation to all old types. I think a retrospective way to apply templates, or the ability to edit the default relations on each type (and have them apply retrospectively) would make anytype a lot quicker to use.

5 Likes

A lot to catch up on. I’ll only partly manage. Thanks for all the input and participating in the discussion. Obviously a bit puzzled by some of it, but I’ll try not to get caught up in that.

To the chase: Essentially I’m reporting a UX problem. I’m evaluating what I see and experience. I have no idea if the UX problems I’m encountering are going to be fixed down the line or are as intended. The Anytype team nudged me to report my experience. All I can report is that for building Sets of (similar) data it doesn’t feel like an end user tool, but an admin one. Like setting up your website in Drupal vs. Wordpress. Everything I’ve seen so far has led me to believe that Anytype is aiming for the latter segment to be able to use the app too, which is not what I’m experiencing.

I get how it works and can work it too, but that doesn’t mean I think works good. You can explain me all the underlying concepts and such for Types, Relations, and Canvas, but I’m still left with the question of what you get out of Types vs. just making a template (with the Relations you want). Again, this is not meant as a verbatim question, in that I don’t know how Anytype works (in that every template has the relations of the Type and all that, just hidden), it’s a question saying that I don’t see the value (with the way the current experience is).

Imagine a competitor software called Notype. In that you don’t have Types, but only Relations and Templates. That’s essentially what my question boils down to. What are you losing? Because right now Types are not giving the experience I imagine most people would expect - structure (also given the examples books, films, contacts, etc). Because you have no way of ensuring your objects abide by this unless you, yourself, keep a strict procedure/process for how you work with each object. Just imagine three people adding books or contacts… Yikes! Gonna be all different.
Currently there’s too much overhead and risk of Objects going rogue. Either because of user(s) mismanagement or because of great ideas you had two years ago, but seen in today’s light you wanna do different.

One thing is building stuff, another maintaining it… and I want both to be simple and straightforward - and I’m not currently getting this. I get that I should go and make some sort of feature report on this. I just wanted to be sure I hadn’t missed anything… And also, if this complicated and unintuitive behaviour is intended then Anytype is just not for me.

2 Likes

I do not get this at all. You are reporting a UX problem, but then you switch back to acting as if Anytype didn’t have types. Anytypes does have types! And they are followed. There’s just redundancy with types and templates, that’s all!

Everyone agrees that maintenance should be simpler. But you don’t do that by removing useful features, you do that by the very suggestions that have already been provided to you - you do it by fixing the problems.

People need to stop misrepresenting other people’s arguments (and then agreeing with them later seemingly without even realizing it). None of this boils down to “how the current way is similar to whichever concept in programming”. What it boils down to is you can have both fluidity and structure, but the UX currently involves a lot of repetition and moving around. Now let’s give suggestions to fix the actual problem can we?

Your question on Templates vs. Types is a valid one in that Types should be one Template (like a default Template), imo. Because, yes, Types are almost useless if we can just put everything in Templates. But then those Templates essentially become like Types, and it’s all a bit fuzzy atm. I’m not sure the best way to handle this, but I think having Types have their own default template that matches all of the Type properties might be a start, idk. But then again, I might change my opinion on this later on, who knows. I already have to begin with.

We both agree that having Types is useful. That there are many objects that share properties because they are of the same type. Nobody is disagreeing with this. What I am disagreeing on is that we should not get rid of the ability to have individual properties unique to an Object. It doesn’t have to be the default way of adding relations, but it should still be possible, imo.

1 Like

I’m going to link another set of relevant issues here:

This last one is important. The devs have already talked about making a sidebar (it’s in the roadmap), and it looks to me like the intention is to make properties more visible. So this already covers the weird complaint of Relations Panel being inexistant.

2 Likes

There is one more thing that I do have to bring up regarding suggestions for changes in the UX.

It seems like the idea other people have is that when adding a relation to an object of a type, it is intuitive that that relation then gets added to all of the objects of that type. I think I have to disagree. If I add a relation to an object, I added it to an object. I didn’t add it to the type. Why would I expect changes to an object to affect all other objects when they don’t when I add text (or anything else) to an object? What if I decided to change the layout of one Object? Would I expect that to change the layout then of every other object? I personally wouldn’t.
I do not think that is intuitive at all. It’s confusing and will lead to trip-ups when people think they are just adding to an object when really they are changing a bunch of other objects, lol.

As always, on a such important feature the user should have the choice. Personally, I see an interest in both cases.

1 Like

This is yet another UX issue and ss the staff doesn’t really communicate about their intentions about the UX (or anything else really), we don’t even know if they are aware of their flaws in this domain. We can only hold on to one hope, and this unknown is deleterious.

If communication is the core of a good relationship, they should consider the effect of our involvement not being heard.

I’m not sure if you are aware of it, but there is an upcoming community town-hall where we can discuss these things with the developers directly. You can find the link to the event on discord. Feel free to join it

1 Like

I clearly haven’t heard of it :smile:

You see, this is another sign of miscommunication in my opinion. It would be better to centralize the communication channel rather than asking people to find such information on Telegram and now Discord… It would make more sense to capitalize on the forum of your own community.

One of the very principle of a community is not to be scattered, right?

2 Likes

Yes, both sides are 100% useful. But what I meant was changes to a type should be more explicit than just adding something to one object. If I change an object, I only expect that object to change. If I change a type on a type page, only then do I expect all the objects of that type to change.
So, for me personally, the intuitive thing is that it should not be default that changes to one object change all other objects, but rather that you explicitly say this is what you want to do within the program, for example, a new button/option saying “Add New Relation to Type” - this can even be placed within the current Type menu thing here:

1 Like

I misunderstood, my bad. You are totally right, it makes total sense Indeed.

1 Like

It’s fine :slight_smile:

Honestly, if this whole conversation were talking about a programming language, I would be making the exact opposite argument than what I’m making right now. But because this is a note-taking and information storage (knowledge base) thing, I just feel like the more intuitive approach is the one that is not like most programming languages (that have strict typing) and more like real life, with fluid typing (a balance between strict and dynamic typing and prototyping) and fluid properties.

1 Like

I might be wrong here, I got a bit lost on all the comments, but I think that quote resumes what @nesdroc meant from the start in regard to that topic…
Though I agree he is trying to make multiple points in one post, so that might the confusing part.

About this, the problem IMO is that we can’t (at the very least) add relations to default types (I haven’t found a way). I understand it’s more complicated to implement the ability to remove or modify default relations, but it may force people to create new types that are basically copies of the default ones, just to have more control.

1 Like

About this, the problem IMO is that we can’t (at the very least) add relations to default types (I haven’t found a way). I understand it’s more complicated to implement the ability to remove or modify default relations, but it may force people to create new types that are basically copies of the default ones, just to have more control.

I agree - the ability to modify (or at least add relations to) default types would be useful, even with the workaround I provided early in the conversation. I’m not sure if this has already been a requested feature.