New feature names in Anytype

Talk
1

Context: We have embarked on a big initiative to make Anytype easier to learn and use. Part of this is rethinking how we name things in the product to be more understandable for a ‘regular’ audience—the pedestrian on the street, if you will. Nothing proposed here is final, we are providing space for input and discussion.

Intro: At its core, Anytype strives to be a safe haven for your digital life. Everything you do in the app should feel secure, private, and fully-owned by you. Today, people feel like the world is owned by landlords and corporations. They’re stuck renting and powerless. There’s real value and need for subscriptions to services, but there’s a line to be drawn on what should stay in people’s hands of ownership. We need to be in control of our knowledge and connections.

Why use Anytype? All your items are gathered in collections that are held in spaces you own. ‘Everything is an object’ is highly abstract. ‘Everything belongs in a collection’ is more relatable.

Request: We understand that new names is annoying for mature users of the product because it creates friction. However, given that the community here is fluent in Anytype, your understanding of how it works gives you the unique ability to express what things should be called. This topic is highly subjective, so let’s engage in good spirits. Here we go:

Object vs. Item

Object is great because it’s abstract and is an ‘industry-defined’ term used by a specific community–but it’s esoteric and unknown to 99% of people. Viewing ‘item’ in isolation seems not much better, but when you connect it to ‘items in collections’ it becomes more natural.

  • Task Object / Task Item

  • Bookmark Object / Bookmark Item

  • Audio Object / Audio Item

Type vs. Collection

Type is great because it’s abstract and also used in certain industries. However, it’s not immediately clear in the word what you’re meant to do with it. When you think of a ‘collection’, it’s obvious that it’s a container for many items. Additionally, items in a collection inherit the context of the other items—such as a book in a display cabinet (decor) vs. on a bookshelf (library).

  • Event Type / Event Collection

  • Movie Type / Movie Collection

  • Tool Type / Tool Collection

Queries vs. Curated Collection

Query is great because its usage is very clear in software circles. However, our choice of language with Queries as rule-based Type and Collections as manual-based Type was confusing, people didn’t know when to use which. In this setup, a ‘collection’ is for capturing new items while a ‘curated collection’ is to search and organise existing items. We will speak to the combination of the current implementation of ‘queries’ and ‘collections’ next week.

  • Query = Curated Collection using rules

  • Collection = Curated Collection by manual selection

Vault vs. Account

Vault is great because it clearly conveys a sense of security and privacy. However, it’s somewhat intimidating and not entirely clear to new users. With shared channels, chats, web publishing, and so forth, a lot of content is not ‘locked in a vault’ per se. Account is immediately understood and has no negative consequences.

View vs. Layout

‘List view’ and ‘calendar view’ is often used today to express the format objects are displayed in types and queries. However, a view should be the combination of sort, filters, and a ‘layout’. Thus, we believe it makes sense to draw that distinction.

  • List view vs. List layout

  • Calendar view vs. Calendar layout

  • Gallery view vs. Gallery layout

Property: Object vs. Property: Relation

This is not about renaming ‘property’ to ‘relation’. This is about the type of properties you can create (date, URL, text, number). When setting an ‘object’ as a property type, your goal is to draw a relationship between an object in one type to another. We believe this could be more explicitly expressed by naming ‘Object’ property as ‘Relation’ property.

Editor vs. Canvas

The content window displays many different types of data, and it’s growing over time. Page, task, chat, and possibly more like whiteboard in the future. Thus, we believe it could be beneficial to name the ‘content window’ canvas, because it’s a surface that displays a variety of content.

Channel vs. Space

The most difficult topic for us internally because the permission model and breadth of content types on Anytype differs greatly from other apps.

Channel

  • Pro: Represents who is connected/has access (membership/participation).

  • Con: Can be misunderstood as a chat channel.

Space

  • Pro: Represents where things live (container for content)

  • Con: Can be misunderstood as a workspace with granular permissions.

–

