- Fabio Paternò
- Dave Raggett
- Heiko Braun
- Joelle Coutaz
- Davide Spano
- Carmen Santoro
- Jean Vanderdonckt
- Jaroslav Pullmann
- Nikolas Kaklanis
- Fabio Paternò
- Paolo Bottoni
- Gaelle Calvary
- Pascal Beaujeant
add yourself if your name is missing and you were on the call
- Gerrit Meixner
- Dave Raggett
Heiko: Paolo made some revisions to the AUI meta-model diagrams and added event support into the AUIUnit. I've uploaded them to:
It's a VPP 10 format. Please let us know if this causes problem for you. In any case, we've exported the images as well:
Paolo explains the changes that were made and asks for any observations.
Fabio: which part is the connection to behaviour?
Paolo: through the trigger event.
Fabio: an event trigger some action but I am not sure how this is represented?
Paolo: we are not representing the behaviours in detail, we have some broad categories and this can be subclassed as needed.
If we are more specific, we would overly constrain what kinds of models are possible. I don't think we should do that.
Fabio asks Jan for comments.
Jan: we are still considering it - questions of expressivity and representation.
The representation class seems to be an abstract class, is that right?
Jan: perhaps we should be using inheritance to simplify things? This might involve multiple inheritance, e.g. from eventSupport and presentationSupport.
Paolo: yes that could be a problem. Enumeration is an alternative.
Jan: presentationSupport is too concrete, perhaps we could come up with a better name?
Jan: we need to think about this some more to consider the implications of this new structure and then to reflect the changes back in the main diagram and put it online.
Some discussion about the event hierarchy. Could this be simplified, for example by having a property indicating the type of event and other properties depending on that. Not all attributes would be applicable to all event types.
Use cases in introductory document
Gaelle: do we agree on switching to a single example throughout?
The suggestion is to use the car rental example to illustrate different aspects of model-based UI design.
Jan notes that in section 3.2, ??? should be removed
Fabio: I think we need more concrete examples.
Jan: so you prefer to have a comprehensive description of each use case in one place. Then to provide an account of how the model supports specific aspects of MBUI throughout the document.
Jan: we would provide links to the model browser rather then embedding lots of diagrams.
Fabio: what actions are needed?
Gaelle: the Grenoble team will refine the document and then invite everyone to review, okay?
Gaelle: we just need the detailed car rental example.
Jan: The model browser (he calls it a voyager) for the car rental example can be found at http://www.fabiennemineur.be/tree
We can put other examples online very quickly. You can view the task, abstract and concrete UIs.
after some discussion, Jan says that there could be multiple AUI's per task model.
Fabio: not sure ...
Jaroslav: what about providing a context selector for different users, different devices and show how this is reflected?
Jan: excellent feedback, for now it is a hierarchy, we could add a list box for this.
Jaroslav: this would be showing the added value of the model-based approach
Fabio: to summarise: we will different use cases for each context and put them in an appendix. In addition we will link to Jan's model browser.
The appendix could get pretty long, but that's not a real problem.