First Name / Last Name fields in "Human" Type

Feature Requests
,
1

What Do You Recommend?

I think that the possibility of adding a “first name” AND a “last Name” in the header of the type “human” should be possible.
Now this header as “Name” in grid view. That is not convenient when you want to create (for example) a people database. Most humans in this world have both a first name and a last name why wouldn’t it be a default?
I know we can create a first (or last) name “relation” but it becomes strange on the page itself with the first/last name on top and the other elsewhere.
Also, if you link to it, only the header will show up.
Anyway I suppose you get my point it’s not “serious” the way it is now. We don’t live in Sesame Street. We need last names (by default) :wink:

How Could It Be Done?

Maybe a switch to switch to First/Last Name instead of just “Name.” So people that already use it the way it is now don’t lose their database?
No idea honestly!

Real World Use-Cases

Sort by First/last name:
Say you built a customer database.
Someone shows up saying “I’m in the database” but you can’t find him with a search for his full name (a search on the present “Name” field).
I would like (for example) to be able to filter by his last name and then sort alphabetically by first names to be able to visually confirm the person has not been encoded with these references.
I hope this makes sense to you guys.

Recommended Alternatives

The possibility to remove the header “name” from a template for “Human” + possibility to assign relations to “human type”?
No idea either

Additional Context

It has been a head scratcher for me for a few days. I almost settled for the “First/last name” together in the “Name” field but to start something that I would use professionaly that way seems too risky.

2

You can create your own Relations for it.
But it has also a downside. We need in deed improvements here.

The downside:
When you divide the name in first name and second name, think what happens if you search for “Michael Smith”.

There are many guys called “Michael”.
(Also many “Smith”)

That’s a real problem if you have 1000 or more people in your database.
At the moment Anytype has no good solution for it.
My own pragmatically way:
I use a Relation “Name” but in addition also one for the first name and one other for the last name.

No good solution, I know.
For the best solution we need an improvement in Anytype. And we know about it since long …
The solution would be, to use first name and second name, but there is also a combined Relation which automatically grasps both and merges them together for the search function.

Thank you, that you wrote this FR, because it brings the topic back to the developers mind!

3

I now see the difficulty indeed. I did not think about the problem of searching both first and last name. I assumed it would just (magically) work I guess.
Thank you for this very clear answer.

4

Yes.
I use this three Relations:

  1. First name
  2. Second name
  3. Name (combined first an second name)

The reason for it:
This way I can sort the Set’s or Collection’s Grid either for first name or for second name. But I can also search for the whole name.

I use the combined Relation “Name” as title in my Human Object.
Down below are the other two Relations.

The disadvantage is off course, that I need to write each persons name two times (spitted in three Relations). Not nice, but I can live with it for a while (hoping for updates!).

What in general peeves me is the fact that it’s impossible that the cursor automatically jumps into the next Relation after finishing one with Enter.
That’s why you have to constantly switch from the keyboard to the mouse and back again.
It’s not a frictionless fluid use.
And each additional relation worsens the situation.
But we have no choice at the moment.

5

I see, it’s a good work around and I guess I can live with it too as long as my work situation gives me enough time to fill three fields “just” to enter someone’s name.
Hopefully I’ll get faster at it with time.
Thank you again @Code-Jack.

6

This is a similar issue mentioned here

7

Hi, I have more issues with the relation “Name”
I am currently trying to set up a database for medical appointments but no matter what you create there seem to always be a “relation” “Name” that is created. This “Name” relation does not create a “human” type like in my previous problem (customer database). It seems to be the “name” (title) of the object (page). It is very confusing since:

  1. The relation “Name” seem to have different functions depending on the object type (human / something els)
    2.The relation “Name” is created by default although I don’t need/want it (in my case what would “name” stand for in a medical appointment ?)
  2. I cannot hide it in grid view (didn’t find how anyway)

By default, it will display the title of the template but it is useless. I don’t need a column/relation saying “medical appointment” for every new object when the set already gathers objects with the “type” “medical appointment”. It is redundant.

Capture d’écran 2024-02-04 à 4.15.45 PM
Capture d’écran 2024-02-04 à 4.15.45 PM2880×1800 182 KB

Does anyone have an explanation on how it works or why it doesn’t ?

Thank you in advance.

8

