App Builder

The problem

Clients of EDR GmbH were using printed out forms to carry out tasks and follow procedures such as quality inspections and fault analyses on construction sites. These printed out forms were often cumbersome, error-prone, and inefficient.

After users had manually filled out the printed out documents, for example, someone would need to enter the data into software such as Excel.

Existing digital solutions were either too hard to use or didn't include critical features such as the ability to hide certain form fields depending on the user's input.

The people filling out the forms often worked in places where there was spotty or no connection to the internet. In one case, overseas builders needed to fill out forms where they had no access to the internet for days at a time.

Many use cases required forms to be updated regularly to accommodate changes in policy and business logic. Business logic that also required changing variables that would need to be reflected in the applications.

My role

After initial talks with EDR, detailing my work on previous complex solutions, such as the integration of rules engines (side note: take a look at my TypeScript port of JSON Rules Engine), as well as the building of highly interactive UIs in Angular, EDR decided I was the right person to tackle the problem.

The Angular frontend and the NestJS backend would be my virtual residence for the next year and a half. Styling with SCSS was also my responsibility.

Working mostly alone on the solution allowed me to quickly develop what EDR was looking for. Because of this ultra-agile, few-meetings, fast-feedback environment, I also had time to build multiple NestJS microservices used by other applications developed by EDR.

Our solution

As is usually the case with businesses, I can't go in to too much detail about the how and what regarding the technical implementation. Regardless, I'll do my best to convey the solution.

The name of the product gives it away really — the solution allows the user to produce separate apps. I built a drag and drop editor, where the user can drag certain app elements in to their app and then configure them. Elements include:

• Text and number inputs
• A signature input
• A photo input
• A repetition group which allowed the repetition of other elements
• A map display

and many more.

They can title sections, make fields required, add validation and even control when certain fields will be shown and hidden.

These apps can be published, versioned and subsequently sent to people who would enter data in to the created apps. This allows EDR to address the continuously changing business needs of EDR's customers. A procedure needs to change instantly? No problem. Make changes to the app in the app editor and publish again. If you've sent someone a “latest version” link, they will always get the latest version of the app when opening the app.

But what if the end users are offline? We briefly considered implementing the IPoAC protocol to solve this predicament, but decided against it for technical reasons. Initially, they would need some way of downloading the app. But after they've done so, they can open the app offline and submit their data. Even their photos. Once they've got a connection again, their data and photos are uploaded in the background. Because of the way I built this feature, uploads handle even spotty internet connections where part of the file might be uploaded before the connection drops out. Essentially, handling failed upload attempts.

We decided to store the data inputted by users inside the apps centrally, allowing app creators to view every submission in a simple, easily filterable table. For companies that needed the end user's input to go elsewhere, however, this wasn't enough.

End customers need the submissions to integrate with their current systems. Excel being seemingly the backbone of many small and medium enterprises, I built an Excel exporter. In fact, I built a couple of exporters for different formats but because every company “spoke” Excel, that was the first I programmed.

Remember the repetition group element I mentioned above? This element allows the same elements to be repeated multiple times in an app. Converting large amounts of this data quickly to a simple Excel format without pivot tables required utilizing my knowledge of data structures and algorithms. This made the end customers understand that we value their time. Converting this data was especially challenging when that data contains user variables.

User variables are a feature that allows the form creator to take the input in one part of the form (or any piece of data), potentially transform it, and use and or display it somewhere else in the form. This was necessary to allow customers to bring their own business logic to the apps they're creating.

Allowing customers to remain flexible and instantly update their apps was a crucial problem that we solved. Not only did we implement features such as versioning and user variables, we also allowed customers to bring their own data sources. Perfect for if you're managing many item of stock and you need to select one from a drop down list. EDR has you covered. A lot of programming was involved to get this feature to work with all the previous features. Thankfully, my use of SOLID principles allowed this to go smoothly. All the time writing testable, maintainable code.

Conclusion

To solve EDR's clients' needs, I programmed the front and backend of a powerful app builder including the following features:

• Drag and drop UI
• Rules engine
• User variables
• Data sources
• Excel export
• PDF generation
• Email notification
• File upload, persistence, and export
• Sharable links
• Offline functionality

EDR GmbH were delighted with my work. If you also want me to deliver something awesome, you can contact me here.