1226263 - Firefox Student Ambassadors Form Validation

Status: RESOLVED WONTFIX

(www.mozilla.org :: Bedrock, defect)

Description

[Ben (:bensternthal)]

The following form validation should be added:

1. Last Name
Should always have the first letter uppercase.

2. First Name
Should always have the first letter uppercase.

3. Prevent Bad Characters In Either First Or Last Name
List of invalid characters will be added to this bug.

For 1 & 2 we can either error and have the user change or we can use JS to do it automagically, please use which ever is the best experience for the user (or suggest alternatives).

Jessilyn can you provide a list of characters that you would like us to flag as invalid.

Comment 1

[Craig Cook (:craigcook)]

Validating case on proper names (either people or places) is rather tricky because there are many surnames that correctly begin with lowercase letters. Examples: Guillermo del Toro, Wernher von Braun, Charles de Gaulle, Melissa de la Cruz, Ismail al-Jazari, Olivia d'Abo, and Osama bin Laden. 

Given first names are probably less likely to begin with a lowercase letter, but some people prefer it for their own reasons: k.d. lang and bell hooks, for example. We should generally respect whatever name someone enters for themselves, even if it's unusual.

We shouldn't require a proper name to begin with a capital letter.

Comment 2

[Jessilyn Davis]

Adding Sean to chime in on the invalid characters piece.

For 1 & 2, I recommend to *not* have the form error. From my perspective, we don't want unnecessary barriers to entry to the program.

Craig brings up a valid point. I know Sean is keen on perfect data.

Possible middle ground: Is it possible to have JS to do it automagically and if a user changes their name back to not capital, the form will accept the edit (and not reformat)?

Comment 3

[Craig Cook (:craigcook)]

(In reply to Jessilyn Davis from comment #2)
 
> Possible middle ground: Is it possible to have JS to do it automagically and
> if a user changes their name back to not capital, the form will accept the
> edit (and not reformat)?

Alas, that's probably even worse for users. It would still require showing some feedback to let them know it was changed automatically and that they can change it again and that their edits will be respected, thus making them enter their name twice for no apparent reason. 

We simply can't programmatically determine what is and isn't a correct name based on format alone, so we just have to accept everything. There's just too much variety. We can't even assume a minimum length (some people use a single initial, and two-letter surnames like Li, Ng, and Wu are really common).

We can do a bit more to strip/reject invalid characters, though. We'd need to allow some punctuation like hyphens and apostrophes of course, as well as periods for initials or Jr. and Sr. Also numerals for names that include 3rd, 4th, etc. Parentheses and quotation marks should probably be allowed for maiden names and nicknames, but that's getting a bit edgy.

We can't really match against a set of allowed characters because we have to accept a really broad range of non-ASCII characters like ñ, ç, ø, ß, î, é, and ü. The best approach would be to have a small set of explicitly disallowed characters and accept all others. That does open us to the potential for some nonsense characters like arrows and emoji, but I wouldn't worry about that until it becomes an actual problem. 

So I think the best we can do is define a short list of common keyboard characters that should not be allowed in a name and strip them automatically on the back-end, things like @, #, $, %, >, ?, and ! (though some dialects use ! to indicate a tongue click so maybe even that needs to be allowed).

The moral of the story: Names are nearly impossible to validate so it's perhaps best to not even try. If that leads to a certain amount of junk submissions, that's just something we'll have to deal with.

Comment 4

[Alex Johnson (:alex_johnson)]

Maybe we can use reCaptcha to prevent spam instead?

Comment 5

[Ben (:bensternthal)]

AFAIK spam is not currently an issue or on the list of use cases we are looking to address.

Comment 6

[Jessilyn Davis]

+1 to Ben. The issue is data quality inside of SFDC (CRM).

Sean - how do you want to address this/these bugs? Wait until the CRM Admin comes in to be part of the solution spec/conversation?

Comment 7

[Jennifer Bertsch [:jbertsch]]

Please ping us when ready to move forward. Moving to our icebox until then.

Comment 8

[Eric Renaud [:erenaud]]

Jessilyn - I wanted to ping to see if the CRM Admin is now/can be part of the solution/spec conversation to resolve this issue. (Was this role brought in with Basket?)

Comment 9

[Jessilyn Davis]

Thanks for pinging on this, Eric!

Lots of things are changing with the FSA program (and transitioning this to the new Campus Party program).  Resolving this as wontfix.

Any new Basket functionality needed to support the FSA/Campus Party program will be handled with new bugs and user stories.

Thanks!