Thank you to everybody in advance for your contributions. :slight_smile:

P.S. Lists 2.0 — We will be sharing more about this at the Town Hall next week (17 Feb) and a detailed forum post will be made immediately after for those interested in diving into product architecture, features, etc. Let’s minimise sidetracking the conversation and stick to the naming.

FYI — the naming conversation around ‘Lists’ where the name ‘Collection’ was chosen.

2

Object vs. Item: item is acceptable but it doesn’t feel like a major improvement. Object comes from the software engineering world, but it actually also works well for non technical people.

Type vs. Collection: I don’t understand this at all. A type (a type of objects, as in a group of objects that all share similar properties) isn’t the same as a collection (a group of objects that are manually or automatically brought together). Type isn’t particularly inaccessible and changing it will not make Anytype more accessible in my opinion.

Queries vs. Curated Collection: please please please no :folded_hands:. Collection and smart collection, or database and smart database are the way to go here. A query is completely inaccessible and a curated collection is just confusing. Let’s keep it simple.

Vault vs. Account: yes! Vault is confusing and does not convey that we’re talking about a user’s entire account, which includes all its channels/spaces. Account is the way to go.

View vs. Layout: “a view should be the combination of sort, filters, and a ‘layout’” yes this makes complete sense!

Property: Object vs. Property: Relation: I am utterly confused here. Is the suggestion to rename property, which used to be called relation, back to relation? Property is a great, understandable name.

Editor vs. Canvas: the Anytype team has been using canvas for a long time and it’s become pretty natural for many of us on the forum. It also makes sense because an editor is more of a functionality or a tool, rather than a space/place. A canvas best describes a space/place.

Channel vs. Space: what is currently called a channel should be called a Space. That is the standard way these are called in multi-player apps similar to Anytype. And there can be two types of Spaces: chat-centric and content-centric.

I hope this helps :slight_smile: it’s nice that Anytype is thinking about terminology and such radical changes in order to make Anytype more accessible, but some of these are working fine right and shouldn’t be changed.

3

I think most naming conventions are understandable and logical enough.

You can have multiple Objects with different Types (Object Types).
Every Object has its own Properties (Object Properties).
You can either add Objects to Collections manually or Query Objects with specific Filters.

I don’t think this is too confusing and easy to understand.

In my opinion, renaming Vault could be a good thing but I would not choose Account as this is related to my personal Account (Username + Password).
I would suggest something like AnyPlace, AnySpace or SpaceCollection.

5

Property: Object refers to the property type.

image
image558×397 25.9 KB

6

Maybe let us choose our own “name” hierarchy? We can rename Types too (I renamed “queries” to “searches”), why not the most fundamental things as well?

For some its perhaps best to stick with something like “notes” – personally I like “objects”

Thanks for asking the community, I like such discussions

7

I think it’s good that the team is actively looking at the possibilities and ways of making Anytype more accessible for the average user. But I don’t think changing the names per se is the way forward to be honest.

I highly disagree of changing the name of the “object” to “item”. I mean, item is a couple of points you write in your lists, on a piece of paper, or in your to do list app. I really don’t think it has the magnitude of meaning Anytype intends. I suggest sticking with “object” and maybe renaming “types” to “Object Types”. This way people can understand that they can create objects and they have the choice to choose from various “types”.

With regards to the “View”, again I would stick with view for queries, and leave “Layout” for the objects and object types itself. I think it would further add value if Anytype works and spend time on adding more features and distinguishing different types of Layouts, for example “profile”, “task”, etc. I think in this regard, Capacities has done an excellent job of creating enough separation and distinction not to confuse the user, and in the meantime provide enough value for them to explore and use all of them.

