Web Interfaces

A web interface is a user front end of an application. It is designed in a device-independent way. Following the principles of responsive design, DigitalSuite provides for the appropriate processing and rendering so that users can interact with the application from desktop, tablet, or mobile devices.

A web interface may define a web page to launch a process and/or web pages for end users to carry out manual tasks specified as process activities. In DigitalSuite, a web page of a web interface is called a screen. A web interface can contain as many screens as required.

Basically, a web interface can launch and interact with exactly one process. However, designers can use process listeners to make a web interface work with more than one process.

Instances of web interfaces and their screens are created and opened when users start the application or access manual tasks in their personalized environment in web browsers or RunMyApp.

The design and configuration of a web interface comprises the following settings and considerations, which are described in detail in the sections below:

Web Interface Identification

The following settings identify a web interface in DigitalSuite:

• Name: The name of the web interface. It is used as the title when the web interface is launched.

  The name of a web interface should be that of the application for which it provides the front end, for example, Expense Request or Onboard Employees. Web interfaces which are used to carry out subordinate or background tasks should be named according to the task or the role supposed to execute it, for example, Report - Employee or Backoffice - Companies.

• ID: A generated number used to uniquely identify the web interface.

• Description: A short description of the web interface and its purpose.

By default, each screen of a web interface has the interface's name as its title. However, it is possible to define dynamic names to give each screen its own specific title. Dynamic names can be composed of static text and variables, for example, Order for ${client_name}. The title is determined at runtime for each screen that is launched. Any variable available in the web interface launch screen can be used.

Screens

A web interface can have several screens, which are used for different groups of users and steps of a process. For example, an employee may use the first screen to submit a request which launches a process. A manager uses the second screen to approve or reject the request.

The assignment of web interface screens to process steps is made in the process design. The screen which launches a process is referred to as the launch screen.

Each new screen added to a web interface is a copy of the previous one and includes the same design elements. New design elements, so-called widgets, are added to all screens. While the design of each screen is therefore the same, visibility properties determine which widgets are presented to the users at runtime in different situations and for the different process steps. Managing screens in this way makes it possible to share elements and variables without having to re-create the items multiple times.

The screens of a web interface can be rearranged at any time to reflect the order of the steps in the related process.

Header

Designers can compose the header of a web interface of the following elements:

• A title of their choice.
• A menu bar, which may include images, text entries, and submenus. The menu options direct the users to given URLs or execute JavaScript. The visibility and availability of the menu options can be controlled in a static or dynamic way. For example, some menu options may only be visible to users with specific roles.
• A task basket containing the current user's tasks within the current web interface, another given web interface, or all DigitalSuite applications the user is authorized to access.

Widgets

A widget is a design element or component of a screen, for example, an input field, button, or image. Developers use widgets to quickly design user interfaces by drag-and-drop.

The widget settings determine on which screens of a web interface a widget is available and visible, and whether user input is possible or required. For example, a field for executing JavaScript may be available, but not visible, a text field may be read-only, or the selection of a value from a list may be mandatory.

For details on the available widgets, refer to Widget Types.

Custom Widgets

A custom widget is a reusable web interface. Designers can create such web interfaces with elements that are often used together, for example, a number of input fields to describe a customer or menus to be applied to several web pages of an application. Custom widgets can be utilized in any other web interface in the same way as standard widgets. They allow the web interfaces they are included in to open more quickly, because the widgets within them are loaded asynchronously.

Compared to standard web interfaces, custom widgets:

• Cannot be launched by themselves.
• Consist of one screen only.
• Do not provide the full range of settings.

The names of custom widgets should have a CW - prefix, for example, CW - customer.

Availability

Access to a web interface can be set to public or private. In order to open private web interfaces, users need to authenticate and have the required permissions. Public web interfaces are available to everybody without verification. However, they must have a Captcha widget to prohibit automated access and attacks. A process launched by a public web interface must also be public.

For each web interface, customers can:

• Decide whether it is available on the custom homepages they have configured for desktop and mobile devices. Only web interfaces of application versions running in the Live execution mode can be made available on the homepages.
• Set a favicon and thumbnail image for quick identification.
• Provide tags which can be used for different purposes. For example, the Homepage portal application, which customers can use for their own homepage, retrieves the accessible web interfaces and displays them ordered by their tags.
• Add a tracker for Google Analytics with a given ID and URL.
• Allow users with read access by a role with Observer access rights to add comments to an Application History widget.

Stylesheets and Layout

DigitalSuite comes with predefined cascading stylesheets (CSS) and settings that determine the appearance and layout of a web interface.

The location and handling of layout and style settings depends on the rendering engine on which the web interface is based:

Application Runner: Layout and style settings are spread across a web interface and its widgets. Settings at the web interface determine the general layout (with or without borders) and text direction (left to right or right to left).

WIRE: All layout and style definitions are collected in a central CSS. In the web interface settings, templates are available which contain the predefined styles and can be used as the basis for customizations through CSS file.

