2012-02-10 AUI workshop
(Redirected from 2012-02-10 MBUI Benefits)
- Minutes MBUIWG on AUI workshop (morning 10/02/2012)
- List of Participants: Ran Zhang, Moritz Kuemmerling, Marc Seissler, Kai Breiner, Jaroslav Pullmann (Fraunhofer FIT), François Beuvens, Davide Spano, Javier Rodriguez, Nikolaos Kaklanis, Annerose Braune, Dave Raggett, Marius Orfgen
- Remote Participants: Gaelle Calvary, Ignacio Marin, Cristina Gonzalez, Jan Van den Bergh, Sebastian Feuerstack
- First round on the different features for each language and how they address the AUI
- UseML
- Core component = Dialog, Structure, Behavior
- Behavior is event-based
- Structure parts may be overwritten by other parts
- Navigation aspects are very important (relative or absolute)
- Static and dynamic concerns are well separated with Structure and Behavior entities
- Two parts in the comparison table: for the structure (static part) and for the behavior (dynamic part)
- Example: ComboBox (at CUI) would be abstracted in a Select
- All the different parameters (Container, Input, Output, Change, Select and Trigger) should be considered in the comparison table
- The categories of structures remain simple >< in UsiXML many specifications are defined like Rating refining a Select
- Discussion about how to model input/output as a single entity or by grouping input and output
- Expression of external data is not defined
- Importance of a link to an external system, or external data source --> concept of "data binding"
- Restructure allows restructure elements from the structure. e.g. adding a new element at runtime -> may be viewed as a kind of adaptation rule
- For adaptation we should consider Restructure concept
- In ECA rule, one particular type of action could be restructure
- Reusable behavior: a rule is defined one time and may be reused afterwards
- Importance of constraint expressivity: see XForms and Taxonomy of integrity constraints
- At what level should be expressed the constraints?
- Distinction between domain-oriented constraints and domain-independent constraints
- Access rights, security-based mechanisms
- Definition of these concepts could be realized by roles and rights on these roles
- Security access should remain optional, we can't enforce model the entire world!
- Importance of providing access points in the model to plug other parts like adaptation
- How to combine different features such as navigation/operation?
- IdealXML
- Focused on CUI
- No specific requirements
- In the table, we could have AUI elements first, but CUI elements too in order to get the correspondence (adding a new column)
- CUI DSL of University of Dresden
- Add another column to CUI to have the correspondence with AUI (as for IdealXML)
- MariaXML
- Behavior part has 2 levels: dialog and event handlers
- Expression of the dialog in a global way and in a local way
- Data Model is expressed through .xsd definition -> allows to communicate with external data source
- Categorization of groups
- Composite Description describes content as images, videos, … -> distinction from interactors
- How do we express the distinction between interactive parts and non-interactive parts?
- Importance of the simplicity of the language, trying not to lose usability
- Events coming from users
- .xsd expressivity may be limited at some point
- UseML
- Discussions with remote participants
- Inputs from Sebastian Feuerstack
- How do we clearly define the Dialog at AUI regarding the CUI
- May Dialog be viewed as the Behavior? Are they related concepts?
- How to express the Distribution at abstract level
- How do we express local dialog vs global dialog?
- How to address the minimal requirements for the dialog depending on the modality? What is the default behavior?
- General discussions
- What are the possible paths according the Cameleon Reference Framework (e.g. one task to many auis, reflection, etc.)
- Concepts should be first defined and then discussed how to use them afterwards
- Concept of containers that can be split (very useful for adaptation to different screen sizes as mobile, tablets, desktop, etc.)
- Concept of goals expressing how elaborated should be a UI depending on the constraints (e.g. size constraints)
- We should add in the comparison table a CUI with modality different from graphical
- Inputs from Jan Van den Bergh
- splitability of containers
- domain-oriented dependencies
- use of UML stereotypes
- Multi-types approach: instead of hierarchies of types, we work on a partition of types
- Canonical prototypes (Q. Limburg)
- Delegating as much as possible specific attributes
- Extensibilty of the template approach, for redefinition of common parts
- Inputs from Gaelle Calvary
- How do we capture exceptional scenarios, especially depending on error
- How to support the CARE properties (especially if we target multi-context)
- How to group things and what kind of grouping (semantically, …) e.g., tasks oriented, or based on common factors
- Inputs from Ignacio Marin
- The link with use cases is very important
- The use cases can useful for 2 things: to know what we want to achieve, but also to limit our expressivity
- Inputs from Sebastian Feuerstack