This is an interesting usability problem! Firstly, I would say that telephone numbers have been used for decades, and while not ideal, do work reasonably well for most people (especially when written down somewhere).
The problem with letters, when typed onto a numeric keyboard, is that they limit the number of possible combinations rather…
This is an interesting usability problem! Firstly, I would say that telephone numbers have been used for decades, and while not ideal, do work reasonably well for most people (especially when written down somewhere).
The problem with letters, when typed onto a numeric keyboard, is that they limit the number of possible combinations rather than increase them. Also, probably the next piece of information they may need to enter, after the parking code will be the long card number on their credit card, which is 14-16 digits.
One useful thing about using GPS coordinates is that a mobile phone with GPS can cross-check the code typed against the GPS on the phone, sort of like a checksum on what's entered.
One issue with that might be if people mistype the least-significant digits of the lat/long coordinates, because two nearby places might get confused. To prevent that, as with the how I mentioned you could generate easter-eggs before, an actual checksum on the least significant digits could be used, like the Luhn algorithm. You could then just have carve-outs of 'easter-egg' sites.
Whether or not GPS coordinates are used, a checksum of some sort would probably be a good idea.
"the long card number on their credit card, which is 14-16 digits". This is true, though credit card numbers include a checksum digit (and also follow a strict allocation pattern). A checksum digit is also used in ISBNs. Might be useful here too.
This is an interesting usability problem! Firstly, I would say that telephone numbers have been used for decades, and while not ideal, do work reasonably well for most people (especially when written down somewhere).
The problem with letters, when typed onto a numeric keyboard, is that they limit the number of possible combinations rather than increase them. Also, probably the next piece of information they may need to enter, after the parking code will be the long card number on their credit card, which is 14-16 digits.
One useful thing about using GPS coordinates is that a mobile phone with GPS can cross-check the code typed against the GPS on the phone, sort of like a checksum on what's entered.
One issue with that might be if people mistype the least-significant digits of the lat/long coordinates, because two nearby places might get confused. To prevent that, as with the how I mentioned you could generate easter-eggs before, an actual checksum on the least significant digits could be used, like the Luhn algorithm. You could then just have carve-outs of 'easter-egg' sites.
Whether or not GPS coordinates are used, a checksum of some sort would probably be a good idea.
"the long card number on their credit card, which is 14-16 digits". This is true, though credit card numbers include a checksum digit (and also follow a strict allocation pattern). A checksum digit is also used in ISBNs. Might be useful here too.