MBUI Telecon 2012 November 15

From W3C Wiki

Scribed by Vivian, Paolo

Present

  • Vivian Motti
  • Nikolas Kaklanis
  • Paolo Bottoni
  • Heiko Braun
  • Jean Vanderdonckt
  • Jeremie Melchior
  • Nesrine Mezhoudi
  • Pascal Beaujeant
  • Jaroslav

Regrets

  • Fabio Paterno
  • Joelle Coutaz
  • Gaelle Calvary
  • Gerrit Meixner
  • Dave Raggett
  • Sebastian Feuerstack
  • Javier Rodríguez
  • Ignacio Marín
  • Cristina González

Scribe

  • Vivian Motti (please double check the minutes)
  • Paolo

Minutes

Due to the reduced number of groups present, the teleconference was mostly concerned with the discussion of the AUI model, but touched also upon the overall structure of the models. In particular, the discussion moved from the comments provided by Paolo on the figures produced by UCL, presenting some fragments of the metamodel.

  • Some agreement was reached on having a structuring of the notions defining Context in a separate package. Specific sub-packages of the context package can structure the notions relative to User, Platform, Device, etc.
  • Some agreement was reached on creating a package for the foundation of Behaviour, including the notions of Event, Condition, Action, Constraint (possibly Justification). Specific models could be used and integrated in the overall specification model, to adopt specific ways of describing / representing / specifying behaviours, e.g. finite state automata, Petri nets, action grammars, etc.
    • In this sense the classes for Condition and Action, where the attributes conditionExpression and actionExpression appear, should be complemented with an attribute expressionLanguage, to indicate according to which language the expression should be interpreted. It would be the responsibility of the modeler to make sure that tools supporting the adopted specification language are available and that the expression is correct with respect to the adopted language.
  • Some agreement has been reached that modeling of Behaviour can be relative to several aspects, e.g. task processes, domain operations, navigation in the interface, syntactic feedback or event propagation at the interface level. For example, one could require that the occurrence of some events be synchronised in multi-modal interfaces, or that several threads of interaction be closed when some event occurs, independently of the specific modality. A proposal has been made, to define packages for each such aspect. In any case, the specification of behaviours would be based on some realisation of the event-condition-action model.
  • Some agreement was reached
  • A side-discussion has started on whether a model of actions and behaviours as producers/consumers (or listeners/sender) of events should be adopted and incorporated in the AUI model, as proposed by Heiko. Paolo suggested that some common semantic model could be adopted, under which to interpret behaviours expressed through actions. However, this model would not be part of any specific component of the metamodel, but would constitute an external reference model. In particular, Paolo proposes a model of production/consumption of resources, events constituting specific types of resources. No specific conclusion was reached about this. Following the meeting Heiko and Paolo proposed fragments of metamodels to illustrate their views.

Paolo's proposal Heiko's proposal

  • Some agreement was reached on the need to relate the AbstractInteractionUnit to Behaviours originating on it or influencing it. Paolo proposed to reintegrate the notion of EventSupport discussed in Pisa, so that an AIU can support several events, which may in turn trigger some behaviour. As observed above, some of these events can affect navigation, some advancement of processes in some task, some modify features of the domain model, in general always activating some behaviour providing a syntactic feedback. It is possible that one event triggers several behaviours at once. The notion of event support might be defined by a specific class, with associations on the one side to the AIU supporting the event and on the other side to the activated event, or through associations directly linking the AIU to the events it supports. No final decision was reached about this. It has been recognised that, in any way, the relations realised by the notion of event support would be dynamic ones, so that some events might cease to be supported in specific situations or contexts.
  • As reference was made to synchronisation of events in multimodal interfaces, the question was raised whether multi-modality is addressed in the Use Cases and whether this specific aspect is covered. This has to be checked, but in anyway it is common knowledge that such situations arise.
  • Some questions concerning the coherence of the presentation of individual packages was discussed.
    • It has been accepted that the Model class can be referred in each package, without the need to reproduce its associations in the original UI Commons package, when these are not relevant to the specific package
    • The relation between the information about the model version and the versioned model should be revised, as it is not immediately apparent how one can identify which versions of individual models are composed in a version of the overall model.
    • The Mapping model should be completed.
    • The direction of inheritance appears reversed in the AUI model.

For all these items UCL will revise them, and progress with the production and integration of the remaining packages.


Updates on AUI document

  • The definition of Packages covers
    • Context (U, P, E)
    • Behavior Model (Domain, Task, JECA, condition-dependent)
    • Separate: Static vs. Dynamic
    • Levels
      • Task and Domain
      • ABSTRACT -> accommodate the behavior model
      • CONCRETE (-> could also accommodate the behavior model)
      • ...
  • Definition of constraints in the abstract interaction units (AIUs)
    • refer to them, constraints, ECA format
    • how to: define, express and validate the constraints
    • move to behavior package to modify and to specify the behavior description
    • must support different implementations
    • e.g. using petri nets or state models or grammars
    • Global Expressions
  • Autonomy across classes
  • AUI
    • satisfy constraints
    • behaviors that trigger events
    • could support classes and events
    • binding
  • AIU: is supported by events that are triggered by behaviors
  • Actions
    • navigation
    • domain
  • Class
    • Action, attributes, type
  • Need of a vocabulary for the behavior model
    • At both abstract and concrete levels
  • Language expressing: condition, expression, behavior
    • on model: create, update, delete, etc.
  • Expression vs. Interpretation
  • Conditions and actions, languages and approaches
    • 'what' must be expressed and represented in the model
    • but 'how' not necessarily
      • We should not commit to one language
      • e.g. with specific vocabularies or languages
  • Event support
      • a capability to express
  • Abstract: select and trigger
    • usage via behaviors?
    • e.g. on [data_selection] event
    • choice:
      • event as a class
      • or as association (type, support)
  • Concrete
    • clear ok
    • AUI support capability (input, select, etc)
    • addressing needs
    • Events support
      • consuming
      • producing
  • AI Model
    • who: creates, initializes and/or realizes a behavior
  • Classify actions
    • navigation (sub-set of actions)
    • call functions
    • satisfying constraints
  • AUI
    • listener vs. sender
    • consumer vs. producer
  • Production events: lead behaviors
    • modification
    • synchronization
  • Model Behavior
    • type
    • navigation
  • Behavior composed by
    • triggered events
    • conditions
  • Modelling AUI
    • describe events
    • trigger behaviors
  • Events support class AUI
    • association AUI and events
      • behavior defined independently
  • Behavior comes at the CUI level
  • Multi-modality covered
    • Separation
  • Do the UCs cover multi-modality?
  • Interaction requirements
  • Model
    • version
    • authors
    • co-existing model versions
    • history
  • in the configuration control model
  • Mapping Models
    • commons
    • main package diagram
  • not detailed definition so far...
  • add mapping model
  • In the specification of each package
    • AUI model and devices

Actions

  • ...

Decisions