Flow: enabling non-technical people to create and maintain applications

By incorporating a set of reusable constructs—or behaviours—that enable advanced functionality, Flow makes platform-agnostic application modelling, creation, distribution and maintenance easy.

Nowadays, there are many tools that enable users without technical knowledge to create content on the internet. From social media platforms, such as Facebook and Instagram, to highly customizable content management systems like WordPress, Weebly and Drupal, to more specialized options—such as LINE Webtoon, for webcomics—a range of systems and platforms exist that make the creation and publication of online content simple.

When it comes to creating applications, though, technical knowledge is usually required. One exception is for very basic apps that enable end users to browse ‘static content’ (e.g. the menu of a restaurant, or tourist information for a location). These can be customized quite simply, since the necessary tools don’t demand advanced technical knowledge. Typically, however, applications are more complicated than this.

As an example, take a reservation system for flight tickets. Such a system would involve a series of tasks: asking the end user for the dates and destination; checking prices and availability; booking the flights; accepting payment; sending notifications and so on. All of these tasks and their interconnections (the logical flow of the app, involving end-user interaction as well as automated tasks) together represent what we call the ‘behaviour’.

For applications that involve user-specified behaviour—such as the ability to make an appointment at a small store, play a trivia game related to a tourist attraction or compose an itinerary to tour a city—the user must have, or acquire, significant technical skills. Furthermore, if we consider deploying such applications for a range of target platforms (including screen-based devices, such as smartphones or tablets, and voice-based ones, like Amazon Echo), the task becomes completely unrealistic for non-technical users. For a visual reference of the skill levels required for each of these kinds of applications, see Figure 1.

With all this in mind, the first objective of our work—Flow (1)—is to empower non-technical users to create apps that contain application logic as easily as they’re currently able to create static content. Our second objective is to simplify the long-term maintenance of the same application for several platforms, which currently poses a major problem for organizations. Typically, different teams of specialized developers are required for each individual platform (as indicated in Figure 2), which multiplies the codebase that must be maintained. As an example, take your favourite music streaming service, online store or social media platform. Each of these can be accessed through a variety of specialized apps which are available on a range of devices, including smartphones, voice assistants, smart TVs and smartwatches. However, these apps—which all run on completely different, platform-specific code—execute the same core logic across all supported devices. Is there a way to employ the logic that’s specific to a given app across all platforms simultaneously, without the need for platform-specific code?

Organizations sometimes use hybrid approaches (e.g. Ionic, React Native and Apache Cordova) with the objective of targeting multiple mobile platforms with the same code. These approaches reduce the number of different codebases that are required by, for example, generating complex platform-specific code from more simple front-end logic. However, hybrid approaches are generally limited in terms of platforms and still require skilled developers to take care of the code. Additionally, long after the initial development of an app, updates must be coded and deployed for each specific platform by the respective development team, sometimes with explicit effort required from the end user (i.e. approving and controlling certain updates).

Looking under the hood: the modelling infrastructure and cloud execution engine behind Flow

To bring about the simplicity that’s required to enable non-technical users to create and maintain apps for a variety of platforms, our system relies on two main elements under the hood: the modelling infrastructure, which simplifies app design; and the cloud execution engine (CEE), which takes graphical flows and interprets them.

The modelling infrastructure of Flow enables the use of domain-specific constructs to build reusable behaviour. Not all modelling activities are intended for the non-technical end user, however, as some activities—mainly the creation of the set of reusable constructs that represent the ‘bricks’ that can later be used by non-technical people to create application behaviours—must be performed by specialists. While the remainder of this article focuses on app creation, the creation of these behaviours is briefly illustrated at the beginning of Video 1 on ‘Flow Design’.

The CEE is in essence a native execution environment that takes graphical flows and, from the cloud, ensures that the application specification is delivered to the target platform. The platform then interprets the information in a way that makes sense based on its specific capabilities. The CEE understands the flows directly—with no specific translation required—by reading, analysing and then executing each step, either by interacting with the user (for steps requiring data display or collection) or by executing an external service or internal functionality (such as data retrieval) automatically. The CEE differs from existing engines (like BPMN—business process model and notation—engines, such as Bonita BPM, Camunda BPM and jBPM) in that it is not generic, executes flows natively, can interact with many devices, and provides certain monitoring and control features that other engines don’t. Further, it can be used to form the backbone of stand-alone apps.

Simplifying the creation and maintenance of applications for organizations and non-technical users with reusable behaviours

In terms of app creation, the main component of the modelling infrastructure is the application behaviour model (ABM), illustrated in Figure 3. The ABM doesn’t contain graphical information or information about the target platform, and it doesn’t implement the behaviour that will be executed within the app. Instead, the ABM describes an application in abstract form, independent of the platform on which it will be executed, as a collection of references to predefined behaviours. The actual behaviours of the app—the flows—are executed solely on the server, and devices only render or collect the data needed in the flows. The CEE then sends the ABM to devices when they connect and provides the appropriate communication to ensure that the right task is received at the right time, without requiring that the device be aware of the flow.