And as for the last point, I think either “sets” or “queries” and even “collection” are all interesting choices. I don’t think any of them would be better than the other in a huge way! But If you want to streamline it I suggest you choose from these two routes:

  1. Either start coming up with specific/unique names in a sense that fits the rest of the portfolio like the “AnySync”, or “AnyStore”. I’m not saying this would be good but something like “Anybase” or “AnyQuery” would be distinctive to Anytype if you want to stand out.
  2. Or stick with the names that is already assigned with minor tweaks to how it works, namely treating the current “Queries” as the “smart - NAME” and collection the “Manual-NAME” and type one as the “Type-NAME”. In this way, the user understands that if it has the power to collect and call out information based on a set of rules, types, etc.

I personally think if Any team can come up with unique name incorporating the “Any” moniker, in addition to adding “smart" and “manual” to it, it would be self-explanotary.

I don’t think Account would be a good replacement for Vault as it refers to each individual’s account and ID rather than the set of spaces, channels, etc. Also going back to “relation” is a bit odd although I think relation was a more suitable name compared to “properties” but the average user would be more familiar with “properties” especially if they come from an app like Notion.

Last but not least, I really don’t like the name “Channel”. I prefer to have “space” and “Chat” although I have to admit the average user wouldn’t think a “Chat” would have the infinite capabilities of the 2nd brain of Anytype. I don’t know, Maybe, having “Chat” as an object, with the option of creating a “Main Chat” or “Direct Chat” in the space where there are only two people would make more sense but maybe that’s just me.

8

RE: Why the same name for types, queries, and collections

On the topic of why we’re exploring the merging of types, queries, and collections (and even ‘tag’ as a type) as a single name: it’s because why these features are used is very similar. They are used to group, navigate, and consume objects with a defined relationship. They’re all about making sense of the chaos.

Anytype is used in many different ways, and this particular Reddit commenter describes an interesting use case—they effectively do not use ‘types’ at all and primarily organise with queries of properties. If one looks at this system described, you could absolutely set it up with types as well, but they don’t because it adds a layer of complexity they prefer not to use. One way to look at it:

  • A ‘collection’ is a container that immediately gives definition to new objects you create through shared properties with other related objects. Everything belongs in a collection by default. This is what we know as an ‘object type’ today.

  • A ‘curated collection’ organises your existing objects into flexible arrangements to help you consume them in different ways. To curate these collections, you can do so automatically with rules or manually by your sorting. As an option, we could call it ‘Curation’ instead of ‘Curated Collection’. This is what we know as ‘queries’ and ‘collections’ today.

RE: It’s not hard to understand or confusing

I 100% recognise that the people here ‘get it’ and that’s why you’re here. But we know for a fact that many people struggle with understanding the object-based system—I’d rather we not debate this but see this as an opportunity for improvement regardless of its difficulty level. Anything we do to make Anytype (even slightly) easier to use is a win. And we 100% agree, to solve this problem it’s not about changing names—there is a lot more work to be done on a product and education level. However, this conversation today is just tackling one aspect.

You can rename things to your liking, that’s no problem. However, we need to have language around this as a default—it needs to in the UI, it needs to be explained, it needs to be in documentation, etc.

FYI — Edited the original post to better reflect what ‘Property: Relation’ is.

9

This time, I better let it to the native English speaking guys.
But I want to say that I appreciate it A LOT that the team asks us! :+1:

And that they made you, @kaye the messenger between the devs and us users, was the best choice in a very long time!
Each post from you is a delight in every way, you’re very clearly the best man for this task! :+1:

10

That is very sweet of you to say, thank you. But your non-native opinion is equally valid—the community comes from all walks of life. Please, express! :slight_smile:

I’m sorry that we didn’t shortlist the choice down to one of your many proposals in the previous community discussion. ‘Collections’ seemed to be what the community at large resonated with and it also make sense with our values about ownership and data sovereignty in Anytype.

11

Thanks a lot to the team for reaching to us and to @kaye for exposing things so clearly!

Here are my tldr; cents:

Object vs. Item

“Object” feels right to me. Admittedly, it may sound a bit esoteric at the very beginning, but it is not difficult to understand and the initial shock disappears soon enough.

