This post was prompted by my use of back end third party services for the FINDaPAD app and my recent set of posts about push pins and Bing Maps control. I want to explore the affect the design of the back end services can have on a mobile app UX & UI design.
For FINDaPAD we make use of two sets of third party services, Nestoria & UK Crime API. Nestoria is a property search service for the UK and other countries whilst UK Crime API provides crime information for England & Wales, we use the second to generate crime stats for a local area when viewing a property in FINDaPAD.
Even though Nestoria claim on their website 'The API is very much a work in progress.' I believe this be a well thought out API from a consumers perspective, it has a compact data schema (JSON or XML) and it enforces a pagination convention on the consumer which has a bigger benefit for mobile app development than for full blown desktop for the simple reason of CPU performance and power consumption. We use two APIs from Nestoria, one for property details and the other for average property prices - one HTTP GET request for one set of results. It has well defined pagination API which limits the maximum page size to 50.
Shown below is the performance cost of making a HTTP GET request against Nestoria on a tethered WP7 device - it takes approximately 3.7 seconds to request the first 50 properties, decode the JSON and map into a domain model. The relationship between the number of properties downloaded and the time taken to download is relatively linear and predictable and this fact is import when designing how your UI reacts when downloading data - whether it sits there with a progress bar or allows the user to perform other actions.
The UK Police API is a less mature API having been around for about a year, it allows you to query for data by several different criteria.
In FINDaPAD we have to use two separate API calls to get the information we want - two HTTP GET requests for one set of results. First we have to make a HTTP GET request with our geo-location to get the police force & neighbourhood values and then a second HTTP GET request with the result from the first to get the crime stats for the current geo-location. Now this isn't a problem per-se for FINDaPAD because we request the crime stats asynchronously whilst we are trickling the property data from Nestoria to the UI so the user experience is a seem less transition from the details of property to the crime stats for the local area. Ideally this would have been done as a single web request not only from a performance point of view but from a cost - if you're paying for your data plan on your mobile device then you would have incurred a greater cost.
In my 'How many pins...' I was using a UK Police API to return all the crimes in a particular area, this was based on the idea of supplying a geo-location and it would return all the crimes occurring within a 1 mile radius for the last calendar month. This API call works great when tested from a desktop app or the WP7 emulator because both have plenty of processor power, memory and network connectivity. But when running on a device it can be an issue because the returned data set has an unlimited size and the cost in time to transmit this down the wire, decode etc is unknown - fundamentally the API does not support pagination. This is best demonstrated by the following set of screen shots, searches for crimes in totally different locations, one a remote rural area and the other an urban inner city area:
The first screen shot shows the cost to get all the crimes in a rural area (where there are no crimes) and the second in the urban inner city you can see how the elapsed time has increased, if the total crimes in the urban area increases I don't have anyway of calculating how long it would take to request and process going results and ultimately this could lead the user to abandon the app (and give it a bad rating!).
So you might ask - Okay how would you do it then?
If I was going to keep the API endpoint the same - all crimes in a 1 mile radius. I would add pagination support so that I could trickle the data to UI as each request is fulfilled. If I was going to change the API I would like the ability to specify a bounding rectangle so I could request only the visible crimes, this would also require pagination as the number of crimes could be even greater than the 1630 show above. Though there could be a downside to the second approach as this would make client caching more problematic.
Don't be under the impression I think the UK Police API is bad or wrongly implemented, I believe this APIs will mature over time as greater understand of how the data is being used.
Remember not all publicly consumable web services are well suited for use with mobile devices.
For FINDaPAD we make use of two sets of third party services, Nestoria & UK Crime API. Nestoria is a property search service for the UK and other countries whilst UK Crime API provides crime information for England & Wales, we use the second to generate crime stats for a local area when viewing a property in FINDaPAD.
Even though Nestoria claim on their website 'The API is very much a work in progress.' I believe this be a well thought out API from a consumers perspective, it has a compact data schema (JSON or XML) and it enforces a pagination convention on the consumer which has a bigger benefit for mobile app development than for full blown desktop for the simple reason of CPU performance and power consumption. We use two APIs from Nestoria, one for property details and the other for average property prices - one HTTP GET request for one set of results. It has well defined pagination API which limits the maximum page size to 50.
Shown below is the performance cost of making a HTTP GET request against Nestoria on a tethered WP7 device - it takes approximately 3.7 seconds to request the first 50 properties, decode the JSON and map into a domain model. The relationship between the number of properties downloaded and the time taken to download is relatively linear and predictable and this fact is import when designing how your UI reacts when downloading data - whether it sits there with a progress bar or allows the user to perform other actions.
The UK Police API is a less mature API having been around for about a year, it allows you to query for data by several different criteria.
In FINDaPAD we have to use two separate API calls to get the information we want - two HTTP GET requests for one set of results. First we have to make a HTTP GET request with our geo-location to get the police force & neighbourhood values and then a second HTTP GET request with the result from the first to get the crime stats for the current geo-location. Now this isn't a problem per-se for FINDaPAD because we request the crime stats asynchronously whilst we are trickling the property data from Nestoria to the UI so the user experience is a seem less transition from the details of property to the crime stats for the local area. Ideally this would have been done as a single web request not only from a performance point of view but from a cost - if you're paying for your data plan on your mobile device then you would have incurred a greater cost.
In my 'How many pins...' I was using a UK Police API to return all the crimes in a particular area, this was based on the idea of supplying a geo-location and it would return all the crimes occurring within a 1 mile radius for the last calendar month. This API call works great when tested from a desktop app or the WP7 emulator because both have plenty of processor power, memory and network connectivity. But when running on a device it can be an issue because the returned data set has an unlimited size and the cost in time to transmit this down the wire, decode etc is unknown - fundamentally the API does not support pagination. This is best demonstrated by the following set of screen shots, searches for crimes in totally different locations, one a remote rural area and the other an urban inner city area:
The first screen shot shows the cost to get all the crimes in a rural area (where there are no crimes) and the second in the urban inner city you can see how the elapsed time has increased, if the total crimes in the urban area increases I don't have anyway of calculating how long it would take to request and process going results and ultimately this could lead the user to abandon the app (and give it a bad rating!).
So you might ask - Okay how would you do it then?
If I was going to keep the API endpoint the same - all crimes in a 1 mile radius. I would add pagination support so that I could trickle the data to UI as each request is fulfilled. If I was going to change the API I would like the ability to specify a bounding rectangle so I could request only the visible crimes, this would also require pagination as the number of crimes could be even greater than the 1630 show above. Though there could be a downside to the second approach as this would make client caching more problematic.
Don't be under the impression I think the UK Police API is bad or wrongly implemented, I believe this APIs will mature over time as greater understand of how the data is being used.
Remember not all publicly consumable web services are well suited for use with mobile devices.
0 comments:
Post a Comment