Prospective renaming of Collections & Sets; topic continuation

Talk
, ,
63

Oh, I just have the best idea ever:

Collectbox :+1:

  • This name is exactly as long as “Collection” (10 characters, not one more).

  • It iis unique!

  • It reminds on “Collection”; no completely new or strange term.

  • It even contains the meaning of it’s active function: to collect soemthing.
    A “Collection” is clearly a static thing.
    But a “Collectbox” can be interpreted as an active thing, as well as a static one.
    None of these two interpretations is excluded, this dual meaning fits perfectly!

64

+1 for Collection

65

I’m not against “list”, and I understand that the idea here is to go with something simple, but to me it feels a bit limited… too simple perhaps?

It doesn’t convey the possibilities of what we can do with sets/collections, where lots of different data can be displayed and arranged.

I kinda like the idea of keeping “set”. Or I’d just go with “database”.

At the end of the day though, I think that functionality > name, so I’ll just go with whatever the team chooses :stuck_out_tongue_winking_eye:.

66

Agreed! I alway think relation acutally is property of a object. Calling it relation always bring some logic porblem to me.

“you need to use relations to build relation between objects :melting_face:”

Relation is a word mostly work with two or more objects.
it’s not intuitive to use it seperately.

67

I definitely find the term ‘relation’ confusing. I personally call it a field - and I started to understand Anytype properly when I did start calling it a field

For the list thing, I’d be happy with set, collection, list or group

68

I don’t believe I’m doing that. I’m certainly not insisting on formality and I don’t prize formality above usability.

True and I am neither of those. I’m not any kind of developer.

I’ve never done anything resembling Computer Science 101.

I would argue that the complaints aren’t about the term, but about the poor documentation of sets. There are many threads here in which the OP has understood what sets are as soon as someone explains that they’re saved searches (or something similar). The confusion arises because new users assume that sets are some kind of database, akin to a Notion databases, and they struggle until they understand that they’re not. If the Anyteam intend to turn sets/collections into something closer to a database (I don’t know that that’s exactly the case), then the term “set” will mean what new users expect it to mean.

As I’ve said earlier (a) this is very much a matter of opinion, and those will differ and (b) I’m not wedded to “set”. I am, however, wedded to proper arguments, not ad hominem references to “geeks”, “IT guys” or “Computer Science 101”

69

I’m sorry I offended you. I realize that’s also why the rest of my argument didn’t come across. That, too, is my fault.

As for having proper documentation, I’m always in favor. Having said that, any software that requires reading a manual before using it will inevitably remain specialized software used only by highly dedicated users. It’s the sort of people who are willing to use beta software, but crossing into general-use production grade is something entirely different.

You’re not a programmer, and neither am I, but we’re both not representative of the majority of people who could benefit from Anytype once it matures.

70

You caught me at a bad moment. I’m not really offended, but thank you.

True

I’m unsure about this. I suspect (but it’s just a feeling - no evidence) that Anytype will always remain something of a niche product, although it might be a large niche.

Generally, I think you’re right to suggest that the terminology should be sufficiently clear and the functionality sufficiently discoverable that extensive documentation isn’t a must-have. That said, Anytype is so flexible that new users will need some serious guidance.

71

Many people have the same problem. The term is a holdover from formal relational database design but it meant something different there, and it doesn’t make sense for “normal” people. “Field” is a reasonable alternative, as is “attribute”

72

About “Field” or “Attribute” instead of “Relation”:
These terms are not unique and much to universal to be suitable as a name for a very specific thing.
Adding a suitable prefix would make them unique.

What in Anytype is called a “Relation” (the Object) is in truth a “field which stores an attribute”.
One could call it an “attribute field”.
But the downside is, that these are two words. And in contrast to the German language it’s unusual in English to merge two words together to get a longer but precise word: “Attributefield”.
It would look a bit strange in English.

