New feature names in Anytype

Talk
22

Hi all, chiming in with my 2cts.

Object vs. Item

I think objects is best. It’s generic, does not belong to anything. Items conveys the fact it is part of something. Started fresh it could be confusing.

Type vs. Collection

Type is the word I use to describe objects. Generic as well and I got it right away when introduced to Anytype a week ago. Each object type has its own properties.

Queries vs. Curated Collection

Took me too long to get what the difference was between Queries and Collections was. Both are Views. If I want to see my objects I would create a generic DataView (object or property query-based view) just as database views from Notion. If I want to create a manual selection of objects I would create a CollectionView or Curated Collection. Also what helped me the most get what collections are is when tutorials described it as Folders.

Thanks

23

Interesting — when you say standard way, which apps are you thinking of? And in those apps, what can you typically do inside a space?

@dzlg Thanks for the input! Curious — if you saw a thing called ‘Space’ in a new app, what would you expect to be able to do inside it? And same question for ‘Channel’ — what would you expect there?

@mandem thank you! may I ask you what you expect from a thing called a space as a user?

@zetashift thank you for the input. what you expect from a thing called a space as a user?

@dxn0 could you please elaborate on this. what you expect from channels inside as space in this case? and what you expect from a space as a user in multi-player context?

@Regis there are no plans to add any hierarchical permission in spaces/channels. We have plans to introduce a new layer of abstraction which would have separate level of permissions which will be called workspace/org/hub - which will accumulate Spaces/Channels. Spaces/Channel will have flat permissions model for a long while as changing this would require of rebuilding a big part of the protocol. In this context what are your exceptions form the thing called “space”?

@Tushar Thank you for your input. what you expect from a thing called room as a user? what you expect form thing called a space? Channel?

24

@anton in those apps, you can typically assign roles and have an enclosed workspace that is isolated (not fully but to an extent) from other workspaces. Some of the apps that I know that use this terminology:

  • Notion: workspaces
  • Element (Matrix) : spaces
  • Slack: workspaces
  • Monday.com: workspaces
  • Todoist: workspaces

Clearly “workspace” is more common than “space”, but I like “space” because it’s shorter. I understand “workspace” may be easier to understand though

25

Thank you. @raph This is exactly what I’m personally worried about.

I really love the word space and I believe it’s a great fit conceptually. My main concern is that people will project onto it the expectations they have from workspaces in Notion, Slack, etc. — especially granular or hierarchical ACL.

We don’t plan to deliver that, at least not in the next two years. So teams coming for collaboration might be disappointed if they expect workspace-level permission structures and instead get something flatter.

What we actually plan is to introduce a higher-level abstraction — potentially called Org / Workspace / Hub — which would correspond to what “workspace” means in Notion or Slack today.

Inside it, Spaces (or Channels) would live. Their ACL would remain flat — with more roles, yes, but still flat rather than hierarchical.

26

@anton thank you for explaining, I understand what you mean. An organization/hub that includes spaces/channels definitely make sense for organizations to have a centralized management system (especially for billing and user management).

What I’m confused by in what you wrote is the lack of hierarchy: we currently have 3 roles in a Space: owner, editor, and viewer. This is already a hierarchy. Many of us are hoping for additional roles (specifically 1) admins that can manage types, properties, and users, and 2) commenters or editors lite that can only participate in chats/discussions) but I believe that this doesn’t require a full shake up of roles and permissions, just to add new access to certain actions.

If what you mean is that you will not (any time soon) implement per-object permissions, I think that’s okay–roles at the space level are sufficient (for now). But to me this doesn’t contradict the idea of calling channels Spaces or workspaces: spaces/workspaces don’t necessarily imply that we’ll get hyper-granular permissioning; to me it only implies that each space is isolated and independent (or at least autonomous) from other spaces, with its own members and database of objects.

So I think we’re in agreement about the overall structure of object/space/org, and in my opinion not having object-level permissions doesn’t contradict the “Space” naming :slight_smile:

