Keywords

1 Introduction

The design of user interfaces (UIs) is widely regarded as a critical factor for the acceptance of IT systems by users as well as for the acquisition of these systems by potential buyers. Although many system vendors today employ user experience (UX) designers to make UI design more effective, the fundamental problem remains that the space of possible UI designs can be too large to satisfy all users with a single solution. On the other hand, customising UIs is often tedious and costly, making many vendors opt for standardising their user interfaces, and limiting any customisations to broad user categories such as “simple users” and “advanced users”.

This approach is also followed by most vendors of business process support systems. They usually have a single UI that has the same look and feel for most of its users. However, as customers become more demanding and the scope of these systems becomes broader to include more domains and applications [18], the ability to customise UIs to wider ranges of user preferences and skills becomes an important competitive advantage. One example includes workflow management applications in the industry 4.0 domain that seamlessly integrate business processes with shopfloor processes. Here, workers with sometimes limited IT skills need to be provided with a very simple UI in order to adopt and master a given process support system.

This paper addresses the problem of customising the UIs of workflow systems by focussing on the “process of process execution” – i.e. the sequence of tasks to be performed, conjointly by a user and a user interface, necessary to execute the actual business process (called the “core process”). Specifically, the process of process execution (here called the “UI process”) is modelled and executed in the same way as the core process. Each of the tasks in the UI process is associated with data (called business objects) composing the content and appearance of the UI. The UI process is run on the same execution engine as the core process, readily allowing for the dynamic interconnection between the two processes at runtime. The existing method of Subject-oriented Business Process Management (S-BPM) [6] provides a uniform modelling formalism for both the UI process and the core process. The approach can be seen as a process model-driven method for customising UIs to the needs of different users, devices and core processes to be executed.

The paper is structured as follows: Sect. 2 introduces the relevant foundations of S-BPM modelling. Section 3 describes how UIs can be modelled as the processes of (core) process execution. It shows how the S-BPM notation and a tool suite for S-BPM modelling and execution, the Metasonic Suite (www.metasonic.de/en), can be used for defining the UI workflow and UI content, and establishing the connection between UI and core processes. Section 4 demonstrates the use of our approach in a shopfloor scenario developed within an ongoing EU FP7 research project (www.so-pc-pro.eu). Section 5 concludes the paper with a summary of the approach, including a brief discussion of how it is the result of applying a “good theory” in practice, in reference to Lewin’s quote that “nothing is more practical than a good theory” [10].

2 The S-BPM Approach to Business Process Modelling

Subject-oriented Business Process Management (S-BPM) is a method and notational approach to modelling and executing processes in a decentralised way. In S-BPM, processes are understood as interactions between process-centric roles (called “subjects”), where every subject encapsulates its own behaviour specification [6]. Subjects coordinate their individual behaviours by exchanging messages. The S-BPM approach is based on extensions of the Calculus of Communicating Systems by Milner [12] and Communicating Sequential Processes by Hoare [7]. Abstract State Machines (ASM) [1] are used as the underlying formalism to allow instant transformation of S-BPM models into executable software. S-BPM mostly targets those applications where a stakeholder-oriented, agile approach to business process management is preferred over more traditional methods based on global control flow. An increasing number of field studies demonstrate the benefits of S-BPM [5].

Based on the strong emphasis on the role concept and on the communication between roles, S-BPM shares some similarities with Role-Activity Diagrams (RAD) [13], UML communication diagrams, and the DEMO methodology [2]. However, there are also a number of significant differences with respect to these approaches. For instance, S-BPM has rigorously defined execution semantics, allows asynchronous communication, and supports end-user involvement in process modelling based on the simplicity of the S-BPM modelling constructs.

S-BPM models include two types of diagrams: a Subject Interaction Diagram (SID) specifying a set of subjects and the messages exchanged between them, and a Subject Behaviour Diagram (SBD) for every subject specifying the details of its behaviour. SBDs describe subject behaviour using state machines, where every state represents an action. There are three types of states in S-BPM: “receive states” for receiving messages from other subjects, “send states” for sending messages to other subjects, and “function states” for performing actions (typically operating on business objects) without involving other subjects. Examples of a SID and a SBD are shown in Figs. 1 and 2, respectively. They represent parts of a production process implemented in a Slovakian manufacturing company (in this paper referred to as “Company A”) within the EU FP7 project SO-PC-Pro. Here, the SID in Fig. 1 includes subjects that coordinate (via messages directed to one another) to prepare the actual manufacturing subprocess. The SBD in Fig. 2 represents the internal behaviour specification of the subject “Work Task Preparation”. The colours of the different states in the SBD indicate their types: green for receive states, yellow for function states, and red for send states. State transitions are represented as arrows, with labels indicating the outcome of the preceding state. For more details about the S-BPM notation readers may refer to Fleischmann et al. [6].

