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 provides a facility to
search that list - but sometimes not! If you have a list of 200 people
paged out to 20 pages with 10 rows per page, no front end specific
filter box or ability to export, a browser search tool isn't going to
help you. This also makes the assumption that all data is consumed on a
computer, which is certainly not the cases, written reports, signage,
posters, registrations (say a list of attendees at a conference given to
security to check against badges at the door), are all consumed on dead
trees.
For years in open source we have had "handles" instead (for example, firstyear for me). We have no issue just "sorting by handle" and "letting people choose their handle" etc. We have all this software that works "just fine" in this environment, so I think people will cope if we just sort by "displayName" :)
The issue isn't with the name a person has chosen, the issue is with how
they are identified by others. There is a definite subset of the
population who knows who I am who knows me by "mizmo" a simple single
name, but many more people who know me by much more complex and varying
compositions of strings and those are equally valid identifiers.
There are many varying ways culturally to express an identifier or set
of identifiers to one given person... but any single person also has
many different identifiers they may choose to use depending on the
context. I think a flawed assumption I am seeing here is that it's one
canonical identifier <=> one person when that's not how it plays out in
real life. Sometimes the context is based on rank, sometimes it's based
on the environment (a Japanese person may state their name in Western
order in a Western country but in Japanese order while in Japan),
sometimes based on family / closeness, sometimes just based on
community. That's why flexiblity around the different tokens in an
identifier string is important to usability in interfaces that involve
tasks around finding and listing personal identifiers.
In the end this is just the defaults shipping with the server, correct?
I do not know how often deployments just go with the defaults rather
than use their own scheme that could be more accommodating to front end
usability.
~m
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
