Low-code development has been around for many years and has experienced ebbs and flows in popularity, but has recently picked up steam again due to COVID-19. Businesses are looking to ramp up their digital transformation efforts — whether that means just starting an initiative or making significant changes or improvements to digital products already in use. Low-code development can be a great way to quickly build prototypes that help take innovative plans from ideation to validation.
One thing is for sure: low-code app builders simplify and democratize traditional development, putting a large amount of responsibility on low-code platform developers to keep everything running smoothly.
This article details three major issues that low-code developers need to consider in order to deliver the best possible user experience.
Integrating with third-party services
Integrating a mobile application with third-party services is an absolute must. End users and customers need to be able to log in to mobile apps with Google or Facebook, integrate Google maps, retrieve data from around the web, and more. A typical modern app should interface with anywhere between five and 10 third-party services.
Achieving the optimal number of integrations is no trivial matter. There are several complicated steps to follow: creating an account with the third-party service, creating development assets, and configuring everything correctly.
A pervasive problem with third-party integration is that developers have no control over third-party services — the API or security policy can be changed at any time. It’s the third party’s prerogative to do this to protect their security and reputation, and when they do, it’s your responsibility to update your app ASAP.
Passing on the responsibility to stay up-to-date to low-code developers is a pretty big ask. Even so, it is the default approach to maintaining smooth integration with third-party services.
Wizards and middleware
The best solution to this problem is two-fold.
First, to make configuring the app simple and painless, low-code platform owners can hide all the configuration complexity from their users. In its place, they can put a setup wizard or other tools that help developers navigate each configuration step.
Second, and most importantly, platform owners can use middleware that stands between the third-party services and the low-code developers. This means that when a third party makes changes, the low-code platform owners can update the middleware and developers don’t need to worry about changing anything. Most APIs notify in advance that they’ll be making changes, and this gives the owners plenty of time to get their middleware in order.
If the platform owners miss a change in a third-party service, they’ll be notified by all low-code developers that there is a problem. They can then make changes to the middleware that will be automatically applied to all products using that third-party service. There’s no need to deal with the tedium of updating each app individually.
Lastly, platform owners generally cache data from third-party services in their middleware, so the low-code products will show data, even if it’s not up-to-date. Generally, apps will notify end users that the data is outdated, but everybody can agree that showing yesterday’s data is preferable to showing a depressing greyed-out broken link.
Custom components
Low-code developers often want to use the same UI components, the same screens, and the same logic across different applications. To address this need, app-building platforms use custom components to streamline the user experience.
The panacea approach
The first option for creating custom components is to make an advanced smart screen with customizable elements. To do this, platform owners must attempt to predict everything that a low-code developer could possibly need and then make a huge configurable component.
The issue with this approach is that configuring the component is almost as difficult as creating the UI from scratch. First, low-code developers will have a laundry list of properties to customize along with all the documentation they’ll have to read, internalize and apply. It is a practically impossible task to cover every use case with a component, meaning this approach often creates more problems than it solves.
Custom DIY component
The second and more reasonable option is to have users create their own custom components. This way the platform owners supply the building blocks for making components rather than the components themselves.
This saves time and can help low-code developers resolve errors. Developers who find errors in the components they employ across many apps can address the problem once in a custom component, and the fix will carry across to all their apps.
Additionally, community-minded developers can share their components with others, build a library of their own components, and control the parameters under which outsiders can see, use, and manipulate them. They can do this with total open source or restricted open source.
There is a tradeoff with this approach: low-code developers need to have a deeper understanding of the overall picture to build great custom components without predefined options. But with this extra work they’ll gain much more flexibility.
Distinction between design-time and real-time
The third major issue with low-code app development is distinguishing design-time and real-time. When low-code developers are in the process of building an app, what they see (design-time) is different from what users see when they use the app (real-time). Simply put, apps look different when they’re in the editor and when they’re used in devices.
Why the difference?
This happens because the two environments use different logic, libraries, and frameworks to express the UI. For example, if an application is created in React Native, the UI will use HTML components, as browser UI’s are written in HTML. In real-time, developers see the real native app (e.g., an iOS button) but in design-time they’ll be looking at an HTML button.
Typically, low-code tools use different libraries, one for design-time, one for iOS, and another for Android.
One library, less expression
To get around this issue, low-code platforms can use the same UI library in the editor as mobile phones use for all situations: design-time, iOS, and Android.
This is incredibly advantageous when developing an app because developers know exactly what the end user will experience, so there are no surprises. They also get the exact same UI in iOS and Android.
Still, there are significant drawbacks to this approach. Libraries are like languages; there are often phrases and expressions that cannot be translated from one language to another. Limiting applications to one library exchanges unique idiomatic language for maximum clarity and consistency.
Getting the job done
The low-code approach comes with some pros and cons, but at the end of the day it’s a powerful means to an end. Low-code allows developers to build functioning applications quickly, efficiently, and with comparatively low expertise. Even major concerns with low-code development can be addressed and resolved. In the digital age, low-code is undoubtedly a key player.
