=Paper=
{{Paper
|id=None
|storemode=property
|title=Editor 3.0: Redesigning the YAWL User Interface
|pdfUrl=https://ceur-ws.org/Vol-982/YAWL2013-Paper08.pdf
|volume=Vol-982
|dblpUrl=https://dblp.org/rec/conf/yawl/Adams13
}}
==Editor 3.0: Redesigning the YAWL User Interface==
https://ceur-ws.org/Vol-982/YAWL2013-Paper08.pdf
Editor 3.0: Redesigning the YAWL User
Interface
Michael Adams
Queensland University of Technology, Brisbane, Australia.
mj.adams@qut.edu.au
Abstract. It has long been a concern that the wider uptake of the
YAWL environment may have been hindered by the usability issues iden-
tified in the current Process Editor. As a consequence, it was decided that
the Editor be completely rewritten to address those usability limitations.
The result has been the implementation of a new YAWL Process Editor
architecture that creates a clear separation between the User Interface
component layer and the core processing back end, facilitating the re-
design of the default user interface. This new architecture also supports
the development of multiple User Interface front ends for specific contexts
that take advantage of the core capabilities the new Editor architecture
has to offer.
Keywords: YAWL, Editor, Workflow, User Interface
1 Introduction
For any software, user acceptance must be of primary concern, and for most
users the design and accessibility of the user interface (UI) has a much greater
bearing on uptake and continued use than any functionality the software pro-
vides. For existing products, redesign of a user interface can lead to substantial
improvements in learning time, performance speed, error rates and overall user
satisfaction [1].
The first version of the YAWL Editor appeared almost a decade ago as a
prototype, with the objective of demonstrating that it was possible to graphi-
cally design a process model in the YAWL language and have it transformed into
a format that could be interpreted and executed by the YAWL Engine. Orig-
inally supporting only the control-flow perspective, many versions have since
been released to include support for the data perspective and later the resource
perspective, then timers, configuration, extended attributes and many other fea-
tures. In each case, new functionality was ‘grafted’ onto the core prototypical
architecture. Over time the result was a code base that had become difficult
to maintain and extend, and a user interface that revealed both its age and its
usability limitations.
To address these shortcomings, the YAWL Editor has been completely re-
designed and is being rewritten from the ground up. The overriding driver of the
project has been to make the Editor easier to use, and therefore more accessible
to a wider audience. This paper outlines the main features of the new Editor.
56
2 Code Redesign
The original Editor architecture has a flattened package structure that mixes
the user interface components with the underlying data manipulation and trans-
portation. This meant that the user interface components were very tightly cou-
pled to their data, which made it difficult to introduce changes to either aspect
without disturbing the other as a side-effect. In addition, on opening a specifica-
tion file, the Editor would first use Engine classes to parse the XML description
contained in the file, then use those objects to populate its own ‘mirror’ classes
(the Engine classes contain the code to (un)marshal to and from XML). When
saving a model to file, that process was reversed. This policy introduced a large
degree of redundant and error prone code, an artefact of its prototypical heritage.
Fig. 1. An Overview of the New Editor User Interface
In the redesigned Editor there is complete separation of the UI from the
underlying framework. The main advantages are twofold:
1. The completely separated core framework can now be deployed in its own
jar file. This allows external developers to create new and multiple user
interfaces that interact directly with the core framework through a concise
API, and frees them from concerns regarding how to store and manipulate
specification control flow, data and resourcing descriptors, and file handling
techniques.
57
2. The core framework interacts with the YAWL Engine classes only. The
negates that need for transformations when opening and saving specifica-
tion files, which results in much faster file reading and writing times, and
removes the scope for introducing errors into the ‘backend’ code when de-
veloping user interfaces.
3 Interface Redesign
A large factor in the usability of a software
product, and particularly an graphical editor,
is the ease with which the properties of an
object can be set, updated and maintained.
The original Editor used a number of different
methods to update properties, found in vari-
ous places within the interface. For example,
specification properties were set via a dialog
accessed from the File menu, and net proper-
ties from the Net menu, while task properties
were generally accessed via a right-clicked con-
text menu on the task itself. Adding a split or
join to a task was accomplished via a box un-
der the palette. Selecting an icon for the task
was done in a different location again. Having
various locations for these similar capabilities
necessarily reduces usability and control.
The new Editor interface places all of the
properties, for all aspects of the active pro-
cess model, within a single expandable Prop-
erties window to the left of the graphical can-
vas (Figure 1). The relevant set of properties
and their values for the currently selected ob-
ject or objects are displayed in their appropri-
ate form. Such properties windows are com-
mon in today’s editors, and knowing that all
properties can be set in one location greatly
aids ease of use.
The detailed view of the Properties win-
dow in Figure 2 shows that the currently se-
lected object is a task with a decomposition, Fig. 2. The Properties Window
(detail)
which therefore allows all properties of the
Specification, Net, Task and Decomposition to
be viewed simultaneously and easily selected for editing. Values are displayed in
a format dependent on their data type. For example, simple values (e.g. Name,
Version, Label) are shown as is, boolean types (e.g. Root Net, Sync, Automated)
58
as check boxes. More complex values, such as Fill Colour, Font and Data Vari-
ables, are shown in a summary form appropriate to their type.
Values for properties such as Data Gateway, Icon, Split and Join Types and
Positions, and Decomposition are selectable via a dropdown list. Any property
modification that represents a visual change is instantly updated on the canvas,
and vice versa. For example, the current location coordinates for the selected
task can be changed manually in the Properties window, which will immediately
move the selected task to its new location on the canvas. A description of the
currently selected property is displayed at the bottom of the window.
Data Perspective Arguably the most significant impediment to usability for
the casual user in the original Editor was the requirement of a knowledge of
XQuery for all but the most trivial of process designs. Typically, net-level vari-
ables were added via the Net menu, task-level variables via the Decomposition
Update dialog (accessed from the right-click context menu) and then mapping
input and outputs with XQuery parameters was achieved via the Update Param-
eter Mappings dialog (again form the context menu). Thus, a greater learning
curve was needed, with each step providing more scope for error.
Fig. 3. The New Data Variables Dialog
In the new Editor, great care was taken to simplify this process as much
as possible, through the introduction of a consolidated Data Variables dialog
59
(Figure 3). This dialog, invoked from the Task section of the Properties window,
provides for the definition of net-level and task-level input and output variables
all within the same simplified dialog. Each of the three areas in the dialog pro-
vides columns for name, type, scope and initial or default value, as appropriate,
and each contains it own mini-toolbar, for adding, removing, editing and re-
ordering variables. The confusing notion of Input&Output scoped variables has
been dropped; it is now clear that a task may have a set of inputs and a set of
outputs, aligning the Editor’s data perspective with that of the Engine.
Notably, a net-level variable can be mapped to a task variable simply by drag
and drop, and the required XQuery mappings are automatically created and
applied. If a mapping other than the default is needed, it is able to be edited at
any time with the XQuery dialog (Figure 4), invoked by the mapping button on
the mini-toolbar. This dialog has also been completely redesigned to remove the
unnecessary complexity of the original Editor’s dialog.
An even more complicated data
design exercise in the original Editor
was in the definition of XQuery pa-
rameters for multiple-instance tasks,
which served to inhibit the use of
multiple-instance tasks for all but the
most determined designers. In the
new Editor, the XQuery parameters
for multiple-instance tasks are also
automatically generated and applied
via drag and drop in the same dia-
log as single-instance tasks, making
the capabilities offered by multiple-
instance tasks available to expert and
novice user alike.
The definition of complex data
types using XML Schema can also Fig. 4. The XQuery Mapping Dialog
prove problematic for novice design-
ers. The new Editor will introduce a new, simplified data definition language,
loosely based on Pascal syntax, allowing for more easily expressed data type
definitions that will automatically be transformed to/from XML Schema, thus
providing two discrete, user-switchable views of the same type definitions (List-
ings 1.1 & 1.2).
Resource Perspective The ‘Wizard’ metaphor used by the original Editor
to capture resourcing requirements has proven less than effective in terms of
user interface design. In addition to being dated in terms of UI constructs, the
metaphor as deployed suffered from three main issues:
1. It was necessary to always begin at the first page and work your way through,
even if you wanted only to make a small change on the final page.
2. There was no facility to undo or cancel a change.
60
3. There is too much information displayed on each screen. While potentially
useful for novice users, the information becomes unwanted ‘noise’ as ex-
perience is gained. A better approach is to have the information available
separately through a ‘Help’ dialog that can be invoked via a button.
Listing 1.1. Type Definition Expressed as XML Schema (example)
Listing 1.2. The Same Type Definition expressed in Simplified DTD Syntax
t y p e BookOrder = r e c o r d {
title : string ;
p r i c e : double ;
inStock : boolean ;
}
t y p e B o o k L i s t = o r d e r ( 1 . . n ) o f BookOrder ;
All three concerns have been addressed in the new Editor through the use of
a tabbed dialog that shows the various resourcing properties, any of which can
be navigated to directly, with verbose help information removed to separately
invoked dialogs. Also, the new Editor will support the swim-lane metaphor,
allowing resources to be assigned to tasks graphically via their placement in the
appropriate lanes, which will aid in the readability of models by all stakeholders.
4 Conclusion
This paper briefly outlines a few of the main features of the new YAWL Editor,
however almost every aspect has been updated and improved. It is hoped that
the reward for the redesign will be realised through increased deployment of the
YAWL environment, and a positive affect on the teachability of YAWL, since
novice users will no longer face such a steep learning curve in the use of the
Editor before positive results can be achieved.
An alpha version is currently scheduled for limited release in August 2013.
References
1. B. Shneiderman, C. Plaisant, M. Cohen, and S. Jacobs. Designing the User Interface:
Strategies for Effective Human-Computer Interaction. Addison-Wesley, 5th edition,
2009.
61