Across the world there are many different ways to describe someone's address. You can use latitude and longitude, What3words or, more commonly, some address lines. These address lines come in all shapes and sizes. Here are some of Google’s offices from around the world:
This poses an interesting challenge for developers. If you want to build an international app which requests an address input, how do you ask for that data? How do you then model it?
When you think of addresses and maps, you can’t help but to think of Google. They have mapped the world and continue to bring new technology to the mapping space. So how do they map addresses?
Google uses a format called KML. KML is a file format used to display geographic data in an Earth browser such as Google Earth. It is an international standard maintained by the Open Geospatial Consortium, Inc. (OGC) and is the foundation of Google’s address handling.
KML is broad, and contains more than just address information. But buried within this XML standard is a node called AddressDetails.
<AddressDetails xmlns="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"></AddressDetails>
This node is what contains an address. It follows a format called xAL. xAL is another XML standard and is a standardised way of representing an address.
This XML standard can be applied in many different ways depending on how complicated you need to go.
In this approach we have a list of strings to represent the different address lines. The benefits of using such a crude approach are that you don’t need any understanding of the addresses.
However to collect this data you are unable to guide the user on how to input it. They have to enter an indeterminate number of lines of text.
Example:
In this approach, we have a nested tree of elements, which at their root have a string for addressLine. This is nice because there's a bit more structure to the list of address lines. But this still lacks that extra bit of detail.
Example:
Here we have added a slightly deeper tree. Also, instead of using addressLine, we have named the elements. These result in a more detailed model and actually this should fit a lot of use cases.
Example:
The only change we have made here is to add some more detail to each of the nodes. This enables us to capture more specific details if they are required. And there are many more details we could have added.
Example:
So which one should you choose? It depends on your specific use case as to how much detail you need. For example, are you building an app for a postal service, requiring specific information? Are you using the users address to find their nearest store locations?
I would recommend using at least the simple approach. The formal approach is a good default for most. These provide good levels of detail and enable you to build great user experiences.
Collecting addresses from users can be a complicated process. You want to ensure you collect enough information but make it as easy for users as possible.
Sadly there isn’t a single approach you can take. You need to provide a different form per region. These forms can then use specific knowledge of that region to give the simplest form possible. As I recommend for most things, get out and speak to users. Users within those regions will know more about the address format than you will.
A better approach though is to have no form at all. There are API’s available which enable you to ask the user to search for their address using a single string. This means you don’t have to worry about region specific knowledge.
I recently worked on an app which required the user to enter their address in order that we could arrange a collection from their house. This app was international and we wanted to provide a simple experience for the users.
We used an API called CraftyClicks. This enabled us to provide quite a smooth searching, drill-down experience.
Data Structure:
Although there is no depth to this model, you should notice many similar elements that we have previously mentioned.
Example:
Deciding on address formats can be difficult. But using the xAL structure (or similar) and keeping it as simple as you can, you can write a thorough, multi-region format. Remember, keep the user experience as a priority.
Search over 400 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!
We develop intelligent mobile apps for iPhone & Android that deliver for you.
Want to connect? You can find us on Instagram, Facebook, X (formerly Twitter) and LinkedIn.
Here’s our privacy policy.
Here’s our Accessibility statement.
Copyright © 2024 Brightec Limited. All rights reserved.
