To paraphrase “the Brady Bunch,” the mobility scene is about apps, apps, apps. Statista.com states that as of July, 2015 there were 1.6 million apps on the Google Play Store and 340,000 in the Windows Phone store. A similar chart on ipod.about.com reports 1.5 million apps in the iTunes store as of June, 2015. For just about any purpose in life, there’s an app (or should be). A July, 2014 analysis by Nielsen found that “U.S. Android and iPhone users age 18 and over spend 65 percent more time each month using apps than they did just two years ago.” In over a year that figure has certainly only gone up.
I recently wrote about an app called Truecar, which helped me to negotiate a price on my wife’s van, but that is a niche app intended for a specific audience of car shoppers and sellers. I myself didn’t realize how dependent we’ve become on the ubiquity of everyday mobile apps until I went on a campout in Salem, MA last weekend. A fellow adult – a major coffee addict – asked me where the nearest Dunkin’ Donuts was and I replied, dumbfounded, “You mean you don’t have the Dunkin’ Donuts app?” Truly it seems every company and product has a corresponding mobile presence of some sort.
With that in mind, however, it’s not enough for businesses to just to pump out apps and expect to connect with customers or other businesses. Out of the millions of programs for Android and iTunes users, there are the great ones, the good ones, the mediocre ones, and the abysmal ones (think: malware and errors, or the just plain “no reason to exist” phenomena). The best ones provide the most useful and relevant functions with the least amount of manual intervention.
Then there’s also the pressure to get apps to market (whether free or paid) in a timely fashion to fulfill a need. Speed is of the essence. I recently wrote about the concept of Fast IT and so did Mary Shacklett of Tech Republic. In her article she lists cloud-based app development tools as the #1 way to implement fast IT without risking failure.
The issues of usefulness, relevance and speed are tied together through what is known as context. Context is becoming a big deal as the mobile app space expands, much like the universe after the Big Bang. This topic led me to take a look at a mobile app contextualization solution called Flybits.
Flybits is a cloud-based mobile app brewery. It uses “Moments” (which are essentially experiences) and “Zones” (which are essentially contextual inputs as defined by programming) to make mobile apps relevant. When a mobile user triggers or enters a zone (such as via a specific location), the unique app content and/or services apply based on that context (which can be something sensed or detected such as environment, social interactions, health triggers, etc.) to fulfill the moment.
For instance, if you go to Philadelphia Airport an app might alert you to the location of available power charging stations or which restaurants have the shortest wait time. More elaborate examples of this type of contextual content delivery are on the Flybits site (such as interactions at a stadium, in a store, while banking or at a campus).
The basis of context in a mobile app is what’s known as “push” delivery rather than “pull” requests. Instead of navigating a clunky app where a user has to enter their location, enter their desires, then wade through the results to match what they want, a contextual app knows the user’s location, preferences and other aspects of the user’s context and hands the information or service out automatically. It’s not a new concept (a study focusing on context-based mobile apps for museums was conducted 10 years ago) but it is gaining ground amidst the cacophony of our current mobile app universe.
I want to caution that the intended use of such apps should not be to harangue or solicit users with spam or interruptions, but enable them to more efficiently engage in the pursuit of products or services they want (in the museum example, obviously a mobile app would serve as a tour guide, detecting you were near King Tut’s sarcophagus and then telling you about his life, for instance). Overly aggressive advertising is not the intention with this scenario, but rather kindling better business relationships by providing easier access to what people want. Granted, the privacy advocates may find fault with the concept, but the simple truth is that the only way to achieve true privacy in the mobility realm is not to enter it in the first place.
Flybits intends to offer more than just context-based app enablement. Some other benefits include the ability to change app behavior without recoding, easy drag-and-drop of desired app content from a library, the ability to create app content via a software development kit (SDK), and profiting from lower app development costs as well as increased customer involvement. It uses the following programming elements:
- Moments Gallery – a set of pre-packaged modules that define mobile experience content
- Moment Builder – a mechanism to build unique moments
- The Experience Studio – used to administer app content and how it behaves
- Context Collection – pre-packaged plug-ins that give access to sources of user context, including location data
- Flybits SDK – a Software Development Kit – to add contextual awareness to apps
- Experience Broker – the air traffic controller that works in the background to deliver data as needed
- Flybits isn’t the only cloud-based app development provider; their competition includes Appery.io, Como and Condiqa. I chose to cover Flybits since I also had the opportunity to speak with the company heads.
Chatting with executives at Flybits
My goal when writing about mobility topics is to focus on what’s new and how these developments came to be. I some time talking with Flybits Founder Hossein Rhanama and CEO Jerry Rudisin to discuss the product, how it came about, and what drove the concept.
Scott Matteson: “How did the idea for Flybits come about?”
Hossein Rhanama: “My area of study in graduate school was focused on Context Aware and Ubiquitous computing. I was inspired by the work of Mark Weiser at the Xerox Palo Alto Research Lab and was impressed by the use cases that were discussed in the Ubiquitous Computing Literature. The challenge I identified was that there was not an easy way for mainstream developers to design and implement context aware applications, and many companies thought context was primarily location.
Companies who were working on Contextual Computing imposed proprietary and expensive hardware for very basic use cases. So the inspiration was: ‘how can such user cases be developed more easily and more effectively?’ In 2008, I received a scholarship from the government of Canada to join a European funded project called MUSIC that was focused on researching the future of Context Aware and Self-Adaptive Computing. A few students and I submitted the first Flybits business to the Harvard Business School, Business Plan Competition that made us the front runner in the competition in 2008. After spending two years in Europe to finish the project in 2010, I came back to Canada, finished my doctoral degree and spun off the underlying Flybits technology into a startup called Flybits. The goal of Flybits has always been to facilitate the emergence of contextual computing services across many devices and become a central hub on the Internet for services that require access to sensory and situational data.”
Matteson: “What is the target user base? Is there a specific level of knowledge required (or suggested) to work with Flybits?”
Jerry Rudisin: “We target any business that cares about mobile apps as part of its customer engagement/mobile marketing strategy. We see real interest in retail banking, retail, connected campuses, and transit so far, but Flybits is a very ‘horizontal’ solution – anyone who wants to deliver a more engaging and persuasive app will see real value in our product. Flybits works with the standard iOS and Android SDKs, so the typical app developer will find Flybits very easy to use. It usually takes about 15 minutes to ‘Flybits-enable’ an existing app. You can import or link to a Flybits library, flag the parts of the app you want to manage and manipulate with Flybits, re-compile, and you’re ready to rock and roll.
One very cool aspect of Flybits is that once the app is Flybits-enabled, it’s very easy for non-developers, such as marketing people, to use our Experience Studio visual interface to change the content and behavior of live apps on the fly. We make teams incredibly agile, cutting out the usual ‘marketing needs the app to do x, y, z instead of a, b, c’ to which the developers have to say ‘great, but it will take six weeks and cost $500k’. We have customers with marketing interns who are pushing new content and special offers using Experience Studio, with no coding whatsoever…. Flybits provides a gallery of Moments, pre-packaged software modules that encapsulate some kind of content or service that the app author wants to deliver to the app user. Things like playing a promotional video when the customer enters a certain venue, or calling an Uber car when it’s raining and you’re at a bank branch. Our customers are really into the detailed insights they can get about how their mobile app users use or don’t use each Moment presented in the app.”
Matteson: “How long did it take to bring the product to market? How many developers/staffers were involved?”
Rudisin: “Flybits first grew as an R&D group from the Ubiquitous Computing Lab at Ryerson University in Toronto. As a result, some of the founding members were working with Hossein and joined the group as research engineers. Flybits started with 3 engineering members in 2013 and immediately secured two of its first customers, Telus and Ontario Ministry of Transportation. Flybits always followed an agile model to bring its product to the market, and had paying customers from inception. They helped us flesh out initial versions of our solution, and showed us what customers need in terms of functionality and enterprise scalability. Incorporating all of these lessons, Flybits announced its first cloud-based, Context-as-a-Service product in September 2015, in addition to its first available public SDK.”
Matteson: What sort of coding/programming methodology was involved?
Rhanama: “Flybits SDK is available on Android and iOS. Flybits engineering methodology is based on autonomy in small teams and as a result it has adopted the Micro Services Architecture by leveraging containment tools such as Docker to enable different developers to build their own Flybits Moments and Context Plugins with their language of interest and ship it through the provided Docker containers. Flybits is in the process of using technologies like Kubernetes to orchestrate its new architecture. Flybits runs on the cloud and it is optimized on Amazon AWS and remains compatible with other cloud offerings such as Azure and Google Cloud Platfo
Matteson: “What interesting personal anecdotes/challenges/successes can you relate to us about the process?”
Rhanama: “Building disruptive technologies in enterprises are fun and challenging. Flybits has always impressed its audience with its technology and is learning how to make it more and more consumable in smaller components. Flybits has learned great lessons about the best practices of spinning off cutting-edge research from universities and partnering with the universities to quickly scale a venture-backed company globally in less than two years. Flybits has learned how to keep its technology ahead of the curve but at the same time align public deliverables based on market dynamics.
Flybits is demonstrating how innovation is now a global game and the classical model of capturing a local market first, and then expanding incrementally may be proven too slow for fast growing startups. While remaining capital efficient during the whole period of its growth, Flybits has leveraged Canada for its engineering ecosystems, the UK to quickly connect to the EMEA market, and has proven this by bringing two large European investors, Vodafone and BOSCH, to back its growth, and has setup its American base in Silicon Valley to connect to the main ecosystem of growth. Flybits ambitions are big and although it has always had opportunities to build me-too products and rely on procedural innovation, it has stuck to its big vision and follows the ‘Go Big or Go Home’ mentality.”
Matteson: “I enjoyed the examples of how Flybits can be used. Can you provide any other real-world situations of day-to-day use?”
Rhanama: “Many of the examples you have seen are real and used by users in the market. In Ottawa, people use it to receive contextual video feeds based on their travel itinerary. At Vodafone campuses in the UK, staff members and visitors receive information that is relevant to them when they visit the campus. From finding a colleague to notifying someone if they have their visitor has arrived. TD bank uses it to upgrade your flights for even send you a pre-approved mortgage offer when you are visiting an open house. The great thing about Flybits is that it is vertically agnostic and the users’ imagination can quickly be implemented using the provided tools.”
Matteson: “What sort of pricing model is involved for users/companies which offer it to users (e.g. in the stadium example it sounds like the stadium could offer this to the vendors operating there to create interfaces for customers?)”
Rudisin: “You’re quite right about the stadium example. The stadium owner or more likely the sports team would be our customers, using Flybits to deliver a more compelling, fresh and fun fan engagement app. The team has lots of opportunities for partner revenue – maybe promotions with local bars or merchants, as some of our customers have done, based on the context relevant to segments that the team defines among its fan base.
More generally, pricing is simple: Flybits is a SaaS (software-as-a-service) solution, so we currently charge an annual fee, pre-paid, based on the number of apps and the number of expected users of each app. That way the annual cost is fixed and predictable, and Flybits is on the hook to show value and earn the customer’s renewal each year. We may move over time to Twilio or Stripe-style pay-as-you-eat pricing as we gain more customers and learn more about which parts of our SDK are used most intensely.”
Matteson: “Where is Flybits headed and what’s over the horizon?”
Rudisin: “We’ve had demanding enterprise customers use our software for almost two years. With our release of our cloud-base context-as-a-service solution, we’ll make it easier to reach a lot more customers much faster. We’ve also published and fully exposed our SDK and associated APIs, with lots of information on what context-aware apps are all about and step-by-step instructions on how to use Flybits to context-enable an app. We’re starting to sign up developers, selectively right now, as we work out the inevitable kinks and bugs, and will soon move to make our SDK freely available for trial use.
Beyond that, customers can already create new Moments; these are the small software modules that package access to some content or service that the author wants to deliver through the app. We provide a bunch of these, and customers can create their own. We’ve always envisioned – and will soon enable – Flybits users to create Moments and share them with other Flybits users. Imagine the equivalent of an app store for context. That’s one goal we have for our solution. We want to become the ‘go to’ place for all kinds of contextual mobile experiences, and we have the solution that makes this possible.”
Flybits offers a Developer Portal which is going live shortly and will be available for trials if you’re interested in registering to participate.
As context advances and competition among mobile apps continues to grow, the ability to tailor specific functions to specific users and environments will be a key theme of ever-increasing importance.
‘Citizen developers’ are ready to fill the gaps in enterprise applications
10 app tests that belong in your QA playbook
Design even more brilliant apps thanks to enterprise social media