FB's email policy is equally braindead. My email address used to be mail@sriramkrishnan.com - they disallow names like 'mail', 'admin', etc. So I had to come up with a new alias just for FB.
But I keep getting hit by this in odd ways. Like with the FB+Heroku integration - I couldn't get FB to accept that my Heroku login was valid because it was failing the 'Is this a suspicious alias' test.
If someone from FB is watching, you would save me a great deal of annoyance if you help me get around this.
If I'm not allowed to assume names fit into the set of Unicode symbols, what do I use for a name field in my database? An image field? What if a dragon whose name cannot be printed attempts to sign up for my service?
Someone who decides to identify themselves with Klingon (whether their parents gave them that name or not) should expect to have an alias ready...
That article doesn't claim that your software must support all of those use cases; it exists to explain that those use cases exist, because some people genuinely believe otherwise. If you write something highly specialized with a strong need for a universal representation, such as genealogy software, you might need to deal with the strangest corner cases. Most services, however, can get away with two simple rules: don't ask for a name if you don't need it, and if you do, use a single Unicode text field and don't try to parse it.
Should a Japanese octogenarian whose parents had the poor taste to spell their child's name with a character that would not make it into Unicode expect the same problem?
I believe that ISO2022 allows for the full set of japanese names (and has some sort of process for introducing new kanji). That's probably a big part of the reason that Ruby's strings are bytes with an encoding attribute, rather than just being unicode.
Ruby was designed as utility goop for Japanese programmers. Inability to parse/output legacy encodings would have rendered it virtually useless for that, even if legacy encodings were strictly dominated by any available Unicode encoding, which many Japanese programmers would hotly contest.
The Ruby thing is probably due to the fact that EUC and Shift-JIS were then (and to some extent still are) the prevalent encodings. It's not so much about character sets, after all Unicode includes every kanji defined in ISO-2022. Please see my other comment in this thread.
Japanese computer systems are often not using Unicode but are based on other encodings like shift-jis.
Even if it wasn't for historical characters that aren't part of Unicode, this will probably stay that way because of the inefficiencies of encoding Asian text in e.g. UTF8.
That's part of the reason the ruby programming language didn't have proper Unicode support for a long time (and now supports arbitrary encodings for its strings, not just Unicode ones)
> Japanese computer systems are often not using Unicode but are based on other encodings like shift-jis.
That's true but doesn't really answer GP's question. Shift-jis is an encoding for one of the JIS X character sets. Unicode includes all the characters defined in JIS.
Though if we enter into details it gets a bit messy due to the complications due to different simplifications occured in (mainland) China and Japan, questions about different glyphs for the "same" character, etc.
Name representation in your DB may not match original. I think it even might be fine if you only allow ASCII to input names—most people who use a computer are probably used to writing their names in latin alphabet. But you should accept that the name you store is just an alias, a person identifier. And other points are valid: you can take into account others including #7, #37, #38, #18.
I think it's more about business process than technology limitations.
"I think it even might be fine if you only allow ASCII to input names—most people who use a computer are probably used to writing their names in latin alphabet."
But why? Why tell people they are second-class because of their alphabet preference?
Well, among Patrick's claims are that it's probably impossible to input all possible name even with all the power of Unicode, and that there are other limitations that prevent accurate representation of names in computer system, including human errors.
So my point is, maybe then it's better not to implicitly promise that your system has no limitations at all, but make these limitations more obvious instead. This'll help to avoid surprise errors and ensure consistent user experience by setting correct expectations.
I admit that most users today expect systems to accept their names in their language though, and that it might be an edge case depending on particular occasion, but then I can see why most payment systems apparently still accept only latin letters (cardholder's name is an example).
For the dragon, you can use a password field to hide the name, which satisfies the requirements.
Actually I think the image field is a good idea, just have everyone use a typed alias and then draw/render what they want to be called. Maybe an image and/or a sound, to be more inclusive.
I think his reference to Unicode code points was actually based on UTF-16/8 mismatches, as in "Don't assume one character == one 16-bit char", since the upper code points (U+10000 and up) actually use two chars in, e.g., Java's UTF-16 representation.
There's a lot of code out there that works fine with one-char code points but breaks on two-char code points.
I don't think that's what he meant. A surrogate pair in UTF-16 is still referring to a single code point. It's a good point that it's a place where people could screw up in dealing with Unicode, but it doesn't match his complaint.
What does match is the fact that you can use a huge number of combining characters [1] to form a single glyph; each combining character and the base are a code point, so in order to figure out how many glyphs there are you have to iterate with the knowledge of what code points are combining characters.
Keep in mind UTF-8 can represent everything in Unicode without the surrogate pairs that make UTF-16 as annoying as it is.
UTF-8 is inherently variable-width, but it's a flat scheme in that one universal mechanism suffices to represent everything you can represent.
UTF-16 appears fixed-width until you realize it isn't, at which point you discover it's segmented and the segmentation scheme is both somewhat complex and likely to be missed entirely in naïve testing.
I completely agree. It would be one thing if you had the prevention in there but somehow had the ability to email them and get it worked out but, instead, Facebook completely ruins the UX for this person.
My favorite version of this problem was an old cornerback for the Patriots named Randall Gay. His friends/family couldn't go to the NFL store to get custom jersey's made because his last name is "profane".
There's actually a few in there that could turn up as names. But a lot of humor in that list. "Flogging the Dolphin" is not allowed on the back of NFL Jersey's if anyone was thinking of that. (and if Pud is viewing this thread, don't try getting your nickname on the back of a jersey)
Sounds like they are discriminating against people based on sexual orientation. (e.g. a homosexual man who is a big fan of sports might want to wear that at a gay pride parade). I presume this is USA, in which case ye need to make some proper equality law, if it's EU, then sue em.
Facebook's naming policy hasn't stopped me from making up comical fake names for testing. It's pretty absurd to think that any developer is going to make test posts from their app/project/whatever to their real Facebook account (not that I have one anyway).
A few years ago Facebook banned a fake account that I created for deploying a Facebook app for the company that I worked at. With the account banned we couldn't get access to the app to support the tens of thousands of users it had. Luckily Facebook did end up reinstating the account after we appealed for a couple weeks, though they did force me to change it to my real name.
It serves more as a warning than a finger point. Problems like this will continue to pop up as long as misconceptions exist between what developers think people do and what people actually do.
I guess the first part is fair. But I think there will always be misconceptions between what programmers initially think, and reality. I'd actually prefer "simplifications" rather than misconceptions.
Every product I've seen starts out pure, beautiful, etc... Then the edge cases start getting reported, and pure beautiful code very rapidly gets dragged down to earth.
You unsimplify code as needed, as exceptions crop up.
A friend told me that her programmer husband once used the cat's name to test a system he was working on. They soon had credit card offers for the cat. Yet, like this lady and others here, I recently ran up against frustration I can't seem to fix when a brand new account was deleted.
I used to naively think my name issues were limited to people being unable to spell or pronounce my names. But, no, it gets betterer.
My ex husband was a "jr." I still get credit card offers for my first name last name jr. I also once had a really nutty phone discussion with a marketer where I tried to flippantly make the point that I can't be a junior since I got married and thus no longer have the same last name as my mother. They didn't seem to get it.
I thought I would escape my name issues by marrying. No dice. I thought I would escape them by going by my more common middle name. It doesn't help as much as I hoped. It's like a curse.
Perhaps it is too soon after waking up to have a sense of humor, but the flaw with your plan is that I am divorced and would be highly unlikely to intentionally have a child out of wedlock. And if I remarried, I would be highly likely to take a new name. (Though, given my post divorce relationship track record, the new name would probably be foreign and something I couldn't spell or pronounce, much less other Americans.)
Glad you brought that up—my father is a third, and my mother didn’t change her name when they married, so they both have their share of name-handling issues. Makes me almost glad to be boring old Jon W. Purdy.
My first and last names are the same (probably you can guess what they are without even googling...), and Facebook around 2006 also rejected me. I don't remember if I emailed them to resolve it or just waited and tried again later.
A popular thing to do when you have the same name as a celebrity is go by a different version of your name. "Mike Jordan", "William Smith", and "Thomas Jones" sound like plain, common names instead of the names of celebrities.
Ok, now I don't feel so bad about having worked on a system that was confounded by people having the letter ñ in their name. (Surprisingly, it had no problem with someone else whose middle initial is the number 8.)
Years ago, the University of Waterloo licensed technology from Ask Jeeves for "Ask the Warrior." (The Warrior is the name of the school's athletic teams.) This site was targeted at prospective students, who could ask basic questions such as "how many students are in the Math faculty?"
However, if you Asked the Warrior what "concordia com veritate" (the university's motto) meant, it told you not to use dirty words.
There are people who don't identify with a gender and aren't going to be included in any list of them you'll be able to come up with.
Don't bother saying "What if I check between their legs?" or anything like that, because gender and sex are two different things that are merely strongly correlated in most people.
I think it's a stretch to say that physiology plays no role in defining gender. Say the gender drop-down is being used on WebMD to present biologically-relevant information for someone ... then the gender drop-down helps to identify what physiological issues the user's body is likely to experience.
> the gender drop-down helps to identify what physiological issues
Web sites that need to know how a person is physically constructed as opposed to socially constructed are going to be rare.
But even then, the physiology is not always always binary: "1 percent of live births exhibit some degree of sexual ambiguity.Between 0.1% and 0.2% of live births are ambiguous enough to become the subject of specialist medical attention" - http://en.wikipedia.org/wiki/Intersex#Prevalence
Well what if someone is trans gendered? What about a trans women who hasn't changed her birth cert, but has gotten a sex reassignment surgery (i.e. has a vagina now, no testicles) and has been taking female hormones for years? What should they put down? They are probably more likely to have female medical problems than male.
Then they should choose whatever is most applicable to their special-case. And really they're unlikely to have female problems given that while body parts are shaped into something resembling the other gender, they don't truly have functional versions of these body parts in the traditional sense. A man that becomes a woman doesn't ovulate or cannot become pregnant for instance.
Look, EVERY website is built based on some assumptions. Sometimes it's that people comprehend a certain language. Sometimes it's that they're using a browser with support for images and they're not using LYNX. The general assumption of most websites is that their user hasn't changed their gender ... and while I'm sure there's some equal-rights group that would disagree with me, I think that's a fair assumption. I'd also bet that for the vast majority of sites that request gender information, that input is unlikely to ever have an impact on the user's experience on that site.
If a user has transformed their identity, then I think they've also taken on the responsibility of figuring out how that new identity will navigate the real-world. That means a woman that identifies as a man can enter "Male" in a gender drop-down if that's how they choose to self-identify, but unless they've had a surgical procedure to change their physiology, then they're still going to need to operate their body like any other woman would. If they're in a pharmacy, that means buying feminine products to maintain their body. If they're on WebMD, that may mean declaring themselves as a woman to get relevant content. If they're on a dating site, maybe it makes sense to declare themselves as a man ... much to the potential future chagrin of their date.
Yep, lots of things are based on assumptions, but one should also look at your audience. E.g. an endocrinologist (hormone doctor) will probably see a large percentage of trans patients.
> I think it's a stretch to say that physiology plays no role in defining gender.
I never said that was true in all cases. In fact, I said it was strongly correlated with gender in most cases. However, it isn't an absolute determinant, especially if you equate 'sex' with 'genitalia'.
The detection may not be more sophisticated, but the UX is a bit better now. Now it says "Our automated system will not approve this name. If you believe this is an error, please contact us." The "contact us" links to https://www.facebook.com/help/?faq=212848065405122. In that FAQ, it explains that you need to use your real name, and leads to another link where you can appeal the automated decision: http://www.facebook.com/help/contact/?id=237843336274237. You have to upload a government-issued ID to get the account.
It's quite often the case that things that seem braindead just don't matter. That is, if this practice blocks a lot of illegitimate accounts, then the only person who cares that it happens to block yours too is you. I'm not defending the practice, I'm just saying there's no money in accommodating edge cases.
Nearly every complaint about crappy customer service ignores that large companies don't have much incentive to improve at the margins.
While we're on the topic of poor programmer assumptions, here's a problem a developer ran into with his family tree software when it turned out there was a cycle in a user's tree (father had children with his daughters):
Since no one else seems to have noted it: the OP is not just a Fake, she's a famous Fake: http://en.wikipedia.org/wiki/Caterina_Fake You'd think the cofounder of Flickr would be treated with more respect by a computer...
But I keep getting hit by this in odd ways. Like with the FB+Heroku integration - I couldn't get FB to accept that my Heroku login was valid because it was failing the 'Is this a suspicious alias' test.
If someone from FB is watching, you would save me a great deal of annoyance if you help me get around this.