Templates & Relations v Type & Relations

[Pointswell]

So there’s a whole bunch of debates on Template v Type.

I would expect that a Type when you add relations to it not update the Template automatically (which is how Anytype behaves).

I would expect that if you add a Relation to a Type and then add it to a Template that it then show up on every object using that template (in the same way as a database form works - you update the form and then whenever you look at data with that form it shows the same layout to every piece of data). Anytype however works like an MS Word Template, once you make a Word document from a template that is the Word document, if you change the MS Word Template then new Word documents get that new template. In Anytype that seems wrong, but has been covered extensively elsewhere.

I assumed wrongly that if I create a Type, don’t add any Relations to it, but instead go to a new template and add Relations to it that these would then show up on the Type but it doesn’t.

There’s a lot of duplicated work associated with creating a Type:

• Create Type
• Add Relations
• Create Template
• Re-add the Relations to the Template
• Hope the Template is correct the first time

I was expecting that:

• Adding a Relation to a Type made the Relation available to everything related to that Type
• Adding an exising Relation to a Template makes that Relation available to every Object using that Template
• Adding a brand new Relation to a Template would add that Relation to the Type (and be visible on every Object made with that Template)

Otherwise there’s a lot of work just maintaining what you’ve put in.

[Pointswell]

Further playing it seems that a Template is an object in and of itself and quite separate from the Type that it was related to so if I add a Relation to a Template this is completely unrelated to the type

In the image below I created a Type, then I added Name, Address, Email and URL to it. Then I created a template and realised I had omitted Phone from it, so added this on the Template.

This is very confusing, I’m reasonably competent but I am really not understanding the interaction of Template Type and Object at all.

Also adding
/Phone

presumably yields a different result from
/Relation [select from the Type’s relation Phone]

[isle9]

Relations are per-object, you can add any relation to any object that you want regardless or template or type.
When you “add” a relation to a type trough the library, you’re only adding a suggestion that will show up in the relation menu of every object of that type. You’re not technically adding those relations to those objects.
On the other hand, when you add a relation to a template, you are adding the relation itself to to template and any object that is created trough that template.
These are all separate things. This way, you can add relations that should be used in all of your objects of that type to that type, and then only add relations that you want to be used in specific templates to that template.

@Pointswell

I would expect that a Type when you add relations to it not update the Template automatically (which is how Anytype behaves).

@Pointswell

. Anytype however works like an MS Word Template, once you make a Word document from a template that is the Word document, if you change the MS Word Template then new Word documents get that new template.

Yes, templates are a manual process right now. Hopefully in the future we get the ability to automatize them. Something like this:

Embedded Templates

Is your feature request related to a problem? Please describe. I have certain projects that reoccur on a regular basis and would like to create a template for it. To manage progress in the project, I would like to create some pre-defined tasks alongside the project every time I create a new copy from the template for a project. Right now creating objects in a template makes them their own objects outside of the template. Describe the solution you’d like I would like to create a template for a…

[Pointswell]

I’m very confused by the Templates having Relations beyond the Type and the resulting Object created. Complexities like this are going to create a barrier to adoption outside of a niche highly technical user base. Unless that is the target user base in which case I’m an outlier.

My expectation would be that Object is of a Type or which there are multiple different ways of viewing or creating the Object. The reality is that an object may be created from a Type (the basic template) or a created Template but that Template may extend the Type either intentionally or accidentally.

[Angelo]

How would a Template “extend…accidentally” the Type? The purpose of Templates is to carefully tailor them to suit a specific use-case.

Templates also encompass not only Relations; but a whole suite of features and layout structures that may vary significantly depending on the use-case.

[Pointswell]

Accidentally because it’s not clear that is how it works. As in I added relations to the Template expecting to save time only to find that the Relations added to the Template are not added to the Type.

The question of who is the end user is key here. If you need to be expert in OO to use Anytype then it is a very limited market.

[Angelo]

Anytype can be as simple or as elaborate as you prefer. It sounds like there’s some confusion as to how Templates are utilized.

You have the flexibility to add as many Templates as you’d like for a particular Type. When you create a new Object directly from one of these Templates, it will adopt any Relations and the complete layout design of that specific Template.

Additionally, in the Library, you can select which of your Templates will be the default. This means that any Object of that Type, regardless of where you create it in your Anytype Space, will adopt the Relations from the default Template.

---

@Pointswell

I would expect that if you add a Relation…to a Template that it then show up on every object using that template

