Skip to content

USE CASE: FINDING CONTENT

One of the biggest problems in apps that are continuously updated with content, is finding that content in a clear and timely manner. At AIM we believe visualisation is key, as well as options for the user, so they can use the apps that we create in their own personal way.

In this story we will talk about one of the visualisation options, the world map, that we provided to find and use content in one of our apps, which has content based on geolocation.

One of the biggest problems in apps that are continuously updated with content, is finding that content in a clear and timely manner. At AIM we believe visualisation is key, as well as options for the user, so they can use the apps that we create in their own personal way.

In this story we will talk about one of the visualisation options, the world map, that we provided to find and use content in one of our apps, which has content based on geolocation.

1. Lists aren't everything

Lists with a lot of filter options can become very overwhelming if you have lots of content. To battle this problem in one of our  geobased cycling apps, we introduced a world map that shows what content is available for our users.

2. Why a world map?

The world map gives a visual overview of available rides in the blink of an eye, without having to use complex UI or filter elements. Using a map gives the user direct knowledge of what content he can expect and where it is located. For example, zooming in on the Alpe d’Huez will provide a user with all the routes available in the Alps and (s)he will know that routes found there are challenging. The user can then click any of the available routes to get more details about the route (s)he finds interesting. Details like length or difficulty level of the ride will then pop up. This makes the world map an intuitive way of finding content.

3. But what about filtering?

We still added very simple filters to the world map, so users can quickly trim down on a specific need for their ride. For example, we left filters for difficulty and length (amongst others). By using a smart way of caching all the data on the server, this filter feels nearly instant. So filters are still important and used on the world map, but more in a way to quickly remove all the entries you don’t want to look at and still keep it simple, quick and visual!

4. Why did we decide on a website?

We needed a single solution that would work for Windows, Mac and the user’s browser, so we opted for a web application using an Angular front-end and Google Maps’ Javascript API. This way, we could easily represent all the available data in a more interesting and interactive way on a plethora of devices and platforms.

For the Mac and Windows apps, we ended up embedding the world map as a web view. It was also embedded in the client’s website. All the platforms that we were serving had slightly different requirements in regards to what was shown. With additional parameters, we could hide or change certain elements to make it fit the required styling of the app we were embedding it in.

The benefits of using a website is that we only had to implement the world map once for it to be re-usable across three different platforms, resulting in a coherent experience. Also, if we need to make a change to the worldmap, we just need to send the updated version to the worldmap server. We don’t need to send out an update to all individual users.

5. How did we deal with bandwidth and performance?

A web application needs to be as lightweight as possible and use the least amount of bandwidth possible. We quickly realised that the data we wanted to visualize was too big, resulting in poor performance on lower-end devices as well as high bandwidth consumption.

To prevent the high load on the user’s device, as well as the existing back-end, we realised we needed to create an additional back-end server in between the worldmap front-end and the existing back-end. This new “in-between” back-end would make the data “leaner” by cutting out all unnecessary data and only storing the essentials. This “slim” data would end up being sent to the worldmap’s front-end for visualization and interaction.

6. Caching data

The data on the existing back-end can change at any moment’s notice, but the slim data needs to be up-to-date. We chose a simple but robust service that updates the “in-between” back-end data and cuts it down on a time-based interval. This updating and processing of the data happens in the background, meaning that users of the worldmap receive an uninterrupted service.

This makes the “in-between” back-end functionally equivalent to a lightweight cache, storing data that is immediately ready for web consumption without any modifications or extra work, capable of serving many users quickly and simultaneously.

7. Result

The world map is a new and exciting way of picking routes. It can also be used for marketing purposes such as websites or mailings, due to it being a lot more visual than a boring list. After feedback from users we also found out that it’s a much prefered way for cyclists to decide on what route to do next, as it helps them on deciding their next cycling vacation! 😉

We will be happy to answer any questions you may have!