On Jan 8, 2008 10:42 AM, tedd <tedd.sperling@xxxxxxxxx> wrote: > At 10:18 AM -0500 1/8/08, Eric Butera wrote: > >On Jan 8, 2008 10:08 AM, tedd <tedd.sperling@xxxxxxxxx> wrote: > >> I just finished a credit card portion for a site where the programmer > >> before me required the customers to enter their credit card number > >> without spaces -- why? It's a simple matter to remove spaces for > >> processing -- why throw that responsibility on the user? > > > >I agree that removing spaces really isn't a huge deal, but aside from > >that I don't think there should be any other modification. I've seen > >code that will regex out anything but numbers. I think this is bad > >practice because we as programmers should validate, not modify data. > >Anything above and beyond that is sticking your neck out too far and > >will lead to problems sooner or later. > > > >What if the user mistyped what they intended? If the script just > >validates it will see the user accidently typed in a letter in the > >field and re-display it asking for numbers only. If it strips out the > >letters, then you've just sent the potentially invalid number to the > >gateway which in the end will be a charge against the client for a > >failed attempt. > > Understood, and agreed. Generally, don't modify the data provided, > but rather validate the form of the data. However, white space is a > different critter in some data and is basically used to help > customers accurately enter/see their credit card numbers. > > It's common for us to more easily identify strings in 3 and 4 > combinations than it is to try to see the entire string at one time. > Research for this has been around for a long time, please review: i agree, but rather than using spaces, or allowing them in the input string, i prefer to have several focused form fields that comprise a larger element. for example, a credit card number is 4 units of 4 digits. my preference for credit card number entry is to have 4 text inputs which take 4 characters each. this is not only convenient from a user perspective in the user interface, but also on the server side. its safe to call trim() on each sequence of characters and concatenate them. if any character is not a digit then immediately the data is known to be invalid (obviously additional checks are important as well [and no more difficult to perform than if a single form element was used to collect the data]). ive also seen sites that will use javascript to monitor the character count in each of these smaller form elements and move the cursor to the subsequent form element once the current one is full. i have mixed feelings, that generally boil down to particular implementations on this design decision; sometimes it works, sometimes it doesnt. but thats up to the designer on a case by case basis. in general i urge clients to have several small form fields when reasonable. it reduces confusion for the user, and headaches for the (server side;)) developer. -nathan
