My thoughts on the recent changes to Types, Queries and Templates

Talk
, ,
1

Hey guys,

I was not sure where to convey some of my thoughts on the recent changes to the structure of Anytype, but I decided to put it here and on the Nightly space, and maybe after, on the community forum.

I know that the current changes to the structure of types, templates, etc. are aiming at improving the core UX and more importantly, lowering the steep learning curve for new users. And I know there are lots and lots of positives to it, but for now, I want to voice some of the things I think has taken a turn for the worse.

For instance, take the current structure of “types” and “queries”. Now that we can see all our types in one database “view”, I can’t help but notice that “queries” doesn’t have a place anymore. If you guys give us the option of adding “inline type databases” to our objects, the queries become absolutely obsolete. Keep in mind again, that I’m not saying it’s necessarily a bad thing nor it should be any other way. I’m just saying that as things stand, “Queries” doesn’t do anything more that what the types page can give us. For instance, as you guys have seen, way back when, I had a type called “movies” which I made a set for it to showcase them in different different views: “Recent Additions, Watchlist, etc.”. And I used the inline feature to add them to my other objects. Well, apart from the inline feature, I can do all of that with Types page to. So, why do I need Queries anymore? :thinking_face:

The same goes for the templates; Before, I had a type of “human” with several templates for different purposes such as author, actor, etc. which all had different relations ( properties ) for them and the only similarity between them was that they were humans. Now, because certain things are being chosen at the type level, for instance, the properties that I want them to be shown in the header. So, now I’m forced to create new types for my different objects of author, creator, etc. and I can live with it. But then again, this begs the questions that doesn’t this almost diminish the power of “templates”? I mean, can anybody give me showcases that you have the same properties for a type, with the same properties shown in the header of it, but need different templates for arranging the blocks?

My point is that I don’t have a problem with the current changes per se, it’s subjective but my question is that are there really empowering? As things stand now, aren’t some feature such as templates and queries redundant? :thinking_face: I think, if by restructuring and introducing new feature, they don’t overlap with the old ones or lesson their place and importance, it could add more value to them.

2

This is not true. You can do all kinds of queries, not just type based ones. You can set the source also to a property or multiple types.

Having dedicated queries also helps for inline ones as they are not supported on mobile and always fall back to the “master” query.

I for example have “company” and “person” contacts and everything for me is a contact. I just devide them by tags. For a company or a person I have a different template with partially different content.
I might have the same properties but I don’t need to show every property inline if it is not needed for a company for example.

3

Agree with @krst .
I need them, I’ve got lots of them.
Two quick examples:

  • a query that retrieves all imports (because each import creates its own collection… not great, but it’ll probably never be fixed), so I can have a global view and manage everything from there
  • a “Files” query that retrieves Audio, Files, Images… anything that’s not a text object

(the fact that inline versions are so problematic remains… problematic ^^)

4

Sure that’s true, but personally I’ve never created a query based on properties :thinking:. Just out of curiosity, what properties do you have queries for?

I’m confused, how dedicated queries help on mobile in case on inline one since they’re not supported?

5

Just out of curiosity again, don’t you manage your imports immediately after you’ve imported them to your space and then delete the excess? :thinking: I mean, why do you need to have such query afterwards… I’m having trouble seeing its use case :thinking:.

6

For example I use some properties, like tags, across types. I then have a query that queries all “work” related tags as the starting point. I then can filter more granularly if needed. This will get obsolete I guess when tags as objects is released.

I also have an inbox query that lists everything with the tag “inbox” (every new object gets this tag in my templates, so everything I quickly create anew lands in my inbox)

Another example is I have a query that lists all objects that are linked or related to the current one. this can be all kinds of types in there (meetings, notes, files), everything that links to the current object.

For example I have a “home page” with my inbox query as a dedicated query that is just 1:1 the standalone query. on desktop I see it inline, on mobile I click on it and see it in a separate view.

edit: the advantage of Anytype imo is that everything can be a starting point, I can come from a tag or a property, a type or what have you. the more flexible it is the better. if you don’t need a feature and it doesn’t cause friction to your workflow, just ignore it. but others might find it useful

7

