I think I agree with William, since the world is diverse and I don't think we can cater to *everyone*.
On Wed, Jan 10, 2018 at 3:44 PM, William Brown <wibr...@redhat.com> wrote: > On Wed, 2018-01-10 at 04:26 +0000, Máirín Duffy wrote: > > Hi William, > > > > I'm one of the Fedora UX designers and was pointed to this thread by > > charcol on another list. > > > > I would like to express enthusiastic support for having by default a > > display name field and a legal name field. This is of particular > > benefit and interest to women as you clearly recognize. My legal name > > is not what people know me by yet it's important for various gov't > > docs that my legal name be used. In most contexts the name I go by is > > more appropriate and recognizable for everyone. Red Hat allows me as > > an employee to choose a displayname for my first name but not my last > > - my legal last name is not what I go by. This has definitely caused > > me some serious real world challenges. > > Thanks! I'm glad to see that this idea is supported. I have always > wanted to improve this, and this seems like a great time to achieve it. > > > > > One question I have about having multiple names in one field, from a > > UX designer POV - often when retrieving lists of names for display in > > interfaces, in a Western context they are often listed lastname > > firstname in alphaorder. If the field is freeform and the person > > inputs first middle last or even more names, how can the lastname be > > identified so that a given user can be located in an alphabetically > > ordered list? > > You can sort on displayname, but that's about it - The challenge get's > worse in this case. > > firstname lastname > singlename > firstname familyname1 familyname2 > firstname middlename lastname > > Which do we sort on? I know in spain they have a non-hypenated pair of > family names. And then you have individuals with single names. > > So sadly, there is no *truly* consitent answer here. > > In the "surname" case you would have: > > [ surname field ] > > firstname lastname > singlename ???? > firstname familyname1 familyname2 > firstname middlename lastname > > So already, we have a broken design in trying to sort on "lastname, > firstname" in the western context because of the individual with the > singlename. > > Additionally, some people may not even enter the surnames correctly - I > know one spanish lady who consistently had issues with the Australian > government insisting that familyname2 was her surname. So she would be > put into systems as: > > [ surname field ] > firstname familyname1 familyname2 > > Again, the surname doesn't "sort" correctly, because her true > familyname1 is not in the surname field. > > > With displayname you can only sort by "order of the displaynames". So > we can at least consistently sort this given the scenario above! > > To *search* for surnames however, now you can do a substring search in > the displayName field. I'm not sure of your LDAP profficency, but the > search would be: > > (displayName=*lastname) > > So for me, I would choose my display name to be: > > "William Brown" > > To find me would be: > > (displayName=*Brown) > > For a legal version, you now need to search the legal name field, and > again, the same search syntax is possible > > (legalName=*Brown) > > > This seems like a core front end use case and I wonder if condensing > > down to one field is going to cause problems for systems connecting > > to the directory. > > *thankfully* most LDAP connections default to the current system of uid > OR displayName, so this is already taken care of! > > > Another consideration - names may be listed in different orders > > depending on locale. Eg typical Western format is given middle > > surname but other locales (Japan comes to mind) is surname given. Can > > applications connecting to the directory be able to display names > > appropriately for a given locale if there isnt a way to parse them > > out correctly? This locale ordering isnt an issue for single names, > > but 3+ names make it I am > > imagining nearly impossible to programmatically parse the user input > > in any reliably correct way. > > We already have complete UTF8 handling in the server, with sorting and > ordering available. > > In terms of "displaying this in correct order" you are right that > Japanese prefer family name: This is still already a challenge in the > current design of the server regardless of the field used because of: > > uid > cn > givenName > surname > > None of these properly encapsulate the "international" nature of names. > They are very "western". If we display: > > givenName surname > > We work for western cultures, but not japanese > > If we do: > > surname, givenName > > We may work better for japanese, but this isn't consistent to western > standards. > > And finally, to make it fun - singlenames. How can we handle this? > > > Thus we arrive at the conclusion - we have a cultural and social > concept, that technology can not represent simply. To have a single > "displayName" and "legalName" field, allow expression of all cultures > names and styles, and we can choose how they are filled in in a way > that is meaningful to a human. We can use ldap's fast querying to help > humans search these fields and still get meaningful data, and we have > to as humans, apply context to the name to understand it (and respect > it). > > > > > Hope this feedback is helpful. > > It is thank you! > > > > > Cheers, > > ~m > > _______________________________________________ > > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.o > > rg > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > _______________________________________________ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org >
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