What I criticise is (beside other users good arguments), that the term “Relation” not differentiates between the field (Object) and the content it stores.
Think: one thing is the Object – the field.
Another thing is the content it stores. For example a Tag or a number.

An envelope is an envelope.
And it’s content is … maybe a document or whatever.
No one would call the document inside it “envelope”
And no one would call an envelope a “document”.
They can’t have the same name!

The term “Relation” spares out this differentiation. That’s not good!

One could call the Relation-object “Datafield”.
“I have in my Page a Datafield for Tags and another one for a number.”
– Such a sentence makes sense for me.
Also, “Datafield” is unique (unique enough).
But “Field” alone is too universal to be suitable as an Object’s name.
If someone writes in the forum: “In the field of my profession …” the post would appear in the search results if you search for “Field”.

Conclusion:

  1. Each Object should have a unique and precise name.
  2. There must be no confusion as to whether the Object itself is meant or the content it stores.

The Relation-object in Anytype stores an attribute or other data. It can be a Tag or a number etc., but in some cases also a relation (a link to another Object).
But the word “Relation” is not not precise, it doesn’t differentiat between the Object itself and it’s content. And it is (often) also wrong, because often there is no “relation” (to other Objects).

“Datafield” would be a much better word for the Object, then “Relation”.
It works also in a Set’s or Collection’s Grid.
“Go to the Grid an enter a number in your Datafield for the temperature!”
– Such a sentence makes sense, there is no confusion possible.
But the sentence becomes wird if you replace the word “Datafield” by “Relation”.

We all are used to “Relation” for a long time, so maybe we are a bit blind now to see how wird it really is.
But a newbie will be confused about “Relation”.
“Datafield”, in contrast, doesn’t cause such confusion.

73

Now relation is my category. I will try to keep to the topic of set/collection though.

First disclaimer: most of my relations are object-supported relation. ∴ they are indeed relations between objects.

Why relation is not simply property? and how does it influence set/collection and its naming?

  • Hidden or unaware relations: we don’t live in an isolated world; things must have some relations to another thing so they can co-exist. e.g. Tasks always belong to a person, even when we don’t input the human object; time is not a single episode, it always relates to another time
    – When we use set/collection, we are laying out a system or structure which connect all the included objects, so using names that represent display and format is good.
  • Property is static and relation is dynamic: for example, when we have date object in the future, we can click on the time/date relation to access that date object.
    – Set/collection is interactive and can be a directory.
  • Like communication, we normally speak interpersonal, but there is also intrapersonal; thus in Anytype’s case, Intra-object relation. For example, for a Song object, only because of the songwriter, a certain part of lyrics is composed in certain way.
    – This will require Set/collection to show dependency; thus box seems constraining… but graph view will most likely be a better place to demonstrate dependency.

I quite like ‘List’ but one problem of using ‘List’ is that we already have lots of options when we type list in / command - checkbox/bullet/number/toggle. If we add another list item for set/collection, there will be more items that we need to search through before reaching the desired option.

I quite like the word ‘Field’ as well. It could be both structure (like wheat field) or other manifestation (like energy field). This raises the potential to combining with graph view and flow view, for different UI/UX and reachable workflow. :thinking: But I don’t think it is easy to understand.

P.S. I am more fond of relations than set/collection, so whatever term will do for me.
P.S.2. I know Relation 2.0 is not here yet, but there are so much potentials in relations that I am already looking forward to Relation 3.0 :laughing::joy:

74

PoV: No programming knowledge.

+1 for merging sets into collections.

Collections seems intuitive as it “collects objects” and could be manual (same as current collections) or automatic/queryable (like current sets). It doesn’t clash with other “list” features like list view either.

If both share the same name though (collections, lists or other options) it should have a quick way to view if it is automatic or manual in my opinion. With many built it can easily get confusing to know how that particular “grouping” is organised, or how to add objects to it.

Lots of rich discussions going on too, damn! :slight_smile: