Going under the hood of July MX Modules

12th Jun 2013

MX’s core feature is that a non-technical user can understand its capabilities, build, and launch a mobile experience in a matter of hours.

The output may sound simple, but in order to achieve this, we have to approach the development slightly differently. Modules have to be simple for the tool user, but still deliver a specific value, pre-tested on a variety of devices for single use as well as for use in combination with other modules.To enable this, we have to avoid a number of steps in the standard development process.

So, here’s what we do:

1. Hide the Complexity from the User

The configuration of a module often involves complex parameters which a non-technical user need not be aware of.

For example, our Instagram module.

Instagram Module Architecture

instagram-graph

A non-technical user identifies an Instagram user through their user name. However, the module identifies a user’s photos based on their configured user ID – a numeric value. To make things simple for the user, the module manages the complexity of associating the given user name with the correct user ID internally. The module then asks the user to configure their user name in the edit panel, and operates based on that.The module also takes care of other complexities regarding API calls. It uses backend services to throttle APIs and cache the responses, and its architecture ensures that the end user request does not result in unnecessary API calls to Instagram over the course of each hour.The user benefits by being completely shielded from this activity and is free to use the module in any number of pages.

2. Ensure Good Performance and Easy Scalability
Once the modules are out in the cloud, they can be used by users in many different ways – in pages which attract very high traffic, in conjunction with other modules or even multiple times on a single page. We have employed a smart-caching mechanism at different layers of the module and the platform to ensure faster response times. The modules are also coded for optimal payload sizes, so that pages do not become heavy and always load faster on slower networks, providing users with better performance and scalability.The different kinds of devices (varying sizes and resolutions, touch versus non-touch, and supporting JavaScript versus not supporting), create a number of challenges in making modules work seamlessly. The MX platform provides mechanisms through which requests from these different kinds of devices can be identified separately and handled accordingly. This helps the module developer solve these complexities easily, and leaves the end user with an easy and smooth experience.