See each Object as a file in your operating system.
Each file must have a (unique) file name.
That’s the Relation “Name” you see in the Grid.

Anytype is more flexible then the operating systems file handling, because Objects in Anytype can (but shouldn’t) have the same name.

You use it wrong, if all your Objects have the same name.
Better give them different names.

What you use in you pic as the Object’s name is in reality the name of a category in which you want to haven them

The better way:
Create (for example) a Tag for it. Then let the Grid’s View gather all Objects with this Tag.
This View is now your category.
Now you can (and should) use individual names for all the Objects.

.

Think:
It makes no sense to create a lot of Objects with the same name: “Good joke!”
Better give all these Objects the Tag “Good joke!” and each of them an individual name.
Than gather them in a View.

There are other ways for organizing Objects, but I suggest Tags.
Tags have the big benefit that you can give an Object more than one Tags, that menas that you can show them in different Views.

I use it vor music, here an example:

In my opinion this music piece is good for:

  • Relaxing
  • Meditation
  • Focused programming
  • Lucid dreaming

So I gave it his four Tags.
Now I can use four different Views for these categories, beside some other for other Objects with completely other characteristics.
But each Object has its unique own name.

9

Thank you @Code-Jack for this very complete answer.
I’m afraid I wasn’t clear, though. I already know and understand very well what you explained about the tags. The repeated names were just an example of what would happen if I leave these fields untouched (from the template).

Each file must have a (unique) file name

That, in my opinion, causes two problems :

  1. Not everything can/should have a name.
  • It adds a lot of friction to have to come up with a name for every appointment (in my example).
    I have all the relations I need to describe it precisely. (Where, when, with whom,. . .)
    Many objects/workflows are not name based.
  • Why can’t an object have a unique identifier that doesn’t appear as a relation? In Logseq they call it block references. (Because everything is a block in Logseq but is translatable to objects I guess)
  1. In grid view this (useless in many cases) column appears and you cannot hide it

What you say there is quite astonishing :

Objects in Anytype can (but shouldn’t) have the same name

  • Does it mean that the responsibility to remember every name ever given to not make any doubles is left to the user?
10

Try to link to another Object by using a Relation in the editor and you’ll understand why it is a bad idea to have Objects with the same name.

Same thing with Templates. It causes confusion for the user if there are different Templates with the same name.

Anytype can handle Objects with the same name. But the user can’t.

To be honest, I don’t understand your examples and why you have such a problem with giving your Objects names?
Can it be that one single Object with a Simple Table (with eight columns in your case) would be a better choice for your use case then storing your data in many Objects in a Collection?

11

