{{selectedItem.title}}

GIA 4C's Mobile Content Management System

Problem: The inherited code base of the GIA 4C's App Suite was developed in a way that created a huge bottleneck during deployment. All the content was either hand coded or lived in a local The Suite Consisted of two Applications Consumer & Retailer with two localizations English and Chinese on Two Mobile Platforms iOS and Android and to make it more interesting the Android flavor of the Application was deployed on both Google play and Amazon. This meant that any content update would require 16 different App deployments. Device testing for layout discrepancies over a range of devices, operating systems, os versions and screen sizes a very frustrating time consuming and monotonous task. Now Factor in my team dealing with a client facing agency, dealing with the bureaucracy and departmental compartmentalization of a large corporation like GIA and you can imagine the frustration, waste, and inefficiency making a small update to the Application would be.

Requirements: First, we needed to be able to update the application without redeploying. The CMS needed to be user-friendly and accessible to someone with no technical experience, a copywriter, or a social media consultant. All the image text and video content had to be updatable and work offline in the application. Last but not least, Making an update to the application needed to go through a staging and review and approval process before being pushed live to the userbase.

Solution: The solution required an application update as well as the development of the CMS. We proposed A user-friendly CMS UI powered by an NOSQL database; the apps localization was done using local JSON objects so using an NOSQL database streamlined the process of storage and retrieval cutting out the translation from another database and code base to JSON. Another major obstacle was devising a way that GIA could internally review and approve the updates before they were pushed to the user base. We proposed creating a white list of internal Device ID's. Devices on this white list had an additional screen that could be used to toggle between staging and live data. On Launch and at periodic intervals the app would call home to the CMS checking a time stamp to see if approved updates were ready. If Approved updates were found, the Device would prompt the user to enter an update screen where new content could be downloaded to the device. This process allowed the app to work offline with the new content.