MBUI F2F Pisa 14-15 June 2012 Vivian
This is a first draft version: please feel free to refine its contents
W3C MBUI WG 2nd face-to-face meeting
Presents: Davide (CNR), Carmen (CNR), Javier (TID), Cristina (CTIC), Nacho (CTIC), Joelle (Grenoble), Gaelle (Grenoble), Sebastian (UFSCar), Marius (DFKI), Sascha (UCL), François (UCL), Vivian (UCL), Nikolaos (CERTH-ITI), Fabio (CNR)
Chair: Dave (W3C)
Remote: Jaroslav (Bonn)
Presentation Introduction Practicalities
- Use Cases discussion: suggestion to group the scenarios (because they are overlapping which can be good or not)
- Suggestions for metrics and features
- How the UC support context information and adaptation
- How user can control (automation vs. control)
- Expert system to support transformation between levels and guidance on best practices
- Recovery granularity
- Adaptation means: migrating / distribution vs. re-molding (shape change)
A table is created to relate use cases and its ‘requirements’ according to their relevance The terms defined in the table are specified in the glossary, the scale adopted is explained
Jaroslav highlights the importance of maintaining some consistency in the level of details for the UC descriptions
Glossary: some discussion about the terms and refining their definitions for the final version of the document
- Task model: representation of the class diagram, temporal operators (sufficiently expressed) except parallel and interleaved, opt to add it to the table
- Depending on the context a task may be central, more or less important
- Discussions about terminology (e.g. object vs. domain object), temporal relations, abstract specifications vs. actual instantiations;
Define: generic vs. specific requirements (e.g. retrieving the current state of the system regarding tasks’ status)
How to express the migration of a task from one platform to another?
Task relates to context of use (including platform specifications)
Definition of subtasks as heterogeneous instantiations of the abstract definition of task Intentional vs. extensional definitions concerning enumeration and task types
Addition of enumeration
Abstraction to abstract_task
Operator as an associative task from task to subtask
Pre-conditions vs. post-conditions
The object defined in the ConditionLiteral can be related with the Object class (or DomainConcept as Joelle calls)
Extensible list for the types (read as selection is a type of interaction)
Is it considering: stretching, orienting, …?
Control: to trigger something (invoking some method) Editing: to change something
Task type: extensible (e.g. path)
Extensibility (by built-in) vs. coverage
Keep core based concepts (common)
Adding an attribute (e.g. name) to instantiate task type (no more abstract class) to support extensibility Add name but also a property to define it (like an enumeration)
OCL constraints
New proposal by Paolo defining Actor (User, System, Interaction and Abstract) as responsible for the Task (Type, Selection, Feedback)
One week to generate the new version of the Task Model Diagram by CNR And cleaning the document to have a refined version that is more readable
By the end of this month: to reach a stable version for publication
Reviewing the document
To provide: a brief textual description explaining relationships and further UML notations
Cross-checking the glossary terms and the documents
Jaroslav suggests further explanations regarding terms that are not ‘self-explanatory’
Lunch
Picture
- Task types discussion: selection (one or more out of many);
- Definition of modality (multimodality: as input and interaction)
- Terms: grouping and order, visualize
- System vs. selection task
- Schneiderman ‘visual information seeking mantra’ zoom, filter… visualization of complex information
Try to keep the consistency with the definitions while describing the user cases
Visualization x information discovery x clustering
- Discuss stylistics like frequency that is not observable
- Make it graphically explicitly or add annexes (preferable)
- Keep the task tree
E.g. discovery knowledge
Concrete example of fish eye, magic lenses, overview + details Inspiration from Schneiderman regarding task type classification
conclude task model discussion
AUI model
- Generic requirements: consistency
- SotA
- AIM: continuous vs. discrete as a way of interaction (e.g. light)
- Internationalization: AUI or CUI? AUI as an attribute (mark the support), modality independent (icons, long/short labels…)
- Having (at least) one attribute to specify the language (and other cultural aspects too…)
Definition of behavior: in terms of event, condition and actions (interaction)
Definition of the association between AUI and CUI: does ‘everything’ need to be supported? (some concepts are modality-dependent)
Different approaches can be considered to support additional modalities
Importance level may guide to CUI decisions
Security mechanism: password x authenticity
AIU cannot be instantiated directly
Hierarchical level
Add an attribute to define the granularity level (like a tooltip)
Directly observable depending on the context of use
Self-contained meta-model vs. associations task model and AUI model
Demos:
- Maria
- Self-contained issue too
- Quill
- Control-point for the end user
- UsiCompose
15/06/2012
Brainstorm session on AUI