MBUI WG Face to Face, Lyon 2012

From W3C Wiki
Jump to: navigation, search

The 3rd MBUI Face to Face meeting tooke place on 29-30 October 2012 as part of the W3C Technical Plenary in Lyon.


  • Heiko Braun
  • Sebastian Feuerstack
  • Dave Raggett
  • Marius Orfgen
  • Javier Rodrí­guez Escolar
  • Cristina Gonzalez Cachon
  • Gaelle Calvary
  • Joëlle Coutaz
  • Jean Vanderdonckt
  • Vivian Genaro Motti
  • Carmen Santoro
  • Nikolaos Kaklanis

Summary of discussions

We spent the first morning going through the proposed changes to the Introduction to Model-Based UI. Jean and Gerrit had added text which we refined, changing it from red (proposed) to black (accepted) text.

In the afternoon we focused on the meta-model for the abstract user interface. Vivian took notes on the changes we converged on. Jean and Vivian will work on updating the meta-model definition and description, and we will then review the revised document in an upcoming teleconference.

For the second morning, there were no further issues to discuss for the abstract UI specification until we have the revised draft. We therefore went back to the Introduction to MBUI. The section on adaptation is very detailed, and it was felt that this assumes too much prior knowledge of the field to be appropriate in an introduction to model-based UI for newcomers. Sebastian and others noted that they like the content, and agreed that it would be better in a separate document focusing on adaptation. We agreed to start a new Working Group Note on adaptation.

The discussion then moved to the purpose of the table and the use cases that follows. The existing table should be moved to the adaptation document. We then worked on a new table as an overview of the use cases, and reviewed each of the use cases in turn.

We then switched to discussing the new document on user modelling by Nikolaos. Should we also work on modelling other aspects of the context of use?

Joëlle noted that for the run time, not everything can be generated from the high level models. In other words, some aspects of the design have to be done at a lower level close to the final UI.

Gaelle asked whether we should consider work on a quality meta-model as a means of assessing the quality of transformations.

Sebastian asked Dave to explain the roadmap for the standardization process. Dave explained how we are working toward stable specifications as Last Call Working Drafts, and then working towards Candidate Recommendations together with interoperability testing.

Heiko expressed his concerns that we need to limit the scope of the specifications clearly. Perhaps we should look back at the aims expressed in the working group charter? Dave notes that we should look carefully at the revised AUI specification when the current edits have been applied, and to then see where we could usefully limit the scope. Heiko is concerned that the current AUI meta model is rather complex and simplifying it would broaden its appeal.

Notes taken by Vivian

  • Introduction Document
  • AUI model


  • more details for figure 2 (CIM, PIM, PSM)
  • better definition of the impact and influence of the context in all Cameleon levels
  • review of all benefits for different perspectives (removing duplicated contents, refining definitions)
  • ISO 9241 210 human-centered design (110)
  • definition of a step-wise development life cycle does not imply in a waterfall approach
  • discussions: design vs. run time for code generation
  • reinforcement of creativity by means of design spaces (alternative designs for multi-modalities)
  • error reduction (apply for different perspectives of benefits: 1,2…)

TO DO (Jean):

  • include Gartner reference on reducing error rates (a qualitative summary and some figures, +reference)
  • benefits of MUID at run time
  • responsive design -> not only cosmetic changes (all core transformations)
  • benefits of supporting method engineering

Afternoon session

  • Why vs. When session (later to be incorporated in the former)
  • Common generic requirements
  • Configuration control establishes the management over time
  • Mapping vs. transformations
  • Composition of the UI model (packages for task, domain, CoU, UM, AUI…)
  • TODO (Jean): re-name configuration control model to configuration model
  • TODO (Jean): re-name author to agent
  • Entity at the mapping package
  • UI commons
  • Behavior to be connected with the AIU by reference
  • JECA (behavior) refers to AIU
  • Expressive but not rigorous
  • Separation of concerns though
  • OCL for constraints?
  • Between objects and rangings
  • Window
  • Trigger? Through which interaction unit
  • Method call function
  • Wizard
  • Static vs. Dynamic concern (to be also expressed by the new CRF)
  • Task model
  • Defining mapping and behavior
  • Relation with AIU and its behavior
  • Each entity can have a behavior
  • Everything mappings while designing behavior
  • TODO (Jean): expression of behaviors at CUI level considering JECA, by means of classes and supperclasses and subclasses
  • Binding at run time
  • Separation of the abstract in a external model
  • Entity behavior is abstract and generic (general classes)
  • DRY principle (respect)
  • Cameleon reference framework update: Static x Dynamic behavior
  • Do not specify the dynamics for all the levels
  • Behavior ranges
  • Across elements
  • Within elements
  • Definition of constraints
  • Events
  • Behaviors
  • Semantics of the meta model (not syntactic)
  • TODO (Jean): bi-directional model, feature, specification (synchronize docs)
  • Users do not necessarily need to access, see, the code

