In the abstract user interface we define construct elements, API calls and user interface behaviour. Similar to UsiXML, we use events and event lis- teners to model the behaviour of construct elements. Events are raised by construct elements to denote an action of a user and raised by function calls to denote the result of an interaction with the system. This approach is illustrated in Figure 5.1.
Events raises Construct Elements listens to initiates changes state of Event Listeners raises API Calls
Figure 5.1: Conceptual overview of defining behaviour of the abstract user interface withEventListeners
5.2.1
Abstract Construct Elements
Containers, Triggers, Lists, Input and Output objects form the elementary objects of this model and provide the structure and the tools such that the user can perform the specified tasks. We call these objects, AbstractUser- Interactors (AUIs). AContainergroups a distinct set of AUIs such that the accessibility of these elements can be toggled. ATriggerdefines an atomic action of the user to, for example, confirm, reset, or start a task. AList
enables the user to perceive a structured set of information and to select a single or multiple items of that list. AnInputobject enables the user to input or to manipulate information. AnOutputobject specifies that infor- mation has be communicated to the user.
The concept of abstract construct elements and their characteristics is easier to grasp if we project these elements on a specific platform and modality. For example, a typical GUI consists of a form that enables the user to in- put and to manipulate data. An instance of an abstract user interface that models such a form can be defined as a Container that contains Input, Out- put, List and Trigger elements. When we project this structure onto a GUI, the Input elements will be transformed into a text field, an integer field or another field that enables the user to provide information. Output ele- ments will be transformed into text, a graphic or different form of output. Lists will be transformed into dropdown elements that enables the user to choose a value. Triggers will be transformed into buttons such that the user can confirm or reset the information.
5.2.2
Events
We define two types of events: internal and external events. Internal events denote a state change of a construct element. External events denote the result of an API call.
Internal events
The different states and transitions of an abstract construct element can be defined in an abstract state machine∗. Such a state machine denotes which transitions can be triggered in which state. Both the user as well as the user interface can trigger these transitions. An event is raised when the state of an AUI element changes. The behaviour of each AUI is defined in a separate state machine. Therefore, we can customise the behaviour of the same AUI with a different behaviour. An example of two state machines for the same AUI is illustrated in Figure 5.2.
sh start sa sd enable hide trigger disable enable (a)triggerdoes not change the state
sh start sa sd
enable
hide
trigger
enable (b)triggerchanges the state intosd
Figure 5.2: Two different state machines of the abstract construct element
Trigger
The state machine in Figure 5.2a describes the behaviour of a Trigger ele- ment with 3 different states: Hidden(sh),Accessible (sa) andDisabled(sd).
Only in the Accessible state, the user can trigger the Trigger event. Fig- ure 5.2b defines the same Trigger element, but when the user triggers the
trigger transition , the state of the element will change into the statedisabled. In this case, the user can only trigger the Trigger once. This can be usefull when a user has to confirm information. Another use-case is to change the start state in, for example, the disabled state. The user interface can com- municate to the user that the possibility exists but the user can not trigger the Trigger, yet.
Using this separate state machine we can customise the behaviour of the AUI elements and express design choices at this level in the transformation chain.
∗
Not to be confused with ASM’s as a method for the design and analysis of complex systems
External events
In our approach we define system calls asynchronous by definition. As a result, an external event denotes the start and finish of a function call. When the function call returns a result, an event is raised. When the func- tion call is not successful, the user interface can react on this event by show- ing feedback, or by aborting the task.
5.2.3
Event Listener
The event listener approach is used to define inter-element behaviour. The event listener as a concept listens to events and can act upon events by changing the state of construct elements and send an request to the system. The collection of event listeners forms the orchestrator of the user interface. It defines the behaviour of the user interface based on transitions of AUI elements and the result of function calls.