Type vs. Collection

This one took me by surprise, but the idea of superseding “Type” really appeals to me. Though “type” is a good term for the concept, the word is so generic that, as a starter, I found it difficult to tell one thing from the other when I read about “types of properties” or similar things. “Collection” seems right if this is what queries will be called in the end.

Queries vs. Curated Collection

I would rather use “Collection” or “Smart collection” for Queries and “Curated collection” for present Collections. After all, it is the user who “curates” a collection by selecting the objects included in it. Unless I totally lost the point here, which is highly possible being Friday.

Vault vs. Account

I also think “Vault” is great. It is a very specific term that I find unmistakable in English. The Spanish translation is quite difficult, though, because in Spain it mainly refers to an architectural feature or a descriptive term too long and confusing for its purposes here (“cámara acorazada”); I used “Arca” (meaning “chest” or “safe box”), but then I saw some Spanish-speaking users here re-translating it to English as “Ark”, which is another of its meanings. With terms, you can never win. But I am definitely against “Account” for the same reasons exposed by other members.

View vs. Layout

I prefer “View”. But “Layout” works as well to me, though it sounds somehow more rigid.

Property: Object vs. Property: Relation

I find both equally confusing and would rather prefer something more descriptive in the lines of “Link to object” or “Related object”.

Editor vs. Canvas

I like “Canvas” more than “Editor”; however, it suggests a degree of freedom we currently don’t have, like rearranging things freely (as opposed to using columns), drawing lines, etc. So I am not sure a change would be beneficial here. It could lead to wrong expectations.

Channel vs. Space

I understand the potential misunderstanding with “workspace”, but I find that “Space” is generic enough for new users to quickly see the differences.

12

I’ve admittedly been very slow at building my understanding of Anytype over the last 8 or so months for personal reasons. Although one primary reason is the contrast with my day job requiring to maintain understanding of the more traditional data structures within a cloud environment verses the concept/architecture that Anytype is building around.

After the mission statement, one of the first things I read that really piqued my interest was “Forget what you already know about knowledge management tools“ (although my mind read “databases”). This set the tone for the rest of my initial read of the docs, and the object oriented structure described really resonated for me. I actually immediately started writing down the terms used on a notepad to have a parity of what I already knew to what the future (Anytype) should be… unfortunate timing on my part as shortly after some terms/definitions changed (sets → queries, etc), but I know changes/pivots are a part of products still in development.

I think the point I’m trying to express is there is some inevitable learning curve to this platform that is important to the technical reality of it’s development. I understand and agree with trying to soften that curve as much as possible, but I do believe the current state of terms is pretty solid and this discussion will be a good path to finalizing the collective understanding. Apologies, I know didn’t offer specifics but I remain adaptable to how things are named as long as the core function is not greatly altered as a result.

13

Cool changes. Just would have preferred Smart Collections instead of queries. For the changes, with tips and tutorials, adaptation is possible within a week.

14

I’d view the naming as a complete package and assign a complexity budget to it. You can have some technical stuff, but for example with Objects and Relationships naming you are going to go past your budget.

Object vs. Item

Object is sortof an abstract term, but Capacities seems to just go fine by it. I prefer Item, but I don’t think it’s easier to learn per se in the grand scheme of things.

Type vs. Collection

I like Types and it says AnyType on the tin! Keep it
Collection doesn’t tell me that I can have multiple views of the collection.

Queries vs. Curated Collection

I prefer Query, but it is kinda technical term. Curated Collection just does not roll of the tongue, it’s long and not easy to remember.

Vault vs. Account

No preference here, I use vault more personally, but I’d imagine teams might prefer accounts.

View vs. Layout

Agree here, make a distinction between layouts and views. Layouts compose with filters to make a view.

Property: Object vs. Property: Relation

Relationships don’t tell me in what way the data “flows”. Objects or Types have properties(it’s in the name!) and thus tell you: “a movie has a release date”. “a movie has a relation with release date” is too vague.