Fig. 1.
figure 1

Subject Interaction Diagram (SID) of a manufacturing preparation process on the shopfloor

Full size image
Fig. 2.
figure 2

Subject Behaviour Diagram (SBD) of the subject “Work Task Preparation” (Color figure online)

Full size image

Subjects may be executed by human or computational agents [4]. When executed by a human worker, parts of the subject may also be automated by associating pieces of code (called “refinements”) to individual states in the behaviour. These states are marked in Fig. 2 using a cogwheel icon in their top right corner. Refinements are always triggered from within the process in which they are defined, irrespective of whether that process is controlled by a traditional user interface or by another process.

3 Modelling Process Execution as a Process

The process of process execution is often a hybrid set of manual and automated tasks, the former commonly being guided by a UI. Using S-BPM, this process can be represented as a subject where some parts of its behaviour are executed by a human user and other parts are executed by a computational agent. We call this subject a “UI subject”, and the behaviour of that subject accordingly “UI behaviour”. The UI behaviour includes two aspects:

  1. 1.

    UI workflow: consisting of a sequence of generic steps independent of the specifics of the underlying core process. For example, a UI workflow may include a particular ordering of steps such as starting a process, displaying a list of user tasks, and editing a function state. The UI workflow can be modelled using an SBD for the UI subject.

  2. 2.

    UI content: consisting of the graphical elements (e.g. text fields, buttons, etc.) and appearance of the UI in terms of the layout, shapes and colours. UI content can be modelled as a business object within the SBD of the UI subject.

In this Section we describe how the two aspects of UI behaviour can be modelled and finally connected to the core process, using the commercial S-BPM modelling and execution tool Metasonic Suite.

3.1 Modelling UI Workflow

UI workflows can be modelled in various ways, depending on the needs of the specific users and devices, and the kind of core process they are to be connected with. The SBD in Fig. 3 shows one possible outcome of modelling such a UI workflow. The only types of states used in the SBD are function states, as the process of process execution is modelled using a single subject without any communication with other subjects.Footnote 1

Fig. 3.
figure 3

Example of a SBD defining the UI workflow

Full size image

The state “Initialize” is the start state of the SBD, including a refinement to load the initial user interface. In case of a technical failure occurring in this state, a transition is followed to the end state “End (init failed)”. In contrast, when the initialization is successfully completed, the states “Select process” and “Select task” need to be performed by the user. Depending on the nature of the selected task as either a function state, a send state or a receive state, the UI behaviour proceeds along separate paths (“Edit function state”, “Edit send state” and “Edit receive state”), after which the UI automatically executes the state “Compute next step” to loop back to one of the three paths. During task execution, the user may also switch back to the task overview and select a different task (i.e. follow the transition back to “Select task”), and, while doing that, may also select a different process (“Start process”). Upon termination of the core process, the UI behaviour reaches its desired “End” state.

3.2 Modelling UI Content

The UI content is composed of two groups of data queried from the associated core process instance: the business objects handled in that process, and some of the meta-data needed for process instance management (e.g. subject instance ID and currently active states). Both groups of data are loaded at runtime from the core process and are represented in a business object handled by the UI process. The definition of this business object can use the existing data types provided by Metasonic’s modelling editor (e.g. String, Number, Enumeration etc.), but also requires a new data type representing a placeholder for the business object of the core process. An example is provided in Fig. 4, showing the definition of a UI business object that contains data elements using standard data types and a placeholder for the core business object.