Hi @Code-Jack thank you again for the answer and sorry for the delay of this answer.
I tried what you recommended me to try (link two objects with the same name and besides the fact that you can’t tell which is which, I don’t see the problem.

image

To be honest, I don’t understand your examples and why you have such a problem with giving your Objects names?

I am having difficulties explaining it better than I already did. Many things have names like people, places, projects, . . . Some don’t require it like appointments for example. An appointment needs a date, a place, maybe with whom, . . . but finding a different name for each appointment that you will ever make is complicated. Like in your agenda, for example. I’m sure most people will go to a certain date write the type (like meeting or ophthalmologist, . . .) but don’t give it a name. People usually don’t put in their agenda “my appointment with an ophthalmologist” right?

So, in my case having a column to fill with a name for every appointment is problematic (even more now that you tell me it cannot have the same name as another object/appointment)

Can it be that one single Object with a Simple Table (with eight columns in your case) would be a better choice for your use case then storing your data in many Objects in a Collection?

Of course that would solve the problem of the “name” relation/column but then what is the point of using anytype?
If I wanted tables instead of databases, I would use one of the many options fare more advanced in terms of tables.
It looks like what you are telling me is not to use anytype for what it has been built for (in my understanding) to avoid a problem of conception.

Same as with the first issue of this thread (first name, last name issue), the way it is now, I don’t think it can be used seriously in a professional environment (as a database). I don’t know any company that would use a database that has a mandatory “name” field” especially if you have to fill it with different data every time.

I hope my point is clearer this time.

Again thank you for taking the time to help me.

Respectfully,

12

J’ai rencontré le même souci pour des notes de dégustation : je veux juste une table avec les notes, il n’y a pas de titre à avoir!
Mais Anytype réclame un nom à chaque object, c’est une limitation…
Seule solution pour l’instant, laisser le titre vide (ou mettre un titre générique “Infos”, “Element”, “.”,…)
Autre solution : utiliser un template avec un layout “Note” (layout qui n’a pas de titre mais va prendre le texte du contenu à la place). Si tu utilise uniquement les relations, il n’y aura rien à afficher. Ca revient à avoir le titre vide…

image

A partir de là, réduire la colonne au maximum et la mettre là ou on l’oubliera le plus facilement.
Et espérer qu’Anytype apporte une solution un jour.
(je ne sais plus s’il y a des requêtes pour ça, je regarderais)

–

I’ve had the same problem with tasting notes: I just want a table with the notes, there’s no need for a title!
But Anytype requires a name for each object, which is a limitation…
The only solution for now is to leave the title empty (or use a generic title such as “Infos”, “Element”, “.”,…).
Another solution: use a template with a “Note” layout (a layout that doesn’t have a title, but takes the text from the content instead). If you only use relations, there will be nothing to display. It’s like having an empty title…

From there, reduce the column as much as possible and put it where it’s most likely to be forgotten.
And hope that Anytype will come up with a solution one day.
(I don’t know if there are any requests for this, I’ll have a look).

13

J’ai rencontré le même souci pour des notes de dégustation : je veux juste une table avec les notes, il n’y a pas de titre à avoir!

Exactement ! merci. Tu as tout à fait compris ce que j’essayais d’expliquer. Je commençais à me demander si c’était moi qui passais à côté de quelque chose.

Seule solution pour l’instant, laisser le titre vide (ou mettre un titre générique “Infos”, “Element”, “.”,…)
Autre solution : utiliser un template avec un layout “Note” (layout qui n’a pas de titre mais va prendre le texte du contenu à la place). Si tu utilise uniquement les relations, il n’y aura rien à afficher. Ca revient à avoir le titre vide…

J’ai implémenté ta technique du template avec un layout « note » et j’ai réduit la largeur au maximum. Ça suffira pour l’utiliser, mais j’espère vraiment que l’équipe Anytype n’a pas tout construit autour de cette « relation » « name » et qu’ils pourront changer ça. C’est vraiment limitant.

Merci beaucoup pour cette solution (temporaire j’espère).

P-S Je me rends compte que je n’ai fait que des critiques (constructives j’espère) depuis que je participe. Je voudrais juste dire que si certaines choses sont si frustrantes c’est parce que Anytype est un logiciel formidable avec un potentiel énorme et qu’on en veut toujours plus.

_

I’ve had the same problem with tasting notes: I just want a table with the notes, there’s no need for a title!

Exactly! Thank you. You totally understood what I was trying to explain. I was beginning to wonder if I was missing something.

The only solution for now is to leave the title empty (or use a generic title such as “Infos”, “Element”, “.”,…).
Another solution: use a template with a “Note” layout (a layout that doesn’t have a title, but takes the text from the content instead). If you only use relations, there will be nothing to display. It’s like having an empty title…

I’ve implemented your template technique with a “note” layout and reduced the width to the maximum. That’s enough to use it, but I really hope that the Anytype team hasn’t built everything around this “name” relationship and that they can change that. It’s really limiting.

Thank you so much for this (hopefully temporary) solution.

P-S I realize I’ve only been giving (hopefully constructive) criticism since I started participating. I’d just like to say that if some things are so frustrating, it’s because Anytype is a great software with enormous potential and we always want more.

14

What you did is not what I suggested.
What I meant is this:

  1. You alredy have two Objects with the same name.
  2. Then you open a Page as a third Object.
  3. Put for example the “Events” Relation in the Page.
  4. Now choose in the Events Relation one off your already existing two Objects which share the same name …

You can’t know which Object is the one you want.

15

I just thought of it: instead of Empty or a phony title, why not just put an icon and reduce the column to a minimum?
I have updated my project, thanks :grin:

image
image767×213 13.9 KB

16

Works for me !

image
image2746×498 25.7 KB

Thanks @Shampra

17

Thanks for this clarification, but as you can see above I had understood the problem.

18

Hello again @Shampra, I found a feature request for it.
There is only 4 votes for it, so feel free to add yours if you still think it’s worth being fixed.