• Designers can specify font, coloring scheme for the web interface header, contents, and texts.
• Designers can also add one or more custom stylesheets of their own in the web interface settings. Their style definitions take preference over the predefined ones with the same name. The stylesheets can be created at the web interface, uploaded, or imported from other projects. It is even possible to reference external stylesheets by their URL, although this is not recommended.

For more details, refer to Differences Between Rendering Engines.

JavaScript

The functionality and behavior of a web interface is to a large extent determined by JavaScript. For example, JavaScript can be used to specify the conditions upon which a widget is visible or accessible, validate user input, define the contents of a report or array, or execute actions upon the click of a button. DigitalSuite provides JavaScript APIs with all the required classes and functions.

The location and processing of JavaScript code depends on the rendering engine on which the web interface is based:

• Application Runner: JavaScript code snippets are spread across a web interface and its widgets. Application Runner takes care about the execution order and event management. In the web interface settings, JavaScript files and libraries can be specified for the header or footer to be executed before or after the web interface has been loaded. With JavaScript in the footer, loading is faster as when adding a script to the header.
• WIRE: All JavaScript code is collected in at least one central versioned file, which is configured in the web interface settings. The JavaScript is executed for all web interface instances and screens after these have been loaded. Functions for all predefined events of all widgets are available for controlling the execution in the JavaScript.

For more details, refer to Differences Between Rendering Engines.

The files containing the JavaScript to be executed can be created at the web interface, uploaded, or imported from other projects. It is even possible to reference external JavaScript files by their URL, although this is not recommended.

In addition, DigitalSuite offers standard JavaScript libraries which can be included in web interfaces as required:

• JavaScript SDK with functions to handle DigitalSuite resources, accounts, roles, and miscellaneous data as well as localization.
• jQuery libraries and plugins with functions to ease the client side development and improve the user experience. One of the benefits provided by jQuery is the possibility to add DigitalSuite components in modal windows.

Collections

Web interfaces can make use of one or more collections as their data basis. Collections can store any kind of data, for example, on customers, products, or assets.

A collection can be made available to one or several screens of a web interface, where it can be accessed by means of JavaScript.

Listeners

Web interfaces can be configured with listeners that trigger actions when certain events arise. For example, a listener may retrieve data from an external system based on variable values entered in the web interface. A listener can be configured for all screens of a web interface or a selection thereof.

The actions that can be triggered are:

• Launch a composite API
• Launch a process
• Call a connector. This option is not available with web interfaces based on the WIRE rendering engine. A composite API can be called instead.

The events that can trigger an action are:

• Screen Initialized: The action is triggered when the web interface screen is launched.
• Listened Variable Changed: The action is triggered when the value of a given variable changes.
• Screen Closed: The action is triggered when the web interface screen is closed, i.e. a user clicks a respective button.
• Manually via JavaScript: The action is triggered by the execution of a JavaScript. This is possible only for listeners launching composite APIs or connectors.

Designers need to ensure that all parameters required by the listener are defined appropriately as variables of the calling web interface. All web interface variables are sent to the launched listener.

At various points of listener execution, like upon completion or failure, or for a specific process state, scripts can be executed. These can be used, for example, to fill in the fields of a web interface screen according to the listener's return values.

The specification of events and scripts depends on a web interface's rendering engine. For details, refer to Differences Between Rendering Engines.

For optimum results of working with listeners, it is worth considering their execution:

• Connectors and composite APIs are executed synchronously, i.e. the web interface waits for their results. Their execution paths are not persisted, which makes them quite efficient.
• Processes are executed asynchronously. Their execution path is persisted, and their result is polled regularly from the web interface.

Consequently, composite APIs or connectors always yield better performance results than processes.

However, working with process listeners may be useful in specific situations, for example, to work with more than one process from a single web interface. In this case, it may be worth considering to trigger only one "screen initialized" process listener with subprocesses. Polling the result of several process listeners may degrade the performance of JavaScript execution.

Rendering Engine

Each web interface created in DigitalSuite uses a specific rendering engine for formatting and presenting its screens and widgets on different devices as specified in predefined and custom style declarations.

DigitalSuite provides the following rendering engines:

• Application Runner: based on the Google Web Toolkit (GWT), a development framework for web applications.
• WIRE: based on React and Material-UI, a JavaScript framework and components for building user interfaces. WIRE is newer and more advanced than Application Runner. Major advantages are its improved responsiveness, rendering and rendering performance, ease of customization, full support of HTML5, lazy loading, and faster start of JavaScript and web interfaces in general.

Designers can select the rendering engine when they create a web interface. When designing and configuring a web interface with its widgets, some differences due to the rendering engines have to be taken into account. These are described in detail in Differences Between Rendering Engines.

Alias Web Interfaces

There is a special type of web interface called alias web interface. Alias web interfaces are part of the standard portal applications. The screens and widgets of alias web interfaces cannot be modified.