Out-of-the-box functionalities of the Metasonic Suite also allow defining custom views and layouts of the UI business object. Views [6] specify restrictions on the data elements, including whether an element is visible, hidden, or inactive for a particular state in a SBD. Views in the Metasonic Suite can be associated with client rules to define further attributes such as the colour to be used for displaying a data element. For every view a particular layout can be specified. In addition, the bootstrap framework (http://getbootstrap.com) is used for making the layout and shape of data elements responsive to different screen sizes, supporting conventional computer screens and mobile devices. All bootstrap functionalities such as CSS themes can be used to further customise the UI.

Fig. 4.
figure 4

Example for the definition of a business object in the UI process, containing a placeholder for the business object of the core process

Full size image

3.3 Connecting the UI Process to the Core Process

UI processes can be modelled either generically for any core process, or for a specific core process. For example, the UI behaviour shown in Fig. 3 is very generic and may be used for all core processes. Other UI behaviours may be defined to tailor the UI to a specific core process and turn some of the “fixed” UI components such as generic menu items and navigation buttons into dynamically generated components that depend on where you currently are in the core process. For example, the “Next” button that is normally used in many workflow UIs to proceed from one user task to the next, may be turned into a set of buttons labelled according to the specific user options defined in the core process.

The concept of generic and specialised UI processes as well as their interplay is shown in Fig. 5. Instances of generic UI processes (designed for all core process models) may be used for providing the UI for instances of any core process. Instances of specific UI processes can be used for providing the UI only for instances of that core process they have been designed for. All process instances are run on the same runtime environment, the Metasonic execution engine.

Fig. 5.
figure 5

Conceptual model of the interconnections between core process and UI process

Full size image

Running core and UI processes on the same platform allows utilising a number of built-in mechanisms to establish the communication needed between the two processes. As shown in Fig. 6, the Metasonic frontend executing the UI process uses Java Remote Method Invocation (RMI) via API calls and connectors to access core process instance data from the Metasonic backend. That instance data is stored in a DBMS that is queried using Java Database Connectivity (JDBC). The frontend can be accessed by web browsers via HTTP.

Fig. 6.
figure 6

Software architecture of the interconnected processes

Full size image

4 Example: Customising UIs for a Shopfloor Process

This Section illustrates our approach based on a case scenario used in the SO-PC-Pro project. Parts of the core process in this scenario – a manufacturing preparation process at Company A – were already introduced in Sect. 2. We will focus on the subject “Work Task Preparation” whose behaviour (shown in Fig. 2) is to be executed by shopfloor workers, guided by a UI running on mobile devices. The standard UI provided in the Metasonic Suite for executing the state “Check task” in this subject is shown in Fig. 7. As it is not modelled as a UI process, it is always the same no matter who executes the process or what core process is executed.

Fig. 7.
figure 7

Standard UI of metasonic flow, showing the data required to execute the function state “Check task”

Full size image

In the specific case at Company A this UI was deemed too complex to be used by shopfloor workers, as many of them had only limited IT skills. Therefore, a UI process was modelled with the aim to simplify the UI for the workers. The model of this process is almost identical with the one in Fig. 3; it is a generic UI process that may be used for any core process. The appearance of the resulting UIs for the consecutive states “Select process”, “Select task” and “Edit function state” in the UI process (cf. Fig. 3) is shown in Figs. 8, 9 and 10, respectively. The UI produced for the state “Edit function state” uses as a header the label of the state “Check task” imported from the core process.

Fig. 8.
figure 8

User interface for the “Select process” state in the generic UI process

Full size image
Fig. 9.
figure 9

User interface for the “Select task” state in the generic UI process

Full size image

These UIs contain only those pieces of information and functionality that a worker would interact with, eliminating all those general menu items, buttons and tabs previously displayed in the standard UI that were regarded unnecessary for the workers. The examples also show that different UIs can be created for different core process steps.

Fig. 10.
figure 10

UI for the “Check task” state (from the core process) used in the generic UI process

Full size image

The UI process was later specialised, as shown in Fig. 11, to increase comfort for workers when navigating in the core process from one state to another. For example, the resulting UI shown in Fig. 12 includes three new buttons – “Start production”, “Request CNC Code” and “Write CNC Code myself” – to proceed from “Check task” along the corresponding transitions in the core process (cf. Fig. 2).

A final design of the workers’ UIs was established after a few iterations in which the UIs were tested by workers in Company A using real process data. Desired UI adaptations were fairly easy to be implemented, simply by changing the UI process model without incurring major programming effort or changes to the core process.

A few technical limitations still exist related to the connection between core process components and the UI process. So far only (core) function states with one going transition can be controlled by the UI process, but not receive states, send states or functions states with multiple outgoing transitions. Development is already underway to address these limitations.

5 Related Work

Process modelling in the context of UI design has been proposed for a number of purposes, including usability analysis, requirements specification, and model-driven development [11, 21].

Fig. 11.
figure 11

Excerpt from the specialised UI process modelled for Company A

Full size image

An early approach to modelling user tasks for UIs is the one by Parnas [14] based on state transition diagrams. These diagrams are fundamentally very similar to our simplified SBDs that have only function states but no send or receive states. However, the sole purpose of the models is to represent UI requirements that are then interpreted by human UI designers. The execution of state transition diagrams for automatically generating and controlling the behaviour of UI software is not within the scope of his work.

Dubé et al. [3] proposed hierarchically-linked statecharts (HIS) consisting of UML class diagrams and state machines for specifying the structure and behaviour of UIs, respectively. In particular, the state machine formalism has been chosen based on its suitability for connecting UI responses with user events such as mouse clicks and key presses. Every visual element in the UI is defined with its own state machine. There are a number of similar approaches to model-driven design of UIs, using behavioural diagrams that are directly or indirectly drawn from UML [15, 16].

Work by Trætteberg and Krogstie [20] aims to realise individualised UIs by means of a model-based design approach that uses the core process model as a starting point. A task model representing the user’s tasks is first extracted from the core process model, and then transformed into a dialog model representing the interaction logic of the UI. The core process and the task model are both modelled using BPMN, whereas the dialog model is modelled using the Diamodl notation [19] that is partially based on UML state charts. This approach requires significant manual work for the individual transformations. Transforming core process models into task models involves splitting lanes into pools to make explicit the data flow between them and annotating the task model with pre- and post-conditions. Transforming task models into dialog models then requires additional manual translation effort due to the separate notations used.

Fig. 12.
figure 12

User interface for “Check task”, generated by a specialised UI process that has been designed only for the manufacturing preparation (core) process in Company A

Full size image

Kolb et al. [8] have proposed mappings between task-oriented process models, represented in BPMN, and the logic and contents of UIs, with the aim to generate UI components in a model-driven way. Based on that work, Schobel et al. [17] have implemented a system for designing the UIs of electronic questionnaires using process modelling, and for executing the UI logic on a workflow engine. Other work [9] proposes state-flow representations of data objects as micro-level processes that can be used for generating UIs. These approaches do not include modelling the core process separately from the UI process: There is only one process model that seems to represent both processes at once. While such a tight coupling has advantages regarding UI maintenance (i.e. if the core process is modified, the UI process is automatically updated accordingly), it prevents customising UIs independently of the core process (i.e. the ability to model multiple UI processes for the same core process).

6 Conclusion

The UI design of business process support systems is a critical issue in the execution of human-centric processes. For a long time, standardised UIs have been favoured based on the high cost of UI customisation. However, as customer demands become more heterogeneous, partly driven by the increasing scope of business process management to cover new domains such as factory and supply chain processes, there is a clear need for more customised UI solutions. This paper has shown how process modelling can be leveraged to develop UIs that can be customised fairly easily using existing functionalities of a BPM suite and integrated frameworks such as bootstrap. The self-referential approach of using process modelling for specifying process execution enables using not only the same technical platform but also the same type of knowledge: the knowledge of process modelling. As a result, developers and integrators of process support systems can address many UI customisation needs without having to employ dedicated UI design specialists.

Our approach is an example for the practical application of a “good theory”, using Lewin’s [10] terms. Here the theory is the S-BPM methodology; it can be seen as “good” because it includes two concepts whose practical application has been demonstrated in this paper: the genericity and the formality of S-BPM process models. The concept of genericity results from the highly abstract modelling constructs in S-BPM: Processes are modelled independently of their embedding in particular organisations and IT infrastructures [4], using only five abstract symbols. This allows modelling any kind of process, including human-centric (business) processes, computational processes and manufacturing processes. In this paper we have shown how the process of process execution, which is often a mixture of human-centric and computational activities, can be modelled with S-BPM. The other concept, formality, is established by the well-defined execution semantics of S-BPM. It allows model-driven transformation of graphical process models into executable software. We have shown that this concept enables turning the modelled process of process execution directly, i.e. without manual intervention, into a running software – the UI of a process support system. We expect that this would be very difficult to be achieved using traditional BPM methodologies such as BPMN, due to their insufficient formal foundations.

Finally, the application of S-BPM for customising UI design can be seen as an example of the “eat your own dog food” principle: As a vendor of an S-BPM suite, we use our own methodology (S-BPM) and our own tool (Metasonic Suite) as a basis for generating customised UIs for our process execution frontend. The technical extensions needed for the realisation of this approach have now matured to product-level quality and will be available on the market with the next feature release (version 5.3) of the Metasonic Suite.