Channel vs. Space

I think the misunderstanding with chat channels will happen quite easily, so I’d prefer space.

15

You convinced me on the fact that item makes it look more like a piece of something bigger and it’s good. I’m not sure it has enough impact the change tho, so I’ll remain neutral on this…

Type. It’s the nature of the object. Yes, can be annoying to choose a main nature but we have properties for those and one can just use properties for that issue.

Dynamic/Smart Collection/Base. Curated and automatic are opposites.

Neutral on this one too. If the future holds federation and stuff, probably it’s better to keep vault to use ‘‘account’’ for the group of addresses or identities.

The layout is part of the view. The view called ‘‘abc’’ has the ‘‘grid/canvas/list layout’’. View for views and layout for layouts, 100%!

I’m not sure I understood this tbh and i’m not sure of where in anytype to find this

edit: I’ve seen philip screen, maybe property: link to object? Neutral on this one.

Editor, because hopefully we will have a canvas (whiteboard) one day.

Space, because a channel is a particular type of space, not viceversa.

I’ve been already prolific enough on the anytype space chat so there won’t need to copy paste here

16

Object vs. Item

I actually don’t think object is difficult for most people to understand. It does have a technical background, but not so much so that I don’t the average person on the street can understand. Object is a pretty generic word that can be used for anything. Which is why I think it fits here. You can create any kind of object with whatever properties you want

Queries vs. Curated Collection