Non-technical users can easily create an ABM—see Video 2: ‘Application creation’—and/or search for the predefined behaviour that they want to include in their app by using a graphical editor, as shown in Figure 3. Please note that the ABM Modeler shown in Figure 3 is just a possible, non-WYSIWYG (what-you-see-is-what-you-get) ABM editor. This means that the final application may have a different look and feel. In fact, this is quite likely, as the ABM is platform independent—the same app will look quite dissimilar on an iPhone compared to a smartwatch, and will be very different indeed when it’s running on a voice-based assistant with no screen.

While the creation of these reusable behaviours is not within the scope of this article, one way to understand them is by drawing a parallel between apps and WordPress blogs. The community provides countless WordPress plug-ins that can be easily integrated into a blog by a user without specialist knowledge. These plug-ins make it simple to add sophisticated functionality to a website without requiring that the creator understand the underlying code. Our reusable functions work in a similar way to these plug-ins. They’re easily available and can be simply added to create the final app, just as a unique blog experience can be created by picking and choosing specific plug-ins.

From app generation to execution

Only two inputs are required from the user creating an app: first, the contents of the ABM; and second, the platforms that the app needs to be generated for. Once the ABM is created for an application, it’s then deployed alongside other standard actions (e.g. creating space on the device drive or initializing the app-specific database). Additionally, a token is generated at this stage that identifies the application (and therefore the ABM) in the CEE.

In the next stage of the app-generation process, appropriate templates are selected for the target platforms. These templates do not contain specific code for the application logic of the app being generated, but do contain:

• Code that supports communication with the CEE.
• Code for interpreting and rendering the ABM.
• Code for enabling interaction with the end user.

In other words, a platform template will differ between platforms—and will contain code that takes advantage of the platform capabilities—but will be exactly the same for all applications. It’s through the interpretation of each ABM that an application will perform its functionalities. A template for mobile phones, for example, will contain logic to display buttons and screens, and will leverage phone sensors and capabilities, while driving user interaction with a native look and feel. For a voice assistant, the template will generate voice output and receive user input in a way that ensures the application logic is respected and the various data elements are presented to the user—or obtained from the user—at the right moments in time. Additionally, the template for each target platform is enriched with the token that was generated earlier to identify the application in the CEE. This enables a connection to be made between the code that will run on each individual platform and the ABM that resides on the CEE.

The next step is to deploy the generated code on the end device (e.g. a smartphone). This step will depend on the final platform (e.g. Android). Most platforms have application distribution mechanisms (in the case of smartphones, for instance, there are specialized application stores that facilitate their distribution).

Finally, the code is executed on the target device by the end user. Each time the application is started, it will connect to the CEE—by sending the token that identifies it—and the CEE will return the ABM. The application then executes the template code, running the logic to interpret the ABM (as well as to interact with the end user) in the most appropriate way according to the platform. All of these stages are laid out illustratively in Figure 4, and examples of execution are shown in Video 3 below.

Video demonstrations showing Flow in use

Video 4 shows how Flow enables a person without any particular technical skills to create a small game that consists of guessing a number.
In this case, the specification of an ABM enables the generation of two applications—one for iOS and the other for Amazon Echo. Finally, Video 5  shows how these applications can be updated automatically, for all users and all devices, merely by updating the ABM and propagating this change.

Summarizing Flow, and next steps

Our approach enables non-technical users to create (and update) apps for any target platform simply and easily. Flow could also be used by organizations that maintain the same application for several platforms, reducing the time and specialized knowledge that’s required to push the updates for each of them.

In summary, our approach brings about the following advantages:

• Flow enables professional-looking native apps to be created quickly and easily from existing libraries of reusable behaviour.
• Many instances of the same application can be run on several platforms, with each looking very different (depending on the platform) but essentially running the same code.
• Interaction with the user is optimized for each platform, as this element is designed by experts who create the platform-specific templates to achieve the best performance and end-user experience. This includes using features and sensors specific to the final platform (e.g. a GPS sensor could be used when the location of the user is required, if available and enabled for use).
• Updates to the application description (or the actual function) are automatically reflected in all applications for every platform. This is because each time a device starts, the ABM is sent to it from the cloud (the CEE).

A major disadvantage of our approach is that it requires an uninterrupted internet connection. However, due to continuous progress in terms of both coverage and connection speeds (2), we believe that this is becoming less and less of an issue over time.

We’re currently considering developing Flow along a number of lines. First, we intend to expand the built-in capabilities of the modelling and execution methods to bring about better support for applications that use artificial intelligence. Second, we hope to introduce support for different domains, such as robotics. Finally, we would like to explore mechanisms that would enable the apps generated using Flow to have offline working modes.