Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In my registration form I have to get user's Machine-readable passport number:

http://en.wikipedia.org/wiki/Machine-readable_passport

I am talking about the second line which contains 44 digits & characters. (See wiki for correct format). Unfortunately, there's no way around it and I have to get this data and validate it against an outside service in order for the user to logon.

I'm looking for a good way to get this data? Maybe make the experience more fun in some way? While also helping the user to not mistake when he copies the data.

share|improve this question
4  
I don't think there is ever going to be a 'fun' way to manually copy a 44 digit reference code from something physical into a digital form field. Unless you have the option to hook into a webcam / phone and OCR the data. –  JonW May 2 '12 at 12:11
1  
Presumably you're going to auto-validate each of the 11 sections for the correct alphanumerical content type, and check some ranges within sensible values and validate the check digit for each section. Idea: After manually entering the number, click a button to get the computer to 'speak out' the entry while the user listens and reads the number on the passport at the same time to verify it. Use different voices to make it 'fun' –  Roger Attrill May 2 '12 at 12:26
    
@RogerAttrill And risk other people in the room hearing sensitive information and copying it down? At the very least make such a thing optional, it sounds annoying and time consuming. –  Yamikuronue May 2 '12 at 12:46
    
@Yamikuronue You'd use headphones of course! –  Roger Attrill May 2 '12 at 12:49
    
Can you read it off the embedded chip in an e-passport ? –  PhillipW May 2 '12 at 12:51

2 Answers 2

up vote 3 down vote accepted

It seems to me there's an easy way to cut down on repetitive data entry here but it needs to be user-tested.

Per the specifications, the first line of the code contains only the letter P, passport type designation, issuing country/int'l authority, and the holder's name. All of these are usually collected separately during the normal application workflow and can be easily parsed for validation.

The second line of the code is a little tricky because, at the first sight, it looks like a string of random numbers without much meaning. In reality, it's the passport number, the holder's nationality, DOB, and sex, the passport's expiration date, holder's personal number (optional in some countries), and check digits for these strings data. The key points in the second line are that a) the holder's sex is the only letter among many numbers, b) check digits are calculated with a known algorithm, and c) some countries include the personal ID number in human-readable format.

With so many pieces of code available in human-readable format, it makes sense to collect the information through "generic" questions (such as legal name, DOB, passport number, etc) and use a front-end script to populate a field with the machine data ending with the gender digit. The reason here is that gender is the only letter among many numberes, which makes it the most easily identifiable separator after the less than sign. The system then prompts the person to complete the remaining information (passport expiration date and on) manually. This way the additional data entry is going to be just 23 characters instead of 44.

You should also make sure to use a monospaced font in the field containing the machine code in order to resemble the real-life one as much as possible.

At the point when the applicant gets to it, the data should look like this (check digits aren't correct) if the passport doesn't have the ID number in human-readable format:

P<USADOE<<JOHN<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
1234567894XXX9901013M.......................

If the passport has the ID number in human-readable format, the system can fully populate the field and ask the applicant to verify the data. However, you need to know what countries do and don't include ID numbers as a separate field of their passport's main page.

share|improve this answer

A good place to start to help the user make sure they've entered it accurately is to come up with an appropriate number grouping system (similar to that used on credit cards). This is called chunking. In your form you can ask for the number in groups of digits next to each other.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Fortunately (or unfortunately) there's only one good way to subdivide 44 numbers - eleven groups of four. Any more than five or six at a time and you risk overloading the user's short term cognitive capacity. Any fewer than four and checking will become more tedious.

EDIT: As Roger and dnbrv rightly point out below, the standard itself may dictate a particular format that doesn't use equally-sized chunks.

Your major focus is going to have to be on persuading the user that checking the numbers is a good idea. You may want to consider some sort of visual indicator when the user changes focus as a reminder, or checking to see if there is any pattern to the numbers which doesn't make sense (eg. do the numbers match the specific format specified as part of the standard?) and flagging any errors to the user.

As for gamification or other methods to make the experience more "fun", I'm coming up blank on that one. I'm not sure how you'd go about making the entering of a string of characters both fun and guaranteed-accurate at the same time.

share|improve this answer
1  
I would definitely tend more towards the groups of letters and numbers that actually make up the format (as per the wikipedia link) rather than 11 x 4, but that's just detail. –  Roger Attrill May 2 '12 at 12:47
1  
VERY bad idea to use chunking here. Data entry field must correspond to the actual data being intered. In the case of passport data, it includes the country code (3 characters), the holder's full legal name (variable number of characters), the holder's DOB (6 characters), etc. –  dnbrv May 2 '12 at 12:48
    
plus lots of checksum digits. But chunking was one idea we thought about (only with different chunks). Maybe even pre-fill some of the chunks like country code which we can acquire a different way. –  Faruz May 2 '12 at 12:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.