In general, for non-software developers aka business users, an Application is one single object that they download and install onto their device whether a phone or laptop. It may also be a solution that they can access from their web browser. It may contain a series of screens that they navigate between as they use it. The Application most likely includes many components working in unisons some in the background and some generating the visual interface that they see.
The Application may have many screens and visual design elements. For example, you might have a dashboard that shows aggregated data, a grid that list documents, or a form that users will use to fill out data.
Many solutions layout out the different screens using a tree structure that shows the relationships between screens. Usually, you build the connections between the pages by selecting actions within a screen. For example, in Microsoft Power App. the tree structure looks like:
However, we wanted a more visual and intuitive way for any user to build their solution allowing them to connect the different parts of the solution as easy as analogous to building with Lego blocks.
We came up with the concept of AppBlocks which represented common components of an application like a form, grid and page. Each is a design element with pre-defined properties and behavior on how they interact with other AppBlocks within an application.
Originally AppBlocks utilized a simple block-based interface with pre-assembled components based on given templates that users might commonly use. This was somewhat restrictive, but worked well. This worked fine until the user wanted to make additional changes or enhancements to the design.
iPhora AppBlock version 1 |
Therefore, we looked for a more flexible approach where users could utilize a number of predefined design templates, but also allowed them to visually customize the design of the application without the need for developers to create code. They could even start from scratch with no pre-defined template.
Since we were already using the mxGraph library to allow users to visually design and create their own processes, we wanted to see if was possible to use it for creating the user interface. A user interface and how a user navigate throughout an application is essentially a flow. In fact, developers have used Node Red to create dashboards, but only as a single design element.
But the trick would be again be how to treat each component as a black box with interaction with between AppBlocks governed by a common bus that facilitated communication. In this case, the communication was not only data but user interaction.
Unlike the process node elements, AppBlocks, were much more complex in nature. AppBlocks themselves contained a variety of design elements within themselves and we needed to keep track of the different design elements within an AppBlock. Again, the flexibility of using JSON to represent objects and design came to light.
iPhora AppBlock version 4 |
It took almost 6 months, but we were able to get it working. As shown above a user can easily visualize the design of the application that they have created making it easier for them to create and edit applications. Does this approach work for all applications and the answer is no. However, it provides 90% of the need.
Now that we have the tools to visually create applications and processes for which business users can use to automate their processes, we needed a way for iPhora to go beyond basic workflow. Something that business users could easily utilize to scale and handle complex workflows and processes. Next time, iPhora ActionStreams.
The iPhora Journey - Part 8 - Flow-based Programming
The iPhora Journey - Part 7 - Transforming Domino with Microservices
The iPhora Journey - Part 6 - An Application, Rethinking and Redefining
The iPhora Journey - Part 5 - Dammit Jim, I'm a LotusScripter not a JavaScripter
The iPhora Journey - Part 4 - JSON is King - The How
The iPhora Journey - Part 4 - JSON is King - The Why
The iPhora Journey - Part 3 - Creating an Integrated UI Framework
The iPhora Journey - Part 2 - Domino, the Little Engine that Could
The iPhora Journey - Part 1 - Reimagining Domino
Comments