In my opinion does “Bundles” have the same flaw as “Databases”: it’s incorrect.
The combined Collection-Query-thing only gives an overview over (some or all) Objects, but it doesn’t contain them.
Therefore it isn’t a database.
The whole Space is a database; the Space really contains the data.
An Object exists physically only once in the Space, but it can show up in as many Collections/Queries as the user wants.
The give only a visual overview, depending from the filter criteria.
In German, the term “Visor” would work well. But in English it unfortunately seem to have a meaning that lets the user associate it with a knight’s armor.
– Here’s is native English speaker necessary to modify the term correctly, I can’t do that, not even with the help of deepl.com.
The term I’m looking for should express that the thing gives a visual overview. A “Visualizer” – but this word sounds a bit stiff with its five syllables.
Maybe someone can help?
Three new ideas;
Presenter or Presentor
– Three syllables, like “Collection”, but one character shorter.
Dataview
– Hey, I like it a lot!
Three syllables; only eight characters; a speaking name; and unique!
Datvis
– Only two syllables. But maybe not as clear on the very first look as “Dataview”.
.
Edit: one idea more (and I like it best of all!): MultiView
– Each old user is already familiar with “Views”. And a MultiView simply offers multiple Views on out data. That’s it!
The part “Multi” transports the idea, that the thing is mighty and flexible; you can use it in multiple ways.
It will be the main central for getting overviews over our data.
Once I’ve suggested in an older thread, that the combined Collection/Query should offer much more Views then before; I suggested a way that would easily offer far over 200 Views.
And @Anton wrote, that they will take the idea into account. – If so, then in principle, one single “MultiView” could replace all our Collections and Queries.
It then really becomes the main central in the Space, where you can find everytihng, grouped in as many ways as you want.
Opinionated about relation, but not query/collection so I am not bothered by the name, as long as it’s clear and it sticks and we continue to use it..
But let’s enrich the playground a little bit, what about Library? Since we no longer use library as the term for relation/type library. Library is a collection, a catalog (when well-managed), a database for researchers, a query by librarian(s), a base (and shoulder) of knowledge so we further develop on, shelves (vertical tables) for storing information, and so much more.
Maybe library or shelf could be interesting choices too
I don’t conceptually view a feature unless I know what the feature is or what it does. You’re basically asking “What would you call a thing you use in the kitchen?” Well, it depends. Maybe “fork”, maybe “oven”, maybe “kitchen towel”, maybe “tap”.
A collection is put together manually, a query is put together automatically like a predefined search, and a type is a set of properties. That’s not hard to explain, is it?
Yes, I understand. However, everybody who would respond to this post already knows what this feature does literally (because they use it today), so they already conceptually know what it is. We’re not asking the community to provide a name for something they do not understand. Those who do not know how Queries, Collections, Types, etc. work would not respond to this post; or at least, this post isn’t directed at them.
It is hard for new users to understand, indeed. That’s quantifiably the case today.
I actually used the exact same analogy in an internal discussion with shelves, haha. Funny to see this show up in the discussion as well.
I think of Laundromat . Dataview and multiview focus more on the consumption of the ‘data’ I think, but it’s an interesting solution.
I find it a bit odd that a few people have commented on “collections” as being static. We have the verb, collect. It’s a very active thing and the result of collecting is the collection. Collections require ongoing maintenance, organizing, etc. which are activities. It’s difficult for me to understand collections as anything but a very active thing.
Second, I think “multiviews” is an interesting addition to this discussion and merits consideration. It is pretty descriptive. I’ve been playing out how it would sound in use but I’m not a 100% it would always add clarity in a description to someone else. Maybe though.
Lastly, I am liking the suggestion of “libraries” too. I’m a librarian though, so I’m biased.
Quantifiably? Like, you have numbers? But even if so, I don’t think renaming those things will help much. It’s a basic concept you need to understand. Notion has it and people seem to be able to work it out just fine, aren’t they? And as someone who already knows what those things are, honestly, I conceptualize collections as collections and queries as queries and types as types.
Don’t get me wrong. I really think Anytype needs some improvements, especially in order to get new users on board. But renaming things and re-conceptualizing things is not what you should do. I recently came back to Anytype and found that Spaces were renamed to Channels. Not only do I not find this helpful (it’s great, but exclusively for collaboration, which could also do fine with Spaces), but it’s also inconsistent, because in some places it’s still called Spaces. I think it’s more important to get some consistency (this is only one example) and fix a load of bugs. (He said after he clicked on all the plus signs in a Kanban board, but nothing happened). Oh, and I just found out that you still can’t do birthdays and other recurring objects, which is at least a 5 year old feature request. Tasks have checkboxes, but checking them doesn’t update the status and updating the status doesn’t set the checkmark.
My point is: Don’t reinvent the app. The basic principles are fine. Make the things that work work well and work completely. I believe that’s much more important.
That’s already the point why I call a Collection “static”. You explain it yourself:
The act to collect things is active. But the result of the activity is the static Collection.
You mention it needs activities maintenance, organizing, etc.
Yeah, everything in the universe is somehow in motion, all molecules are permanent wobbling. Nevertheless, you wouldn’t call a house “active”, although it needs activities maintenance, organizing, etc.
The thing is, that the new combined Collection/Query does some of the activities on its own when it does what a Query does. It’s no longer the user who does the activities.
That was always the difference between Collection and Query (btw.: “Query” was never a very good word in my opinion):
Collection = static. (No matter if it needs maintenance by the user.)
Query = active.
The new combined thing can do both (and maybe even more), therefore it is “multi…”.
It will be a collection/bundle of Views and some of the Views do actively collect Objects (what the original Collection never did).
I think therefore, the new name should transport the information that – in difference to the old Collection – it now has the feature to become active on its own.
Admittedly, “MultiView” doesn’t direct underline the aspect of activity, but the part “Multi…” is very universal; it can mean a lot and this fits also for the aspect that the new thing contains multiple Views with different functionalities (passive, as well as active functionalities).
– Btw.: Nice discussion here; I like it very much how we all together try hard to a meaningful, best fitting name!
i’d like to reminnd you all that no word will ever do the hevylifting of explaining a whole feature to people and only part of the world has english as mother tongue; that english is also divided in 2-3 big blocks…
think more about what happens when you have to explain it to someone else or that someone else has to search for tutorials and less about ‘‘intuitive meaning’’ imo
don’t try to offload onboarding to the meaning of a single word
and, on a side note, softwares like anytype and notion are not common at all, so trying to rely on old meanings imo doesn’t help. The most exact word would be ‘‘list’’, the second one would be ‘‘database’’ but we all know that both are highly impractical even if the most correct and understandable…
Regarding this, when this change arrived I proposed (in the Anytype Community chat) keeping Spaces as the global name instead of Channels, and then using Chat for the spaces that revolve around conversations, as a room from your spaces where you can “make noise”, and something on the lines of Library or Study for the ones revolving around content, as a room from your spaces where you focus on creating and curating. I know this is not being discussed here, but @C.c mentioned “Library” for lists and I would like to reserve this name just in case
I have voted for Collections here because I see them as this, but the fact that you create them in different ways (one is automated and the other is manual unless you previously set up an automatic way to label things) keeps me thinking about this nevertheless. As a translator, I deal with words for a living and think that naming is quite important for approaching new concepts. In fact, when properties where still named as "relations”, I had to take some liberties in Anytype’s docs translation into Spanish for them to make sense. So, I am still tinkering with alternatives for Lists in my mind and enjoying this conversation very much.
While not trying to defend library,
I had been using the word element library a lot for referring to the UI space for creating type, template, and relation a lot, so I understand why library might be a good choice for other things, but we probably have lots of word choices for rooms for creating things that we don’t have to reserve it, e.g. factory, assembly line, lab, workshop, kitchen, kiln.
btw, out of the topic, I am also curious why we need two words for channels and chat, channel is very accurate for speaking to each other, in those walkie-talkie ages .. especially in terms of function, we can make chat object as default homepage to make channel function like chat..
Some users have already voted for “Table”, what puzzled me, because I’ve associated it with a dinner table. <:-/
I believe most non native English users would get it as wrong as I did.
The term “Tableau” avoids such misleading associations. It fits good to the real meaning.
The word is also unique enough in my opinion (although not as unique as “MultiView”).
I think the key purpose of the name is to accurately represent what it stands for, for example:
a “database” object accurately represents data contained within a “database” object (not exists somewhere else, e.g. in a space)
a “query” object is well suited to representing the rule used to select objects from a set (or a space in our case), e.g. I want all apples that are green
a “collection” object is is best when you want to represent an arbitrary set of objects, but without having a particular rule except for “I want this object to be in the collection” = true
I want to mention that right now Anytype basically has this model:
an object type is the database table definition - it contains which columns does table have
an object is the database row which contains the values for each column
For the above stems that there is no object in Anytype that contains multiple rows (in the database sense). The space serves as the smallest scope within which the objects exist. That implies that “database” is not a good name in current Anytype, unless we introduce another special type of object called “database” (which will contain multiple rows and the table definition inside of it).
In the end a “query” logically is the closest thing to represent a view on the space (i.e.. a rule under which we take some object from the space) which I think the Lists 2.0 will be. Or if I am wrong please tell what underlying data will Lists 2.0 represent.
This word is also closely related to databases in the IT world, and I think that Anytype is a database in its core (+ some visualizations on top).
Just to mention - a collection IMO is a subset of a query in a sense that you can think of a collection as an edge case of a query where every element has the property ‘belongs to collection A’ set to true. So the query is a better name in that sense.
We’ll leave this poll open for another day. And we’ll ‘soft-close’ this discussion soon thereafter, as we want to move into the next conversation soon. Just giving everybody a heads up.
Overall, I’ve thoroughly enjoyed a lot of the proposed options and discussions/thoughts. Thank you so much to everybody who lent their brain power for this exercise!
So I would like to emphasize the need to keep the feature that allows any Types to be renamed(even System Types!), regardless of the final choice, so that we will all be able to display the name that best suits us even after Lists 2.0 release.
In short, we are proposing that we use ‘Collections’ moving forward. There are many reasons outlined in the post, so feel free to continue the discussion there. Your input is highly valued.
Again, I want to say a big thank you to everybody who has helped chime in so far. You’re really helping to orientate us on what makes sense for the future of the product.
. Dataview and multiview focus more on the consumption of the ‘data’ I think, but it’s an interesting solution.
.. especially in terms of function, we can make chat object as default homepage to make channel function like chat..