Data accuracy is very important for having a well-functioning application. The most risky place where bad data can be introduced is user input. Entering an address is a worldwide example where getting it right (valid and complete) is not very straightforward.
I can think of two approaches for making sure that a user entered address is accurate (valid and complete):
This is the conventional mailing (aka postal) address method. This one is not very straightforward to get right, since:
- There are lots of fields to enter.
- Formats change between countries and in some instances, even within countries.
For this method, the best way that I can think of is the following:
-
From a drop down list, make the user choose the country for the address they want to enter.
-
Provide the user with a single text field to enter their address. This field should be sending queries, in real time, to an address completion service. That is, you should be using a reliable address completion service ("reliable" meaning containing a correct and complete collection of mailing addresses and able to match a partial, free form address to these structured addresses). After matching an address, the program should auto fill the individual fields (such as state, city, road, building number, unit number, postal code, etc.) that are returned from the address completion service. Note that the variety of fields would depend on the country.
The most important component here is the address completion service. Specifically, the ability of the address completion service to:
- Contain a complete and correct list of mailing addresses, which are frequently updated.
- Match a partial, unstructured address to a structured address that is in their database.
-
After such match(es), return the structured address(es) in a structured way. That is, the response from the address completion service should put specific fields (such as state, city, road, building number, unit number, postal code, etc.) to their respective fields, instead of, for example, aggregating them into a single string and returning it.
-
After auto filling the individual fields, the program should give the user the ability to change the values of these fields, or just submitting the address. That is, the fields that are auto filled should not be made uneditable.
-
After the user submits the address, whether with or without making changes before submitting, the server should send the received address to the same address completion service that was used on the front-end.
- If the address completion service returns the exact same address with the submitted address, the address is saved to the database and the address input process is successfully completed.
- If the address validation service returns a different address, the address returned by the address completion service should be offered to the user and the user should be allowed to:
- Approve it
- Reject it (use the address submitted by the user)
- Make changes on it
- If the user approves the suggested address, the address is saved to the database and the address input process is successfully completed.
- If the user rejects the suggested address, the address submitted by the user is saved to the database and the database entry is marked as needing human attention. Later, a customer service agent would have a look at the address and try to figure out if the address is valid or not. The representative might get in touch with the user if the address does not seem to be valid.
- If the user makes changes to the suggested address, the address is saved to the database without further validation, but the database entry is marked as needing human attention. Likewise to a rejected address, a customer service agent would have a look at the address and try to figure out if the address is valid or not. The representative might get in touch with the user if the address does not seem to be valid.
Pros:
- The conventional method of entering an address. Meaning this is what a user is used to, compared to entering latitude and longitude.
- A conventional address might be required for various reasons, such as compliance, validation, etc reasons.
Cons:
- Much more work involved, such as the use of an address completion service. This is sort of a big deal because of the concerns like:
- How reliable the service will be in terms of availability and latency.
- How reliable (complete and correct) the data of the service will be. This includes how frequently the data will be updated as well.
- How much the service will cost.
- When will any of the parameters above be changed. That is, if the service will be discontinued, reliability of the service or data will change, service fees will change, etc.
- Also, even just searching for, evaluating and testing such services is a work in of itself.
Instead of an address, just ask for coordinates (latitude and longitude), or a variation of it (such as what3words, plus codes, etc.). Wherever the user lives (such as a house, an apartment, an underground tunnel, etc.), all of these must (eventually) have an entrance from the ground level. Hence, it should be sufficient to ask the user only the following two things:
- Coordinates (latitude and longitude) of the entrance to the user's premises.
- A text field (without any format restrictions) to let the user enter more detailed information such as unit, building or floor numbers, instructions on how to navigate to the user's actual location from the entrance of the premises, etc.
Pros:
- Completely independent method. That is, the conventional method depends on the address providers (such as municipalities) to function. If buildings, roads, etc. are changed, most likely an old address will become invalid. No such risk with this method.
- Arguably much more accurate compared to a conventional address.
Cons:
- Might be more prone to errors and cost of errors are higher. That is, as long as the user enters valid coordinates, that's a valid address. However, if the user has entered wrong coordinates by mistake, the delivery will be made to the wrong location.
- Less room for error-recovery. Similar to the previous point, as long as the user enters valid coordinates, that's a valid address. That is, a change in one digit of a coordinate will not make it invalid, but it might make the delivery to the wrong location. This problem does not happen with conventional mailing addresses. That is, a one character change in conventional mailing addresses does not result in a big change in most instances.
- Non-conventional way of specifying an address. Might confuse or turn-off the user.
- The points above might be alleviated by providing a good user experience during the process of entering the coordinates. That is, for example there would be text boxes for coordinates, and there would be a map below it. The coordinate text boxes and the map would be connected both ways. That is, whenever the user changes the values in the text boxes, the pin location on the map would change and likewise, whenever the user changes the pin on the map (either by making a text search on the map or by moving the map manually), the coordinate text boxes on the map would update.
- Might be problematic for legal (or otherwise) compliance. That is, conventional addresses might be a requirement for legal (or otherwise) compliance reasons.
- Might be problematic for business partners, such as the delivery partner might require addresses to be in conventional form.
- Heard about more cons around the web, like the cons inherent to the GPS technology itself, such as GPS being not very accurate inside buildings or that the GPS satellites will be gone one day. I'm not sure if these are actually valid arguments, since coordinates and GPS are two different things. That is, GPS gives coordinates but the coordinate system existed before GPS. However, it might be the case that GPS has made them practical to use. If that's the case, these might be valid arguments.