MBUI F2F Pisa 14-15 June 2012 Vivian

From W3C Wiki

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

http://www.serenoa-fp7.eu/casfe2012/

Retrieved from "https://www.w3.org/wiki/index.php?title=MBUI_F2F_Pisa_14-15_June_2012_Vivian&oldid=59825"