Cathay Pacific 24-Hour Hackaton: Understanding cxDiscovery

This is the second entry of a two-part blogpost about an application my team and I developed for Cathay Pacific’s Hackathon. You may want to read the first post here, to get more context. In this blogpost I will discuss the technical aspects of our demo application, I will start by briefing you about the stack, then, for the longer part, I will examine some of the unique challenges we had to consider.

logo-cathayTHE STACK

As you may have concluded from part one, cxDiscovery aims to virtualize the in-flight magazine, Discovery, on-board the Cathay Pacific fleet. Intuitively, it could be expected to see the application as part of the on-board entertainment system. Unfortunately, during the hackathon, that was difficult to reproduce; therefore, our application was built as a web app.

In the front-end, we built a React-Redux application on top of create-react-app, a great boilerplate for front-end development with React and Redux without the need for any configuration. To keep the demo simple, our React application handled most of the heavy lifting of filtering the articles by the selected categories and tracking saved ones. Our front-end components were built with Material-UI, a dedicated library of React components built on top of Google’s Material Design. The front-end was coupled with a RESTful API server built with Node.js, Express and a MongoDB database.

If you are interested in knowing more details about the build, you can view repository on github. Now I will discuss the challenges that our concept was facing, and our solutions to the most critical ones.


Since our application would replace the in-flight magazine, we identified our audience to be in-flight passengers. With that in mind, we understood that cxDiscovery should be accessible within flight by all passengers, regardless of their devices, while remaining as intuitive and accessible as the paper counterpart. At the same time, we recognized that this meant close integration with the airlines’ infrastructure which proposes many constraints. To reiterate, the application must comply with the following expectations:

  • Accessible by all passengers
  • Live and dynamic to cater for preference
  • Able to make sense of user behavior.

Based on this we agreed that the main features of our application must align with this, most importantly:

  • A multi-platform and constantly available content delivery.
  • Personalization through historical user data.
  • Understanding and analyzing user preferences by tracking user interactions.

To add, we considered essentially three different mediums of delivery for the application, as a native mobile app,  a web app, and within the on-board entertainment system. The latter being the ideal outcome, we set out to find the second best option and that is what we analyzed below.


Since we know our application needs to be accessible by all  passengers, we should guarantee user access to the full content and features we can provide. This lead us to the first question, where is best approach to host the main data of the application. Well, we had two possible options, pre-flight and in-flight. Meaning, either the user pre-loads the data on ground, or they have access to it on-flight.

The first option suggests the use of a native mobile application, one that can easily sync a database  on the cloud, and store articles locally. While convenient, this option must exist on all the different environments -if available, and yet does not guarantee user preparation; not even downloading! If we then consider a web app, we realize pre-flight syncing might be as complex, on the other hand, in-flight data retrieval is as simple as owning a browser friendly device; especially on the new Wi-Fi enabled planes.

This raised the clear question, what about the other flights. The solution is to host the content on the planes’ computers, the space, at least, is definitely there. Then we remember that the planes’ computers are updated once a month; which means we are not providing the dynamic platform we want. This would also be the case for an application running on the entertainment system. Therefore, on-board Internet services would be a great addition, and most airlines are already actively seeking it. For the sake of the demo, we assumed this will become true.


For our concept to work it is crucial for the application to be able to identify the user currently in session and track their actions. In addition to that, it would be extremely beneficial to know demographic data such as age, gender, location, of the users -that they agreed on sharing- as it  gives a better insight on individual and collective preferences. Of course we took the issue of privacy and security very seriously; the application would not preserve any sensitive data and instead just link user actions to corresponding user records in the databases of Asia Miles and Cathay Pacific, who host all the sensitive  information.

Users would therefore login with their Asia Miles account and the application then verify them with the Frequent Flyer database. Otherwise, a unique QR Code could be printed on the boarding pass and used to authenticate the users. A native mobile application seems more fitting than a web app since credentials can be stored and authenticated automatically. Nevertheless, we regarded QR Code as a viable solution for both. But not that it mattered for our demo where we had a mock user database and skipped authentication.

Furthermore, the application maintains a database to store the users’ preferred categorizes and favorited articles to provide personalized content. But, it also has an offline mode in which users are not verified and use the default view. Here, we prioritized simplicity to assure a seamless adoption of the application while satisfying its other conditions.


As explained previously, the application is designed to monitor user interactions in several ways. It stores the users’ preferred categories and tracks whether a user opened an article, read it until the bottom and whether or not they saved it. These interactions need to be constantly synced with the database to present an accurate depiction of the trends and provide more refined results to the users according to their interests.

Once more, we are obstructed by the unavailability of internet access on-board numerous flights in Cathay Pacific’s fleet. With the web app and the entertainment system versions of the application, this is a challenge; there was no guarantee that the on-board computers would be updated frequently enough. Of course, all this could be mitigated with a native mobile application. One idea was to use of an offline enabled database like PouchDB to enable a seamless experience in the plane and syncing whenever an internet connection is established; thus, providing the data integrity we need.


I just want to point out that a mobile application is a much simpler, and probably cheaper, to develop and maintain than the two alternatives. It would also be smaller in size, and more manageable on a plane’s computer, not to ease of updating it.


As you could see, building an application for an airline, especially when used in-flight,  puts many constraints on the development due to numerous complications. For example, integration with the currently existing infrastructure of the airline or connecting to the internet are currently either impossible or expensive for Cathay Pacific. For this reason, we were only able to display our take on the second best option during the Hackathon, and are hoping that if a concrete implementation of such an application is to be made, Cathay Pacific’s technology team might help in resolving them.



Leave a Reply

Your email address will not be published. Required fields are marked *