UI Development Is More Than Coding

The usual statements were floating around, ranging from, “We had that 30 years ago, and it was called CASE tools” to “It does not work, you will always need coding” to my statement “It only works for simple apps”. SAP states differently and defines AppGyver as equally powerful as classic UI programming.

Speeding up development via better tooling is always a good idea in my mind, regardless of the name. My biggest concern is SAP’s goal to enable the citizen developer. Its promise: Anyone in an organization can build new enterprise-grade applications.

Just for now, I would like to put the question about the limitations of no-code tools aside and assume everything is possible and easy with these tools. Instead, I’ll argue that app development requires more skills than just assembling the UI. Firstly, it requires business understanding – which the business user has much more of than the IT department. So, that is one argument in favor of enabling citizen developers.

UI design

However, UIs created by business experts tend to be full of functions and buttons. They know all the business cases and their exceptions, but will the outcome be a fun-to-use UI? There is an entire research area of Human Computer Interfaces (HCI) dealing with questions about how to design a good user interface. SAP has acknowledged that and offers the services of AppHaus, an organization helping to build properly designed apps, to internal teams and customers. The Fiori design guides are another example of guardrails for well-designed apps.

Developers usually already know all that, either because they were taught in university or during their professional career. Do we have to teach these principles to citizen developers as well? Regardless of how we choose to answer that question, we are faced with problems: Either this knowledge is useless, the business users should only be building small apps where a user-friendly UI does not matter much, or the claim that citizen developers can build professional grade apps is invalid. Either way, something does not quite fit.

Product standards

At SAP, all software must be developed according to a set of product standards. Products are validated against those standards prior to their release. They are a key part of the design and coding process. These standards include a lot of requirements a business user might only start considering in the aftermath. These standards are internal documents, but some public documents offer a glance at them.

A few examples of the most important questions:

• Does the UI render nicely on any screen size, from a laptop to a desktop PC with a 4K screen to smartphones?
• Are authorizations utilized in the UI? For example, if the user has no permissions to edit a sales order, only to view it, all buttons and links related to the edit screen must be disabled. Otherwise, they might be able to click on the edit button, just to be faced with an error message.
• Is the application secure?
• Does the UI prevent entering invalid values?
• Is it able to deal with invalid input that is injected by a hacker bypassing the UI?
• Can the app be translated to other languages without code changes, including right-to-left languages?
• Are keyboard navigation and screen reading supported, which are required for disabled coworkers?

Obviously, not all of these requirements will always be relevant to every project. But we are only focusing on the claim that no-code tools allow citizen developers to build professional apps, not on any specific use cases. This should make it clear that the coding part is serious work, but the design part and other aspects are equally important.

With that out of the way, we can get back to the limitations a no-code tool might have.

Potential limitations

In respect to SAP applications, there are three main areas where I see limitations in no-code tools: model transformation, functions and controls.

One important limitation in AppGyver and all other no-code tools is the backend. Nobody ever said that these tools provide a point-and-click interface to develop new interfaces in the backend, e.g., a new oData service in S/4 Hana or a new BAPI to be exposed via the Abap Restful service. Using the existing SAP services would limit our UIs to be alternatives to the SAP-provided applications. Or is there any API which SAP provides and has no UI to maintain the same data?

Even combining multiple API calls in a single app for a more fluent workflow is often not possible as each oData/Rest call is stateless. There is no such thing as a transactional consistency foreseen by SAP for these APIs whereas a begin-transaction-commit is standard for RFCs/BAPIs.

Model transformations

The bigger problem is that the UI expects the data in a specific format which often is different from the backend model. Let’s take a drop-down box as an example to show the SAP material hierarchy. The drop-down control requires the data to be provided as a flat list, the backend provides the data either as parent-child structure or as a multifield table. Somebody has to do the model transformation, meaning to either change the SAP system or perform that task in our newly built UI. The no-code tools claim it is the task of the backend to provide the data as required by them. If that is true, then five UIs showing the same data but in different fashion need five different APIs. The backend developers would question that – for a good reason. They would say such model transformation is the task of the UI.

Functions

Such transformations happen on the field level as well. A user types an IBAN, and a function should validate the checksum. That is quite some logic to perform. The backend provides the data in a timestamp column, but we must format it to a year value. The user enters a phone number using separator chars, but the backend requires it without – so all non-digits must be removed and a leading +1 (US country code) should be turned into 001.

Can we reasonably expect all possible functions for any kind of usage to be provided by an out-of-the-box no-code tool?

Controls

For simple apps, the number of controls (“components” in AppGyver terminology) is limited. Text, input field, title, checkbox might be sufficient. However, no matter how many controls are provided, our concrete UI will need more. Just check the vast number of controls SAP provides in OpenUI5. In SAPUI5, the list is even larger. Controls to draw charts, color picker, an entire control to edit a workflow. But even that list is missing controls I required in the past for my projects. Yes, new controls can be added to all tools but if 90 percent of the UI development goes into classic programming to provide the control, we are far from the idea that a business user can build their own UIs without the help of IT.

Verdict

I am all in on no-code development, as long as it can be extended by classic code, models, functions and new controls. Then I have the best of both worlds: A graphical way of arranging the controls with which I can show the current UI to the business user and the two of us can design the UI together, and yet, I retain the full power of classic programming. There are no doubts in my mind about the usefulness of no-code tools. However, I just don’t buy the statement that such tools empower the business user to become a citizen developer, allowing them to build more than simple apps.