“Touching” Workflow Management at Runtime Joey E.W. Claessen and Hajo A. Reijers Eindhoven University of Technology, joey_claessen@hotmail.com,h.a.reijers@tue.nl Abstract. New technologies are being introduced into our lives on a almost daily basis. Touch technology is a recent one which changes the way we interact with devices. It influences the work environment a user works in: Instead of only a desk with a PC, the environment is enriched with devices like a smartphone or tablet. For these new products the user experience is important, whereas in Workflow Management Systems this subject not received much attention. It would, however, be an interest- ing subject for Client Applications of Workflow Management Systems. This study shows what a Client Application for a Workflow Management System could look like integrating touch technology. 1 Introduction In 1973 the first touch screen was put to use, which was manufactured by CERN [1]. Already in 1965 [2] and 1967 [3] papers were written about the concept of touch. Now, 40 years later, touch screens are everywhere, from a smartphone up to a laundry washer. A development that was used in this paper was the develop- ment of a table containing a large touch screen (further called ’touch table’). This table could change the traditional work environment dramatically. New consumer products containing new technologies that are being launched, are tailored towards the customer. In the research on Workflow Management Systems this does not receive much attention [4]. The prototype described in this paper was constructed by taking a user perspective: first use cases were identified, then requirements, followed by the creation of the prototype and an evaluation. By following a user perspective and integrating touch, two additions to the conceptual model of a Workflow Management System were identified. The con- text of the conceptual model is the Workflow Reference Model as can be found in [5]. This study will mostly be directed towards the Workflow Client Application. A screencast of the prototype can be found at https://www.youtube.com/ watch?v=SnoH_ZvE6B0 2 Design The desire for the prototype came from business. A department within ING, Trade Finance Services, has a process to handle Letters of Credit. A financial 2 Joey E.W. Claessen and Hajo A. Reijers product ensuring a large amount of money is available when a trade is accepted. They wanted an idea of how the as of yet manual check of documents, which go along with a Letter of Credit, would look like on a touch table. From this story, a fictive story and literature research requirements were identified. The most important ones are described below: – Support the basic work item tasks (allocate, start, complete, fail) – Touch screen setup – Touch screen interactions – Subtask actions (create, allocate, start, complete, fail) – Annotation of a work item – Document handling 3 Mapping The identified requirements formed the basis for the design of the prototype. To reflect back on how the current conceptual model supports the view of users on how the prototype should look like, a mapping was created. It mapped each re- quirement (except the touch requirements) onto conceptual elements of a Work- flow Management System. The most important element to map to was the basic of a work item1 . From this mapping two new features emerged: subtasks and annotation. Subtasks The concept of a subtask is that, if a user is performing a work item and (i.e.) needs input from someone else, a subtask can be created. The subtask is similar to a work item except that it is smaller (one small action) and not forseen in the modeling phase of the process. The subtask should inhibit the work item from being completed as long as the subtask is not completed (or failed). To assure the consistency of the model, it is important that subtasks are small and consist of only one step or action. There are conceptual alternatives available providing flexibility in a process. However, most of these are to be taken into account during the modeling phase (i.e. flexibility by enumeration, late binding [6]) where subtasks operate on run- time. The set of techniques that does work in runtime does not match the goal of subtasks, like dealing with expected exceptions or uncertainty [6]. The basic life-cycle of a work item (Fig. 1) has been expanded with subtasks. This extension consists of a state “Started with subtasks”, a state “Suspended with subtasks” and the corresponding transitions. For the subtasks itself a new life-cycle is created. This life-cycle is almost the same as the one for a work item, consisting of the states: created, allocated, started, completed and failed (and corresponding transitions). The difference is the removal of the suspended state, and all transitions are initiated by a resource. 1 http://www.workflowpatterns.com/patterns/resource/images/fig5.png “Touching” Workflow Management at Runtime 3 Fig. 1. Work item lifecycle with subtasks Annotation The concept of annotation is based on the desire of users to be able to add data to a work item (or workflow case). The data to add concerns data that does not fit into the data model, yet is designed during the process at run-time. This could be, for example, information that can help colleagues further in the process. There have been suggestions to create annotation, but these implementations often focus on identifying steps in the process that should be changed. 4 The prototype The most important basis for the prototype were the requirements. These iden- tified the required functionality, but choices remained like the development en- vironment and Workflow Engine to use. A web application was the choice of development environment. For the Workflow Engine, YAWL was used. The physical setup consisted of a server (running the application and YAWL 4 Joey E.W. Claessen and Hajo A. Reijers engine), a work client (i.e. pc, laptop or touch table) and mobile devices. The basic environment in which the user works with the prototype is called the workspace. After a user has logged in, the following basic control elements are available: Active windows These “screens” can be compared to windows in a normal operating systems. Minimized windows A menu where all minimized windows are grouped. Inbox All work items addressed to the current user are showed. With this as the basis of the prototype, the next sections will describe the func- tions and features that the prototype supports. Work items The most important part (for the user) of a Workflow Client Application is to view and be able to perform work items. The user is able to view her inbox, as already mentioned before. After opening the work item, the basic actions are available: accept, start and execute. Besides being able to show standard work items, the prototype also has the capability to create custom forms for a specific type of work item. This enables custom functionality which does not have to be supported by the engine. Annotation A specific part of the prototype concerns the annotation of doc- uments. These documents are used throughout the whole process and the users desired the capability to add notes to documents. Once a note is added to a document, it is also visible to other users in the process. Subtasks When a user is executing a work item, she can get an overview of all the created subtasks and their statuses. New subtasks can be created. An interesting detail is that the target user of a subtask does not need to be a user within the Workflow Management System. Via an emailaddress a user outside of the system can be targeted. That user will receive an email containing a link to complete the work item. Multiple devices The user stories in combination with the trend of bringing multiple devices required the support of multiple devices into one environment. Active windows can, besides being moved around in the screen, also be moved to other devices, making it one integrated environment. 5 Evaluation Two types of evaluations were performed on the prototype: an evaluation by requirements and one by users. The evaluation from requirements showed that because of time constraints not all requirements made it to the prototype. Basic functionality had the highest priority causing elements like failing or reallocating “Touching” Workflow Management at Runtime 5 a work item not to make it to the prototype. Since the user perspective in this study was leading, the user evaluations were very important. Two sub-types of evaluations were performed: the first was with ING employees and the second with PhD students with an affinity for Workflow Management Systems. The number of ING employees that were able to evaluate was too low to perform a reliable statistical analysis, but they involved employees knowing the process that was modelled and some were professionals in the area of prototypes. Their conclusion was that although it was still a prototype, the strength and po- tential of it was evident. The goal of the evaluation with the PhD students was to see whether the claimed new components were really innovative, and besides that, get inspira- tion for future work. They also identified the requirements that were not im- plemented, as missing. Their conclusion was that there were ways to deal with flexibility which look a lot like the subtask but not match it completely. Also the annotation was new but would be quite simple to implement. 6 Conclusion The realised prototype is not in a completed state yet, but it is capable of showing what a Workflow Client Application could look like in the future as was the goal. Users that have evaluated the prototype were enthusiastic and positive about the possibilities for the future. The subtasks are a source of possible future research as there are a lot of possibilities with them. The feature of the multiple devices in it self does not have a specific connection with Workflow Management Systems but was perceived as a powerful feature which will come to our work environments in the future. References 1. CERN. Another of cern’s many inventions! http://cds.cern.ch/record/1248908, 2010. 2. E.A. Johnson. Touch display - a novel input/ouput device for computers. Electronic Letters, 1(8):219–220, 1965. 3. E.A. Johnson. Touch displays: A programmed man-machine interface. Electronic Letters, 10(2):271–277, 1967. 4. G. Alonso, D. Agrawal, A. El Abbadi, and C. Mohan. Functionality and limitations of current workflow management systems. IEEE Expert, 12(5):105–111, 1997. 5. D. Hollingsworth and U.K. Hampshire. Workflow management coalition the work- flow reference model. Workflow Management Coalition, page 68, 1993. 6. B. Weber, S. Sadiq, and M. Reichert. Beyond rigidity dynamic process lifecycle support. Computer Science - Research and Development, 23(2):47–65, 2009. Copyright c 2014 for this paper by its authors. Copying permitted for private and academic purposes