Quill presented

  • Models
  • Web based
  • Collaborative
  • AUI relationships between dialog
  • Voroni diagrams for separating branches of tree-like models
  • Different windows
  • Look for referece: the physics of notation, by Daniel moody

AUI meta-model:

  • ranging: min max behavior
  • solve level granularity
  • TODO (Jean): behavioral model spans across different levels

meta model properties: inherits from experience with XFORMS for forms

  • constraint class
  • dynamic navigation

see paper on AdapForms (Bohoj) ICWE 2011

  • support adaptation of contents
  • 0..* in the composition AIU relationship in the AUI model
  • trigger expression either via navigation or function call
  • intentional vs. extensional approaches
  • isTriggerable?
  • This AUI should have the capability to do so…
  • Constraints
  • Existency
  • Unicity
  • Dependency

TODO (Jean): move default value to AIU

  • Constraint to DIO and data selection
  • Link constraint to AIU

TODO (Jean): remove prefix from all definitions (e.g. constraint)

  • Default value either user defined or system defined
  • Model to UI model
  • Task taxonomy
  • Data browsing
  • Avoid proliferation of task types
  • Only most used cases are covered
  • And provide feedback/output for the user
  • Control triggering
  • Grouping and visualization
  • Oasis group: containing and component (but covers just CUI)
  • Support of comparison in the AUI
  • Define AIU and its specific properties
  • And the navigation between them
  • Not only for the AUI: templates propagated or not
  • Superseded creating another instance
  • Templates duplicated and modified
  • Propagation
  • Composition
  • Master detail view
  • AIU and templates: either overwriting or superseding
  • Keep open capability to do so
  • With propagation: minimum
  • 2 cases
  • reference (with or without DEFAULT)
  • copy (edit or modify)
  • design time vs. run time
  • session level
  • template for any UI model
  • model entry: copy and paste
  • behavioral level
  • trigger or not
  • depending on the configuration
  • localization (yes or no)
  • e.x. 4 languages per label specification
  • isContextualizable?
  • Already convey by the relationship
  • Refer to the respective context model

TODO (Jean): remove the class to avoid redundancy

  • The contextualization is ensured by a relationship with the context model
  • Documentation for the models
  • Output
  • Input
  • Information that is expected
  • Express help needs to complete the definitions of a AIU (e.g. tooltip, bottom line messages)
  • have 2 data input and output separated (Sebastian)
  • label data input
  • security level
  • feature of the localization
  • “everything can change depending on the context value ”
  • run time
  • association class between 2 classes
  • 0..* different contextualization
  • decoration for attributes that are context-specific
  • for small devices
  • not the same AIU
  • removing details
  • annotate AIU
  • implementation: dynamic at run time
  • depends on the frequency and centrality of the tasks
  • load state machine
  • depends on how much adaptation you support at run time
  • designer: anticipates that
  • templates as solutions
  • data filter
  • type (mutually exclusive, inclusive, joint)
  • operator: and, or, xor
  • condition
  • property
  • in terms of the behavior of the model
  • ECA
  • Filter implemented through behaviors
  • Parameters of the behavior
  • Modality dependency?
  • Several formats for information
  • Dynamic queries
  • Fill displays by scheneidermann
  • Pagination vs. interaction unit behavior
  • Error management relation
  • Input constraint
  • Solution of the problem (e.g. springer link)
  • CARF properties in the composition class
  • Mapping class across levels
  • Mapping meta model
  • Security
  • Captcha
  • Secret
  • AIU
  • Data input output
  • TODO (Jean): Transfer the attribute
  • And change the name: secret level: hide, blur, …
  • Level: 1,2,3
  • Authentication
  • CARE properties
  • UI commons
  • Security
  • Secret
  • Secrecy level
  • Quality?