Templates are not integrated with or actively managing the Object in any way; they simply provide it’s initial structure. Any subsequent changes to the Template will have no bearing on previously created Objects.

This would be an undesirable outcome, and I’ll illustrate why with an example: Suppose you have a Type named ‘Band’ with a generic icon in its Template. You create a Band Object for ‘The Beatles’ and replace the generic icon with their band photo. Later, if you change the icon in the Template to an emoji, all 1000 Bands in your Collection would have emoji icons instead of their Band photos.

---

Have you checked this tutorial video in our Docs?
(I’ve just updated that section with this text because I noticed it was empty )

[ccrawford]

@Pointswell I see both sides of this, but I don’t think they are going to change how Types work because it’s a core part of their design.

If you want to change the relations for an entire Type (including existing objects) you should be able to do so by editing the Type directly in the Library.

I think the current system is actually pretty good. Like @Angelo said, it can kind of be as simple or complicated as you want. I like to keep the number of Types I use pretty simple, so the ability to use different templates for one Type is nice.

[Pointswell]

I’m not suggesting that there is anything wrong with Type as a concept or that it should be changed. The nomenclature of Template and how it behaves is confusing and unclear.

One would expect that creating a Type and then creating a Template for that Type and then adding Relations to that Template would be adding them to the Type as that is what they are associated with.

As it is the work flow for creating a Template is way too many steps to include what has already been created for the Type. Similarly there are way too many ways to create a Object with data (eg from a Set) which doesn’t then show up on the Object.

Like I keep saying: Who is the anticipated user of Anytype. If they are meant to be mass market then this is confusing and unclear to the detriment of take up. If it is someone with a PhD in OO concepts then everything is fine as it is but the market extent will be much much more narrow.

[Pointswell]

@Angelo

This would be an undesirable outcome,

There are two undesirable outcomes, the one you describe and the one where you have to iteratively add elements, create objects and return to change elements to get to the output you actually want.

Nobody in the history of computing has designed the correct code and layout the first time, and users compiling their BrainOS in Anytype will be the same. It is too cumbersome to create what I will call a Layout (to avoid a repetitive discussion on what Templates are or are not) then create 5 records then on the 6th realise there is a twist that actually you should have included in the Layout from the get go. Then you add another 20 records, then you decide that no, the layout flow is incorrect. You’ve now got 20 records to touch individually to get into the format that you want to see.

Or you create a Set you add the relations that you want to the Set and merrily start creating hundred of Objects. Then you go look at one of the objects and you’ve forgotten to configure the Set to use your new layout by default.

Layouts should contain placeholder text by default and actual data by active choice.

If the intention is for regular users to pick up Anytype then as it is at the moment it’s too confusing and too long winded.

All of this is said with the best of intentions and the realisation that this is beta software.

[ccrawford]

I understand that it might not be intuitive (it wasn’t for me), but objects of the same Type can exist with different relations. This is different from how apps like Notion work, where if you add a property to one object in a database, it adds it to every object in that database.

For example, if you have two objects of Type “Note,” you could go to object one and add a new relation, this will only add the relation to object one, not any other objects of Type “Note.” However, if you go to the settings for Type “Note” in the Library, you can add a relationship here, and it will add it to all new and existing objects of that Type.

Please note, if you do this, the new relation will be in a different category (called “from type x” on the relations panel for the existing objects.

Once you fill in the value, it will move into the “in this object” category.

Also, if you create an object with the default “blank” template, any relations that do not already have values in them will be placed into the “from type x” category (which is most of the relations besides the locked ones). Again, these will move to the “in this object” category once they are filled out.

If you instead create an object from a custom template, you can add relations to that template (whether or not they are also added to the base Type), those relations will show in the “in this object” category even if they are empty because you’ve manually added those specific relations to the template.

Again, this may or may not be intuitive but that is how it currently works. Once you get used to it, I think it gives you a lot of flexibility for how you use the app. That being said, it might be nice to have a toggle option in settings to simplify this behavior.

Maybe the default behavior could be a more traditional system where if you add a relation to an object, every object of the same Type will inhereit the relation. Then you could toggle the setting to the more advanced (current) system to have finer control. This might be more confusing but if done properly, it could be helpful. @Angelo thoughts?

[Pointswell]

@ccrawford

I understand that it might not be intuitive (it wasn’t for me)

@ccrawford

Again, this may or may not be intuitive but that is how it currently works. Once you get used to it, I think it gives you a lot of flexibility for how you use the app.

I am a product manager. When I hear statements like this it sets alarm bells off.

Who is the target user?