MBUI Telecon 2012 September 20
Chaired by: Gerrit, scribed by Dave
Present
- Dave Raggett, W3C
- Carmen Santoro, ISTI
- Davide Spano, ISTI
- Gaelle Calvary, LIG
- Javoslav Pullman, Fraunhofer
- Nikolas Kaklanis, ITI
- Paolo Bottini, University of Rome
- Jean Vanderdonckt
- Vivian Motti, UCL
- Pascal Beaujeant, UCL
- Sebastian Feuerstack, USC
- Cristina Cachon, CTIC
- Javier Rodriguez, CTIC
- Ignacio Marin, CTIC
Regrets
- Joelle Coutaz, LIG
- Fabio Paterno, ISTI
Planned Agenda
- Current status of the Abstract UI document
- Current status of the working group note
- Next F2F meeting @ TPAC 2012 in Lyon
Jaroslav: I am seeking funds for attending Lyon F2F. My preference is for the two days. Sorry, but I have to leave early today.
Current status of the Abstract UI document
Jean: one question. In the CTT document(?) this is a list of task types. What would be the best moment to merge lists? The goal is to complete the list of task types.
Davide: we can consider to update the list.
Jean: this wouldn't change the meta model, only the list of task types.
Carmen: we can update the WD, right?
Dave: yes, we can do that at any time we need.
Davide: the best thing to do is to send an email with the task types you want to add and we can then discuss this, before adding them to the WD.
Jean: okay I will do that.
Jean: I would like to include the requirements and to state how it has been satisified?
Gaelle: this is a justification for the metamodel, right?
Jean: ...
Sebastian: it is a sort of refinement of a general requirement, right?
Carmen: we could provide some concepts relating to validation, perhaps at the end of the document where we could indicate which of the requirements have been satisfied, but not a strict validation
Jean: I like this idea, does it make sense to everyone?
several people say yes.
Gaelle: it should be a systematic approach, yes?
Carmen: yes, although these are generic requirements and each document can instantiate their meaning.
Jean: one example requirement is separating structure from behaviour.
Jean: The new meta model is introduced in the middle of the document, any comments on the new version?
Paolo: I was proposing a different way that doesn't use the composite pattern in the original way, and could take into account dynamic revisions
Jean: I didn't have a chance to read your email this morning
Carmen: We found the new meta model in the Google Doc clearer that the previous one.
Paolo: last week there was an issue on allowing for some sort of dynamicity. The other choice is to make composition as an entity, but I am okay.
Paolo's email on compound AUI:
Jean: what happens if we have other relationships? If we want to qualify something about the composition class, could we add this as an attribute?
Jean: your proposal is better than the one we discussed last week, but I am not sure how to pick between the various proposals we've heard.
Gaelle: one question, for me composition is an abstract interaction unit, why didn't you consider that?
Paulo talks through the model.
This proposal allows composite to be mapped into elementary and vice versa.
Davide: not sure how useful that is. I think the meta-model should allow for interaction units that cannot be further decomposed. If you use the type attribute you can avoid putting let's say a group as a child of a text input.
Davide: we already agreed that the AUI should be able to cover all the CUIs of interest.
Gaelle: please repeat the example
Davide: let's consider HTML5, we should represent constraints on what elements can be contained by others. You can not include content in empty HTML elements, for example.
Paolo: this is more a matter of the transformation from the abstract to the concrete level, where you will need to determine whether a simple or compound CUI component is required.
Jean: I agree that the AUI should express everything we want, but the mapping to the CUI will deal with the constraints.
Davide: there should be some constraints at the AUI level, e.g. that a given AUI component is atomic and cannot be decomposed.
Paolo: I'm not sure we can say this.
Jean: trying to summarise. if we consider the solution in the editor's draft, we think the input/output should be strict. In Paolo's model there is no distinction between composite and elementary. (scribe failed to capture everything)
Davide: prefer to keep the elementary interaction unit as I think this will be clearer.
Gaelle: Paolo's version allows you to make relations explicit.
Carmen explains why she finds the new model in the editor's draft clearer.
Davide: we are discussing types not instances
[scribe missed subsequent discussion]
Carmen: selection as an example of an atomic goal, it is not decomposable.
Jean: we should clarify the two proposals and relate them to examples.
Dave: we need to come up with some examples to compare and contrast the two approaches.
Sebastian: can Jean please explain data input output?
Jean: the goal of that is to support input and output at the same time.
Davide: we think there is a need for an interactor devoted only for the output.
DataInputOutPut should be a subclass.
Paolo: prefer the UsiXML, I generally prefer composition to subclassing.
Dave: is there any impact on how easy it is for people to learn and understand AUI models?
Jean: interested in the groups opinion on the new entity model, any reaction or comments?
No comments. Everyone seems happy.
Current status of the working group note
Not covered in this call.
Next F2F meeting @ TPAC 2012 in Lyon
The poll results for the time slots can be viewed at
This seems to justify having a two day meeting and adjusting the agenda to work around those who are absent at either the first morning or last afternoon.