two examples where it came in handy:

  • testing purposes to test reported bugs or to develop my Evernote conversion tool), I’ve a space with dozens of imports (and sometimes the same data imported several times). With my query, I can see them all, follow their evolution, compare versions, retag everything as I wish, etc.
  • Because I import according to need: Evernote doesn’t allow global export but per notebook (so several batches); and for Notion, it avoids having a big mess all at once. The query also allows me to manage and classify everything (don’t forget that when I import, it ends up in an “Import_xxx” collection, which is pointless).
  • I can also cite the times when I couldn’t find a document I thought I’d imported: hop, query everything imported and I find it (trying keywords via the search didn’t work).
    image
    image283×325 5.69 KB

A last example : did you try to import something from ANY Experience Gallery?
There’s a big problem with it: you have a collection with the objects of the experiment.
But not everything… it doesn’t understand type and relationship.
This is a big problem, you’ll have stuff lying around even if you think you’ve deleted everything.
If you want to test a bit of everything, say goodbye to your space…
Hope this gets fixed someday!
In the meantime: query → Import type = Anytype + Origin = “Installed from Gallery” “et voilà!”, you’ve got the complete list of stuff to delete (you’ll have to distinguish between them if you want to test several at once… really, Anytype has to mark them!)

8

Thanks for the examples. I personally use tags to further categorize and sort down my types, and don’t use them as a global tool. :thinking:

I understand :thinking::+1:

Yeah, that was one of the benefits of how Anytype is! But, I was thinking maybe less overlap between the features could potentially empower Anytype. I imagine, the workflows you mentioned was there, even before the “Primitive” update and it didn’t affect your workflow much. It didn’t hinder mine either but I saw that many of my workflows can be done in multiple ways, which I don’t personally think is necessarily a good idea nor can decrease the confusion for newcomers.

9

Thanks for the explanation. I have used the Anytype Gallery but only to test my own creation and not others. So, I always know what have been imported and immediately managed them. But you are right. To be honest, I never imported from Notion or any other Tool in Anytype; hence, I haven’t faced with these kind of problems.

But you can’t deny that these kind of workflows can be important to some people like you, but the majority of people, with the current state of Anytype, can rely only on the types page without needing to create any additional Queries. You see, that’s what I was worried that the newly introduced features overshadow the previous ones, and we end up with multiple ways of achieving the same thing which if I’m not mistaken, was one of the main goals of Primitive update which the Devs were trying to avoid in the first place.

10

But then we get into a pre defined way of doing things and other tools might be a better choice.
This is also why I don’t understand why other people for example have demand for properties that are restricted to a collection. I don’t want to be restricted to anything. My mind is confusing, and the more possibilities I have to go wild about my structure, the more it helps me to create my own.

11

I understand what you mean but I don’t agree with your conclusion. To paraphrase that quote: “Make Anytype simpler, not simple”.

The fact that now Types incorporate a Query, does not mean that Custom Queries are useless. Removing Queries (which cannot be done, as Types would also lose that functionality) would mean that every query and view of a Type would be in the same place. I can’t imagine a Type with 101 views being an “improvement”. Also restricting max number of queries/views per type would not be an improvement.

There are a number of workflows that make no sense to some people and others that are vital. In my case, that happens even on Space basis. On some spaces I have no need for Collections, on others it is vital.

I see the primitives/Types with a default query being an improvement for types that don’t need much “querying”. But for other Types or cases, it can be vital!

Same with Types/Properties/Templates. Nothing stops you of having a template which adds a custom “local” property to an object. Or having Templates “pre-fill” properties.

In my opinion, the only thing I am missing from this system (meaning the primitives update) would be in the Type, to also specify a “header” and a “footer” (being the template the middle), and a easier way to add/manage local properties.

12

Yeah, good shout. This would be really useful with the essential properties in the header and those other ones that don’t need to be in your face, but are handy to have in the object at the bottom.

13

I very much agree. It’s useful to control the header at the type level. But I wish there was also some way to control object’s header properties without changing all the types. Some kind of “local header” for a specific object or template.

14

Doesn’t that exist already? To be honest, I have been having all my objects “in sync” with the type, but I think one can change the header of an object/note and just not “sync/reset” with the type settings.
Will test next, if not, I edit the message.

EDIT: was wrong and properties featured/header line is static/fixed per type.

15

As things currently stand, you can add a local property to an object, but the only way to make changes to the properties appearing in the header of objects, is at the “type” level which affects all those objects.

16

Ohh sorry.. I think I got where I misunderstood and was wrong. I mean the “Featured” in the header “line” and I was remembering that I can just add properties below that line at the top.
Yeah, double checked and “featured” are static per type. (I usually keep that line minimal).

You are right, the featured line is fixed/static per type. (although one can add “local properties” just below it)

Edited previous message to indicate this.