27

This is so helpful! Thanks a lot for taking time to answer. This is what I wanted to validate.

28

@anton Well, it depends who you’re asking. Because of my exposure to all of this productivity apps, I’m somewhat biased and partial to the naming scheme. So, when I see a ‘Space’, I would think that thing is probably a terminology belonging to the top of what that app is offering me; maybe even the highest and would allow me to do everything that the app is capable of. Similar to what we have in Notion in terms of ‘workspaces’. Somewhere I can create, work and have my own stuff in it.

When I think of ‘Channel’, I immediately think of Telegram and how it’s used there. But generally I think of channel as a method to broadcast information, probably in a one-way fashion. I don’t think of it as ‘editable’ or somewhere I can create and do my work in.

That’s why I prefer the naming scheme of ‘Space’ and ‘Chat’. However, as I’ve voiced my opinion when the chat feature first launched, it would cause a lot of confusion for the average user and for myself in the first place. Let me explain again.

When i’m in a shared space, I can see there are a lot of people there. So, it would seem natural that I can click on their avatars and ‘connect’ with them or ‘chat’ with them. Sure, this is how Anytype works at the moment and it’s all good and well. But, then you discover that when you are connected with that person, not only you can have a direct conversation with him/her, but you essentially have a whole new space to create and work together! Awesome! However, you can’t have a ‘main chat’ and not chat as an object. So, you’re stuck with an environment like Telegram, with the additional features of creating, Very well.

But, then you have another way of achieving this! You can create a space, and just invite that person. Now, you can also chat with that person directly in your own private space, but you now have the capability of having multiple ‘chat’ objects; meaning you can have dedicated topics of conversation like discord/Slack, while being able to co-create. So, this begs the question:

  • why should I just have a direct channel with that person in the first place?
  • Should I think of it first that whether I only want to chat with him/her about one topic, or do I want to organize my topics of conversation in different places?
  • What if I change my mind and later down the road, need multiple chat objects to handle different topics of conversation, however, I’ve created so much objects, customized types, etc. and would be a hassle to move to a new shared space. Not to mention that we would loose all our chats from the ‘direct channel’.

So, you see my point? I can’t see what’s the point of ‘direct chats’ if we can have multiple chats in a shared space. Again, if the chats were just chats and you stripped away the capability of creating/working on objects/types, I would understand. It’s just a normal chat within Anytype and nothing more. But as of right now, it’s in a bit of a no-man’s land!

I strongly think it would be much more streamlined if there was much more distinction between features so that it would be clear which one the user should choose and it justifies its existence. Again, if the chat feature would gain the capability of having ‘chat’ objects in it, then we would have a different conversation. Then it would mean that there are various means to an end. Or, if we could elevate any of the ‘chat’ objects in any given space to act like a ‘main chat’ or ‘direct chat’. This way, you could choose whether you want to have a central hub of conversation like the one we’re having in ‘Nightly Ops’ and then I remember people talking about having various other ‘chats’ for ‘feature requests’ or ‘bug reports’, etc.

But back to the naming scheme, I think the most streamlined version would be to have just ‘space’ with each and every space have the capability of having one or more ‘chats’ going on in them. And the ability to elevate the status of one of the ‘chats’ to the ‘main chat’ so that it would become clear in the sidebar too. Similar to how it’s now.

29

I believe this was meant for @Maira :slight_smile:

30

I’ll throw in my two-cents. I found @Elias ‘ points about communication strategy and using Capacities and Raycast as extremely helpful. He’s right that there’s been a lot of naming convention changes over the past year. I think it’s important to describe a feature as what you hope it will do, and not just what it does currently, even if the realization of that vision is 2+ years away. Unmet expectations is certainly a concern, but I think having consistency is more important.

Regarding the Naming Scheme:

Object vs. Item

I think either term is fine. Direct and indirect objects are taught early on the English language, so I don’t think its that technical of a term and most folks would be familiar with it.

