gbif / gbif-web

Apache License 2.0
6 stars 8 forks source link

Descripency between presentation of names between collection and dataset view #558

Closed mpitblado closed 1 month ago

mpitblado commented 1 month ago

Hope that this is the right repository to ask this in! Is there a rationale why the names of persons are abbreviated in the dataset presentation, but handled differently in the collection view? The code below is based on my understanding of where this is getting determined

Dataset presentation code for contact names

packages/react-components/src/entities/Dataset/DatasetPresentation.js

<GenericFeature>
  <MdPeople />
  {dataset?.contactsCitation.length < 10 &&
  <span>
    {dataset?.contactsCitation.map(c => c.abbreviatedName).join(' • ')}
  </span>
  } {dataset?.contactsCitation.length >= 10 &&
  <span>{dataset?.contactsCitation.length} authors</span>}
</GenericFeature>

Collection view code for names

packages/react-components/src/entities/Collection/CollectionPresentation.js

<GenericFeature>
  <MdPeople />
  {contacts.length < 5 &&
  <span>
    {contacts.map(c => `${c.firstName ? c.firstName : ''} ${c.lastName ?
    c.lastName : ''}`).join(' • ')}
  </span>
  } {contacts.length >= 5 &&
  <span
    ><FormattedMessage id="counts.nStaffMembers" values={{ total:
    contacts.length }} /></span
  >}
</GenericFeature>

Of the two, the c.abbreviatedName form (in the dataset presentation) is more difficult to handle, because cases in which individuals go by their middle name or first initial become more complex with the reversal. The bandaid fix would be to just put the person's full name in the last name field within the IPT, however this seems dangerous if other systems' UI handles the name differently. The way that the collection view handles it is perfect, because it does not make any assumptions, it just presents the name in order without abbreviation. A middle name or middle initial can be better handled by placing it in the first name field.

Even if opinions disagree on what I have presented here, perhaps the two could be consistent so that data publishers could at least format the names accordingly to present how people desire across both interfaces?

mpitblado commented 1 month ago

To add further clarity

Dataset

image

Collection

image

MortenHofft commented 1 month ago

Datasets use the naming provided by the API which corresponds to the citation string. So it is to keep things consistent with the citation. There is not such API for collections and we just use the names as is (I have implemented no special logic in the frontend to try to deduce an abbreviation)

https://api.gbif.org/v1/dataset/37f48e00-1fe8-11dc-b461-b8a03c50a862 field: contactsCitation

Keeping name formatting consistent everywhere is unlikely (if that includes recordedBy etc).

Personally I like that formatting in the citation and dataset header is the same (in the past we have been asked why they differed before implementing it this way). Whatever that is. So if the difference between datasets and collections/institutions is a nuisance, then I would prefer we added a backend process generating those names for all contacts across data types. (currently that would mean all names would be abbreviated since that is what we do in citation strings - i have no opinion on what is the better way).

mpitblado commented 1 month ago

Thank you for the explanation, it seems like there is more to it than just a frontend change (and even if a frontend change was made, others would have the opposite opinion). On my end this is a user request and I am trying to see if there is anything I can do to accommodate. I think that for now, the workaround of structuring their name within the IPT itself so that it will appear as they request in both formats is the easiest thing to do. I will try blanking the first name and putting the entire name as a string in the last name field after talking to the user about it, as it would potentially affect other queries for their name that operate on first name and last name.

I'll close this issue as there isn't anything further pertaining to the react components themselves, and the API being consistent has much more weight than a single user request

MortenHofft commented 1 month ago

"Putting first name as last name". I do not like the sounds of that. That is generating bad data for the purpose of hacking the UI. Data lives on, UIs die. How about this version: I want consistency between dataset header and citation. But the most important part for me is the choice of people and ordering (not everyone makes it into the citation string). I can live with the full name.

If, we get conflicting opinions on abbreviation vs full name, then I defer to someone else to take that decision and we implement it across data types (datasets, collections, etc).

mpitblado commented 1 month ago

I agree, hacking the data is not ideal, especially because we cannot know how that would affect other systems. The only reason why I would consider doing so here is that for something as personal as a name, it is difficult (for me) to put technical best practices over that individual's wishes after outlining the possible tradeoffs to them. I do think that this issue affects a small but not negligible amount of individuals, particularly the following scenarios (just some things to consider during the discussions around the naming):

I appreciate the candor around why things are the way they are and what a potential process for change may look like, given various other decision makers and opinions.