I’m fine with using query in that way, but when I think of collection I don’t think of a bunch of manually selected things (which may or may not be different). Typically in my mind collection means a group of items/objects that are all the same (or similarity). For example I might have a collection of apples or a collection of fruit. But I would never use collection to describe a group of items that included things like animals, cars, and books. Yet this is how collection is (currently) used in Anytype. You can group a bunch or fandom object types into a collection. Not sure what a better alternative is, but I think a collection should be a group of the same object (ie. this post Help with the naming of Anytype's 'List')

Vault vs. Account
I agree that vault is a bit confusing (and has been to me). Some applications have “vaults” within their main application (eg a note taking app that stores everything in plain text except for what you put into the vault). For Anytype the whole application is your vault. So I agree using the language of account is better here.

View vs. Layout

a view should be the combination of sort, filters, and a ‘layout’

Agreed

Property: Object vs. Property: Relation

I already though this property was called relation? If not than I agree relation is good.

Editor vs. Canvas

Why not just call it the “content window?”

Channel vs. Space

Con: Can be misunderstood as a workspace with granular permissions.

I thought there was mention of adding more levels of permissions to the spaces? Either way I think spaces is better. Typically other applications (Discord, Slack, Matrix) all use channel as being apart of the same server. In Anytype the spaces are more like servers. Therefore, I think you should stick with sapces here.

17

I fully agree with everything you’ve written here @dzlg , I value keeping the naming consistent and meaningful rather than changing it for the sake of simplicity.

That said, I think the real challenge isn’t about names at all. Renaming things rarely solves confusion in tools like Anytype. The truth is, the users drawn to this kind of app don’t actually fear complexity, they enjoy it. Look at Obsidian: it’s opaque, sometimes hard to grasp, yet that’s exactly what gives its community a sense of mastery and distinction.

What really makes a difference, in my opinion, are three things:

  1. Consistency: once names and structures are set, they should remain stable over time. The core terminology in Anytype changed to much in the last months and its not a good thing
  2. Community: an engaged, supportive community that helps newcomers find their way is far more valuable than a new naming scheme.
  3. Communication: regular, clear, and inspiring communication from the team, like what Capacities or Raycast do, where features are introduced through stories, tutorials, and examples that make users want to explore.
18

I think the core issue is the fuzziness of the conceptual model. You introduce the concept of objects but when you go to make an object, all the actions say “New Type.” I was a bit confused by that when I was first learning how to use Anytype. Other relational database tools have a clearer conceptual model. Usually it’s something like a database contains tables; tables contain records. Records have fields. Fields have types. Databases or tables have views of the records. And the interface is very consistent with that terminology and reinforces that visually.

Right now I see Anytype’s conceptual modal as: a space contains objects; objects have types; object types have properties; object types have views. Queries are a view of an object or property but are also an object themselves and can contain views. Collections are a group or view of multiple types of objects and are also an object with views. It’s a bit muddy.

Something clearer might be a mix of what you proposed and how it works now—a space contains types of objects; object types have items. Object types or items have properties. Properties have property types. A space has displays (or arrangements?) of items. Displays can be organized by rules or manual selection. Displays have views. Views have settings which include things like layout, property visibility, sort, and filters, etc.

I was confused by queries and collections and it took me a while to understand the difference. The word collection always trips me up because it feels more permanent and rigid. I think of like a collection of Pokemon cards. They are all the same type of object that I display one way. Like I’m putting things together in a folder and I can’t reuse them elsewhere. I think words like View, Arrangement, or Display convey more flexibility and less permanence about the organization of the objects within it.

I also would not call an individual query or collection an object. I would pull through the object name in the interface—“Add a Display” or “Add note” not “Add object.” Or you should conceptually distinguish views from objects in the interface even if there isn’t one in the backend.

If your conceptual model uses the metaphor of physical objects and how people interact with them in real life, make the language consistent with that. People don’t “query” objects irl. They group, arrange, or view them.

It would also be helpful to relate Anytype’s terms to terms in other similar programs like Notion or AirTable in the docs. Saying something like “a type of object is like a table in AirTable” could go a long way for people bridging their mental models.

Re: property: object vs property: relation—I think something like Property: Linked Object would be clearer.

19

Generally fine with any decision that team and community conclude, but it feels a little lifeless to make the direct comparison between two terms.

  • Object are things we interact with in different ways (e.g. object like tools, Subject+Verb+Object); items exist.
  • Type/Layout sees through the surface content and capture the common elements/structure; collection/view displays a granted structure.
  • Vault addresses the data; account addresses the user
  • Editor focuses on line/text based materials; canvas allows expedition across the whole surface.

The terms we have used so far convey the potentials to what can be developed - a great vision where Anytype can reach (that’s why I like object and relation); and now we are perhaps moving towards accurate representations of existing features (perhaps because of the contributions of German minds).. Perhaps there will always be a gap between what it is now and what it is to become…

As far as naming/conceptualisation approach goes, it is probably way harder to thicken things up after it being flatten, than to enrich things with details.. Being flexible and formless is not a bad thing… the term can settle, but our mind can still journey, and the embedded meaning towards these terms can continue to expand.

Have fun and enjoy the exploration of AnyWorld :wink:

21

Volunteering my ideas:

  1. Object → Instance
  2. Type → Blueprint
  3. Query → QueryResult
  4. Vault → Home, Space → Room
    This actually gave me a bit of pain. I wanted to have a ‘Space’ which would be special because it would store ONLY sensitive data like passwords (maybe), documents like social security card, driver’s license, home deeds, … . I would have named it ‘Vault’ (like the vault of a house), but ‘Vault’ meant something different in Anytype. I suggest using the ‘home/house contains mulitiple rooms’ metaphor, instead of ‘Vault’ has multiple ‘Spaces’. I have not paid any attention to ‘chats’ so I don’t know how it works and relates to other things, but given my suggestion, ‘ChatRoom’ instead of ‘Chat’ is a possibility which may be more consistent. (I similarly don’t know anything about ‘Channel’ and have to find out what it is).

EDIT:
I thought some more and would like to refine:

  1. Vault → Home (‘Go Home!’)
  2. Space → Room
  3. Chat → ChatRoom?
  4. Type → Blueprint? Entity?
  5. Object → Instance
  6. Collection → Set (shorter name, and see #7)
  7. Query → DynaSet (Not too long name, consistent with #6)