Type vs. Collection

I’m convinced that collections is a more accessible term.

Queries vs. Curated Collection

Don’t love curated collection, but I can see the argument for it. The only pushback I’d offer is that you can query properties, which isn’t a type/collection, so curated collection doesn’t really fit here because you’re combining bits and pieces from various collections.

Vault vs. Account

Depends on whether you’re person oriented (Account) or data oriented (Vault)

View vs. Layout

I really really dislike layout, it makes me think of arranging furniture in a house and having far more flexibility than views allow. Also view is a much more succinct term.

Property: Object vs. Property: Relation

Happy with either term, we just need it to say the same for a few years. We just changed this name like less than a year ago.

Editor vs. Canvas

I prefer editor, mostly because I think you’ll run into naming issues down the road when you implement an actual canvas. Also, I think canvas will set incorrect expectations about it being mostly graphic focused and not text focused.

Channel vs. Space

I prefer space, it think it’ll be more flexible for future use, and you’ll be less likely to have to change it. Also, you have a lot of words starting with C otherwise, which could be confusing.

31

I’m just thinking of another thread I saw where there would be a separation between an “admin” and an “editor.” An admin having full privileges, but an editor only being able to create/edit/delete objects.

32

Rather then saying Items would we still say Types? or is Types to Concrete to really describe its future capacity… because If that’s the case I would go with items

34

Wow! I expected to disagree with some of these, but I really disagree with all of them. :smiley:

It’s hard to explain how angry this makes me.

35

I’m with @raph on this: “Space” is how I naturally think about it (and I prefer it over “Workspace,” since Anytype isn’t always about work, “Space” is more flexible).

Also, since you’ve said fine-grained permissions/structure aren’t coming for a while (maybe ~2 years), I’d optimize for a name that will still be right when the product matures.

Choosing “Space” now trades a small expectation mismatch for some users in the short term, but it avoids a rename later, meaning more stability and less confusion long-term.

36

Sorry for the late reply, @anton , and thank you, @mandem, for tagging me here!

When I first met Anytype, the initial experience was full of cosmic metaphors, so I took “Space” as meaning “one of the borderless chunks of my very own galaxy in the Universe,” with “Universe” being everything out there and “my galaxy” being my Vault. It took me sometime to navigate those concepts, but gradually a Space became to me what I see now, an empty room with no preset partitions, mechanics, or purposes. This is why I see Chats as rooms focused on discussion, and what are currently called Spaces as rooms focused on content. These are my visual metaphors at present.

I think that, if I were a new user at this moment, the fact that both are called “Channels” would make me feel confused about their purpose and capabilities. I find it hard to think about my knowledge base, whether shared or not, as a channel of any kind.

37

yep these are comming

thank you, this is good to know

38

This is what I afraid of, since we plan to introduce a higher level abstraction for orgs — something like workspaces which would contain channels, properties, templates… etc.

this is good to know, clearly can understand this confusion. I think Iran and Russia two contras where people use channels heavily, hence it’s easy to be confused.

This uses different cryptography and allows you co create these channels p2p without any network, you both in direct channel literally own the connection and have same rights. When you create a regual channel/space you can’t invite yet people in local network and only a one will be an owner.

No you should not, we soon collapse a chat and a space into a one concept where you will be able to chose it;s form. So yo would be able to amen it as you wish.

thank you for you input!

39

That makes sense from this point of view, but maybe we can explore alternatives for channel if you want to keep the “space” for higher order schemes.

I don’t know about the rest of the world, but yeah, in Iran we heavily make use of Groups and Channels in telegram.

Thanks for clarifying the infrastructure differences. But you do see my point as it doesn’t have enough distinction or added value of the two routes for the user; at least, in the current form.

That’s very good to hear :+1:

My pleasure, thanks for taking the time and interact with the community :slightly_smiling_face:.

40

Yep, this is true. Still ACL is flat if you an editor, you are editor of the whole space.

41

Please, elaborate