[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-directory-devel
Subject:    =?utf-8?q?=5B389-devel=5D?= Re: Improve the demo objects from install
From:       Máirín Duffy <duffy () redhat ! com>
Date:       2018-01-17 15:32:44
Message-ID: ad1b5840-a193-7981-1efc-fadb9bc26fd2 () redhat ! com
[Download RAW message or body]

> 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@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org


[prev in list] [next in list] [prev in thread] [next in thread]