Blog


ContextHub: an emerging platform for Context

Over the past four years, I have been fascinated at the speed at which the world has adopted mobile technologies: The advent of the App Store distribution model for software and media opened up new sources of revenue and dramatically accelerated what was already a fast adoption rate of smartphones: estimates peg today the global number of mobile users at 4.5 Billion, roughly two-thirds of the world population.

The advent of mobile, coupled with the rapid evolution of cloud-based offerings and proliferation of API’s everywhere, has drastically changed the technology landscape – the world today looks very different than it did just five years ago.

In parallel, users have substantially raised the bar on what they expect from their applications, as they experiment first-hand the superb customer experience created by the Darwinian competition of over two million apps in the app store – all vying for their attention – coupled with the leading-edge design capabilities of companies like Apple, Google and Amazon.

It is not surprising then, that this unprecedented mass adoption of technology has left most of the enterprise software companies and IT departments struggling: trying to reconcile a world that demands beautifully designed, scalable, consumer-grade applications that leverage all the capabilities of smartphones and other smart devices around the user, with a reality of diminishing IT budgets, inadequate skills, outmoded business processes and a very complex, difficult to support, ever changing environment.

Five years ago, if you led an internal IT team at a large corporation, you could count on a relatively stable hardware environment: probably a single client OS (Windows 7 perhaps?), a fixed set of hardware configurations from a few approved vendors, a secure internal network, and a controlled datacenter environment where your enterprise applications lived.

Today, development teams are increasingly expected to develop applications that work outside the firewall, leverage new capabilities (such as geolocation, beacons, sensors, and more), support a variety of smartphones (iOS, Android and web at least) and interact with smart devices – owned by the company or not – all while maintaining security and scalability… at a fraction of the cost and time than before.

Over the next three or four years, things are bound to get worse – not better. The advent of the Internet of Things (also called the “Industrial Internet” or “Smart Devices” to incorporate concepts such as wearables) is going to put additional pressure on development teams everywhere to integrate them.

Users everywhere will continue to raise the bar on applications, as they will increasingly expect them to be sensitive to the context they are in – both physically (“why doesn’t this app know that I’m in the car?”) and logically (“why is this app showing me with data that is irrelevant to the task I’m doing?”).

I use a new term to describe this new type of applications: ‘Contextually Aware Distributed Mobile Applications’, or CADMA. These are applications that run on large numbers of mobile phones, with centralized cloud services, leveraging internal or environmental sensors and smart devices. They are flexible and smart, with the ability to offer the user the “right information with the right functionality through the right user interface at the right time and the right place”.

The problem is that creating these CADMAs is hard. The best way to understand the difficulties intrinsic to them is to review a few use cases. Here are two examples:

  1. An application for a movie theater that runs on a customer’s phone, accesses a central reservation system, is aware of the customer’s location & time of day, of its proximity to different places within the venue, and of nearby friends who are also at the venue. The “contextually aware” version of this application would:
    1. Let customers review information to purchase tickets and select seats from the app when they are at home.
    2. Display the movie theater location and automatically show driving directions if the customer is outside the theater, as long as they are moving in a car.
    3. Show real-time location to friends that are driving to the same venue at the same time to make it easier to meet up – and allow them to easily communicate any change of plans amongst themselves.
    4. Validate the ticket as they walk in the venue and past the ticket booth – no need to print or scan anything.
    5. Highlight prices and offers, or pop-up coupons, when near the food court – and an offer an option so they can bypass cashier lines.
    6. Display a large, friendly arrow pointing them in the direction of their movie when inside the theater – with a 5 minute ‘nudge’ alert.
    7. Prompt the user to mute their phone as the movie is about to start, but only if they are inside the theater.
    8. Display a directional finder to help them find their car on the parking lot – the location of the car was automatically captured by the app as they parked.
  1. An application for equipment service technicians which incorporates a central dispatch system, takes input from sensors on devices deployed in the field, communicates with an app on the service rep’s phone, and has both technical manuals as well as historic data related to the equipment installed. The “contextually aware” version of this application would:
    1. Have sensors that monitor the devices continuously and alert of any anomalies – eliminating or drastically reducing the need for “daily” or “weekly” rounds just to see if they are working, as well as the number of “emergency dispatches” that occur after the equipment has failed.
    2. In case of a problem (or a potential problem), the device sends a signal over a 3G connection reporting its status.
    3. The central dispatch system queues up the request to the service technicians in the area and automatically alerts the customer of the need to service the device.
    4. The technician app shows her the next equipment to be checked – including driving directions to the site where it is located. The queue of work is reassembled dynamically by the smartphone in real time based on proximity to request sites and availability of technicians.
    5. Customers are able to see the ETA of their assigned technician updated in real-time, including time associated with driving to the location in current traffic conditions.
    6. As the technician drives towards the site, the related customer is notified via push messages and provided the opportunity to confirm/reject the visit (i.e. “nobody who can open the gate is there right now”) or simply to communicate with the rep (“please ask for Stacy when you arrive”).
    7. When the technician approaches the equipment, the app displays the relevant manual & technical data, access information, as well as the historic maintenance log of what has been done to it. This information is locked with “contextual security” – which means it can only be used while the technician is in close proximity to the device and during the right timeframe.
    8. As the technician is working, the app automatically continues to update the request queue and starts diverting work if it is taking longer than anticipated.
    9. When the technician completes the request, all work done is added to the device log – including pictures taken with her phone.

