Interaction Space (IX)

Origin

The Interaction Space (IX) is originated from the gathering of interaction spaces (now referenced as Interaction Components) generated from the application of the WISDOM

Software Architectural Technique to the User Intentions of a given UT. This led to the

establishment of a Model-Driven Architecture, the Hydra Framework [Costa et al., 2007], for User Interface development, which implemented the interaction spaces clustering using Aggregation Spaces (AS). With the formalization GOALS, the IX is structurally defined as the space of communication between two or more UTs that happen in the same (physical or electronic) space, where the same Business Rules (BR) and Data Entities (DE) are used. It reflects the relation of the customer with the enterprise, in the same way that in the DEMO method, the initiator and the executer participate in a transaction subject to Action Rules and using Object Classes. The IX was identified as the solution to represent physical and electronic spaces and as a basis for the User Interface development. The Lines of Visibility and Interaction which are presented in Section 4.3.1.1. Step 1 - Service Design, may also be considered as Interaction Spaces that include BPs, DEs and actors.

Definition

The original IX definition is derived from the WISDOM concept of interaction space, as a User Interface space where the “User Interacts with Functions, Containers and Information in order

to Carry On a Task” [Nunes, 2001]. We adapt this concept to the enterprise context by means

of its generalization in order to complementarily consider the support of the UT in person, as in any of the cases the same BRs and DEs apply. Hence, we redefine the IX as “The Space that

Supports a UT” (with the same BRs and DEs). One IX supports the interaction of two or more

users in person or remotely while each one carries on his own UT. If two actors carry on the same UT remotely, then they are necessarily performing cooperative work [Grudin, 1994].

Meta-Model and Example

The meta-model presented in Figure 16 defines that one IX can support one to many UTs. The IX uses and includes BRs, and can also directly use and include a DE if no BRs are identified to apply in that IX. In the example, the identification of IX is architecturally deduced from the relation of UTs. They are the space that supports the interaction of two or more actors. The IX supports the application of BRs that apply over DEs, defining the IX Logic that “builds-up” the Enterprise Structure. The relation of IX to UTs, BRs or DEs, can be expressed along with the BP design, or by means of an integrated representation of the BP design where the physical space of the IX is represented, allowing the communications of more than two actors per business transaction, as will be presented in Section 4.3.1.3. Step 3 - Enterprise Structuring.

Figure 16. Meta-Model and Derivation of IXs from UTs and relation to BRs and DEs.

The example shows the derivation of IXs in order to support the interaction between Actors “A” and “B”, and “B” and “C”, by means of IX “A” (a Request) and “B” (a Coordination) respectively, which is possible since the UTs “A”, “B”, “D” and “E” are subject to the same BRs and DEs, and the same happens in the case of UTs “B”, “C” and “D”, except that UT “C” is not subject to BR “B” in order to access DE “B”. If another interaction between Actors “A” and “B” would occur (e.g. between User Task “E” and “F”), then again, the same or a new IX may be defined (e.g. “C”) in order to support that interaction, depending on the business conceptual idea.

Semiotic Structure

The IX grants the user control over information, respecting existing paradigmatic and the

syntactic relations. Information should be presented using syntagmatic (historical) information,

from which the user can withdraw knowledge in order to apply the enterprise principles and fulfill his task applying wisdom. For example, the IX can enable the possibility of proceeding with a person’s registration, presenting that person’s registrations from the past, and eventually outcomes of registrations from others to facilitate user decision.

Meaning to the SDP

The IX represents a logic that that aims user performance and software development efficiency by means of believing that the most productive way of working for the user is giving him a User Interface that facilitates his task in terms of data and tool availability. In other words, if all the needed data and tools are always available (or always when needed), navigation is reduced, and also the mental effort of maintaining variables that concern the task execution. It induces the reduction of the articulatory distance of the UT i.e. the user’s physical interaction with the User Interface [Winckler et al., 2015], and suggests the composition of the User Interface in such a way that the user has a clue of what each concept means, which is possible since the design is based on what are the User Intentions and User Interactions when dealing with a UT in a given system state. It also suggests locating the components by the highest affinity possible, and using as little implementation space as possible in order to raise the probability of reducing implementation objects and therefore reducing implementation effort. It can be observed as a technology-ecologic approach, that aims giving the user what he needs when he needs, using an adequate, instead of an over-worked solution.