Hacker News Reader

Comment by smackfu | Hacker News Reader

And then when you get a business requirement to sort by last name, tell them "there is no such thing as last names."

Then when they finish laughing, hack up some system to split the single name field that doesn't work very well.

(It gets even worse when you have unusual sorting rules that really only apply to Western names, like treating Mc and Mac the same.)

View on HN

True story: I once told a customer that their requirement to "sort by last name" was likely impossible to satisfy without reworking the system, given what I knew about their user base. It turned out that I was right: the majority of their staff was Japanese, who expect Japanese lexicographic sort. However, they also had visiting professors from overseas, who largely could not understand Japanese lexicographic sort. (There are actually two common lexicographic sorts in Japanese, based on two ways to order the sounds of Japanese. We use the "table of fifty sounds" method, under which Tanaka comes after Aki but before Sato.)

My customers said "Fine, alright, two sort features. One for Japanese, one for foreigners."

They were less than happy when I told them that foreigners haven't agreed on lexicographic sort, either. (To use one example I'm familiar with, in Spanish, "ch" is one letter, so Chisako comes after Consuela.)

Oh, there is a separate right way to order prefectures. (Which I learned about in an email from a coworker saying "Patrick, come on, use some common sense next time. Have you ever seen prefectures listed lexicographically before?!")

In Spanish, at least, the ch is no longer considered as a separate letter for sorting. It is still a separate letter in lists.

http://en.wikipedia.org/wiki/Ch_(digraph)#Collation

Yeah, that was an interesting adaptation from the Spanish language academy to the use of computers. At the time there was some public debate similar to the "pluto is no longer a planet".

So, what did you end up doing? I'm very curious.

"hack up some system to split the single name field that doesn't work very well."

You've correctly identified a problem, but misassigned the responsibility. The problem with the single-name split is that it is impossible, full stop. When you forcibly try to do the impossible, you always get bad results.

You appear to be proposing that we force the users to enter first and last names, then we can trivially sort them by last name. But for the exact same reasons you can't write a name splitter after the fact, you can't have the user break their names into "first" and "last" either. You haven't solved the problem of there being "no last name" by changing your input form. You've just moved it around. Now it irritates the customer instead of you, which is often a bad trade, and sort by last name still doesn't work because customers for who a first/last split doesn't work have fed you one or another variety of garbage data. Garbage data which is now even harder to find; at least when you had a one-word name you had a clue that there was no first/last split.

In this case, you should dig deeper. If the customer says "give me sort by last name," the actual requirement may be "give me an easy way to find a person by last name." In this case, a general full-text search may be the best solution.

This is the right way to do it. Due to user error. I've had problems checking into a hotel until the receptionist realize my first/last names are switched.

The receptionist SHOULD be shown a list but ALSO wants to be able to search for me if I don't show up in the list (and may ask for my ID/get a particular spelling).

(It was a comp'd room in Vegas, so I have no idea where the mistake was made, but this can't be a unique occurrence.)

My project has a "sort by last name" requirement, but we wanted to accomodate "funky" names. Here's what I did:

There are four fields in the database:

  first_name
  last_name
  display_name
  primary_email

All 3 name fields are optional. The email address field is required, but you could use a customer ID or username if that is more appropriate for your app.

The name are never accessed directly, except on the one form where you can edit these fields. In general, they are accessed by these two helper methods:

  @property
  def name(self):
      if self.display_name:
          return self.display_name
      if self.first_name and self.last_name:
          return self.first_name + ' ' + self.last_name
      return self.primary_email

  @property
  def last_first(self):
      if self.first_name and self.last_name:
          return self.last_name + ', ' + self.first_name
      if self.display_name:
          return self.display_name
      return self.primary_email

Then we do a culture specific case insensitive sort. This should cover most cases pretty well....... I hope :-)

Well, as far as I can tell, you are screwed anyway you do it, so you might as well do the simplest thing.

For a Western company, that may be: use a first name and a last name field which works for 95% of our customers and inconveniences the other 5%. But that 5% is already used to it.

Which of course goes against the spirit of the original article.

Yeah. I think I would personally go for two fields -- first name and last name -- with a hint that 'if unsure, use lastname' so that the rather common(?) 'sort by lastname' would make at least some sense in most cases, and the requirement that at least one of the names must be non-empty.

Reply on news.ycombinator.com