Pretend for a moment you are the developer responsible for developing these applications. It is clear you will need to implement the user interface both in the web and mobile devices, as well as the business logic behind it – but a part that can end up consuming a large portion of the development budget, not to mention a significant number of all-nighters, is the plumbing associated with creating the infrastructure behind it.

In the applications we have developed, we have seen that most contextually aware applications need to:

  1. Interact with sensors in the environment. For example, to detect iBeacons in the food court at the theater, or monitor “black box” sensors in the field.
  2. Access internal sensors in the smartphone and process the associated data – Bluetooth, geolocation, motion, etc. For example, to leverage the location of service technicians, whether the movie theater customer is driving or not, etc.
  3. Represent and manage contextual objects (locations, beacons, states, etc.). For example, to notify all apps when a new beacon or the location of a new theater is added.
  4. Span multiple devices. For example, a single user might have a tablet, a phone and a wearable device, or, the app in the technician’s phone needs to interact with the app in the customer’s phone.
  5. Communicate: app-to-app, app-to-server or with the users. For example, when the app notifies the service rep that there is a new work order waiting, or the customer to let her know that the service rep is on their way.
  6. Store and synchronize data. For example, to store settings, parameters or contents in a central server so they can be adjusted in real-time, and to ensure devices are notified and updated when interesting data changes.
  7. Have logging and audit services. For example, to validate that a service rep indeed visited a certain location, or that a customer used his movie tickets.
  8. Generate analytics. For example, to know how many users attended a certain movie screening, or to see the week-to-week growth of service events being handled by the service team.

Implementing these tasks can be very time consuming – not only because of the complexity involved, but because some areas (such as beacons, data synchronization or background network communications) are tricky and require a lot of testing to ensure they work properly. They also require skills that are often not present in the development team – like setting up a public, secure, scalable server infrastructure, or dealing with advanced iOS capabilities.

At the same time, this functionality is generic – and not where an application developer should be spending time on, because it is not what will ultimately provide differentiation or business value to their company.

To address these requirements, and leveraging our experience building enterprise-grade mobile applications, our team has developed a platform for CADMA that is robust, simple to integrate and easy to use.

The platform consists of a SDK that is integrated into the mobile applications, a REST API that can be used by devices, sensors and other web services, and a developer portal where server-based logic, data and parameters are accessed.

This hybrid model, when compared with traditional “mobile only” applications, provides much more flexibility and dynamism – because it allows contents and functionality to change instantly with just a few clicks.

Our goal is to enable application developers to quickly create robust, powerful contextual applications, without needing to spend weeks or months implementing these generic functional areas. In some cases, it can even compensate for existing skill gaps in the team: an iOS developer, for example, can develop and deploy a contextual application by simply interacting with the native SDK and managing it through the developer portal – without needing to stand up his own server or learning any additional skills.

For companies and business managers, our goal is to allow them to spend the majority of their development budget on true innovation and areas that drive differentiation and user value – not on redoing the “contextual plumbing” of their applications. At the same time, our platform allows them to reduce risk and deliver applications faster, because they are able to leverage a platform that is tested, robust, and operational today.

Cool things you can do

There are many possibilities with our platform; here is a tiny sample of things I think are interesting and come “out of the box”:

  • Get Push services working in your iOS app in less than 5 minutes and without the need for any additional servers.
  • After your application is live in production, decide that you want to start tracking contextual data to understand your customer’s habits.
  • Store parameters for your app in a server, and have the platform tell you whenever they change so you can update your app’s behavior.
  • Have a business user go into the platform portal and perform content changes as needed – which will reflect instantly across all devices.
  • Log any type of events from all devices – and be able to dissect and graph the data centrally.
  • Integrate new types (or versions) of sensors and/or smart devices without needing to change a single line of code in your application.

It is my hope that developers everywhere find the platform useful, and use it to create engaging applications that make our lives better. Try it for free at www.contexthub.com and send me your comments!

 

Comments ( 1 )

  • Jimmy Morson says:

    Roberto, Thanks for choosing this topic to write on. This post is of considerable use for me and my friends. Great experience has been shared with us. Thanks for this post.

The comments are now closed.