Imagine if you last names were say alice bob. But you wanted to be found under "alice bob".
>Today, you would not, you would be found under "bob". Not what we want
at all! And our singlename friend
>would not even be allowed to exist at all (do you make their givenname
the surname? That's not right either ...).
>
This is just disrespectful to both of these individuals :(
William, "* alice bob" wanting to be found under "alice" is the exact
case I am concerned about here.
I get the top-level issue here. It impacts me personally.
My concern is whether or not there are affordances / ability for front
end developers to create usable interfaces on top of this system. The
data is polluted without multiple fields, because you have no way of
knowing if ""alice" is a middle name, a front surname, or something
else. There is no way to know how a given name string is meant to be
used unless the person identified by the name themselves is given a way
to indicate their preference directly. That's why additional fields -
labeled in more cross culturally conscious ways absolutely - could help
front end developers create more culturally sensitive front ends that
are also usable.
A single field for personal identifiers is not a usability issue when
looking at any single person. It becomes an issue when dealing with
personal identifiers in the aggregate. Some of the issues are not new,
but exacerbated by forcing a single field.
I am also open to being completely wrong, of course, I just want to make
sure my concern here is understood and clear before bowing out. A lot of
my job designing front ends is impacted by limitations of backends (one
of which is a personal directory) which is why I've bothered to say
anything in the first place.
Your "frontend" with it's "western" style of "lastname, othernames" can not accommodate these people :(
Why are you placing frontend in quotes? I mean a literal frontend. Is
this part of the misunderstanding?
We have the ability to order by displayName, and the ability to search on any
> substring of the name so you can find your identity efficiently.
It appears to me that with only globs and no regexp that isn't quite the
case, unfortunately. Unless I missed something in the back and forth
upthread.
As a result, sort by displayname and searching is really the best way to get access
> to this, even if not perfect, because we allow people to express
their name and
>
identity in a way that is meaningful to them :)
There are a lot of problems with display name sort, because it assumes
the first ordered name is the one you want to be listed by. You may
prefer to be listed by a name other than the first ordered. Assuming
anyone inputting their name that the first ordered name is the one they
want to be listed by is problematic for me personally:
- Because of how ASCII sorting works, my name "Máirín" in alpha-sorting
order is not found between Mary and Melanie; á is sorted after all
non-accented vowels. This isn't intuitive, and my name has been placed
this way in lists before and people have been unable to find me in the
listing.
- It's a flawed assumption that everyone can input any part of any
person's name. The vast majority of people in the US do not know how to
input accent mark characters and thus cannot spell my name, so they will
not be successful in searching for my name by first / given name anyway.
(Search for "Ma*" and my name won't come up.) This is exacerbated with
personal identifiers outside of the ASCII character set; how will these
folks be found in an aggregate listing?
- A lot of the iterations and attempts to find a given person play out
one way when there's a single person interacting directly with the DS...
eg you say "people will quickly see" except which people? Because the
programmer for a front end might not find out except via bug months or
years later. Things are a bit different when it's used as a backend to a
front end and there is an abstraction layer or two inbetween and lists
of names generated programmatically - because the impacted people will
just see something weird in the front end and not be able to trace it
back, or they won't receive some automated email and never even know, etc.
Too many "brown"s? Just search "william brown". Or even just " brown"?
You have to be looking for a specific person for that case to work. The
specific task you are using as a counter example (finding a specific
person X) is not the same case I am concerned about, which is generating
a list of people. For example, a front end developer connecting to the
directory server to generate say a report of employees local to a given
office that are eligible for a promotion - which then gets propagated to
some HR dept dashboard or printed and given to a site manager and used
for some purpose. Yes, where a list appears on a computer screen, often
times either the desktop, browser, or app itself
