Re: Current thoughts and doubts

Dear group,

Gerrit does bring up an important point, but like Paolo, I don't think the discussions of the last few weeks have been misleading. But I am very much in favour of a reduced and comprehensible AUI model. Most of the concepts we've put into place already require in depth explanations between expert group members. IMO this is a really bad sign.

A goal for the first release could be the structural aspects, the behaviour model and the relationship between two. With regard to this, I completely agree with Paolo. Although it might be necessary to refer to other models (security, user, etc), a blackbox approach would be sufficient at this time.

In terms of the level of detail, I would prefer as little attributes as possible, ideally none at all. I think it's more important to get the high level concepts right, before diving into the details. I agree with Gerrit in that we've put too much second guessing into the current model.

Furthermore I get the impression we've compromised clarity for brevity. In order to reduce the number of elements, we've collapsed some of the concepts. This sometimes blurs the intention of the model elements in the first place. I would suggest to revisit the Useware model. It's a  good example of less ambiguous elements that don't necessarily require a textual explanation of their purpose.  

Certainly beneficial would be a specification for AUI model extensions. This would allow us to work towards a first release and improve in subsequent iterations using the mechanism we put into place. 

The specification remains questionable if not verified through use cases. I don't believe this can be retrofitted later on. It needs to be part of the release procedure for any document (draft) we consider a milestone. This would require us to pick a small number of use cases, that are realistic to manage, but yet provide a good coverage of the concepts and semantics we have. 


Regards, Heiko


On Nov 26, 2012, at 11:22 PM, Paolo Bottoni <bottoni@di.uniroma1.it> wrote:

> Dear all,
> 
>  
> I think Gerrit is right that we have to stay focused on the objective of providing a clean and simple meta-model for the AUI, as well as for the other components of the standard. However, I do not feel that the discussion of the last two weeks was straying from this line.
> 
>  
> I think the focus is actually on what must go in the metamodel of the AUI, i.e. those concepts which refer to the abstract notion of interaction unit, and what must go in different places, for example a comprehensive metamodel of behaviour, which can be reused in several places, and which is not a component of the AUI metamodel. 
> 
> In this direction, we were thinking of how can one specify behaviours, and we seem to agree on the use of a common formalism of type Event-Condition-Action, and how interaction units are connected to behaviours. This connection should be in two directions. On the one hand, interaction units can trigger events, (and in this sense they provide some support for event generation), on the other hand, the consequences of the behaviour have to be represented in some form through the unit). 
> 
> Hence, we should define how to establish this connection. This can be done in three ways (I will exemplify with respect to the event generation case): by directly defining the interaction unit as the generator / producer / sender of the event, by associating the unit to the events, by introducing a specific concept of event support, associated with events, as was proposed in Pisa. For the representation of consequences the same alternatives occur. Of course, these should be adopted in pairs in a consistent way. 
> 
> So, if we all agree on this view, it is a matter of convenience (and possibly of scientific and pragmatic investigation) which alternative to adopt. I prefer the third option (explicit event support), but I can also live with the association, as both allow for flexible associations of units with events, while for the first option (units as producers of events) I find that it might incur in a rigid structure, and one that might meet with fewer implementations. 
> 
>  
> All of this derives from the fact that the current version of the metamodel, in the document as it was last week did not provide any way to relate an interaction unit to a behaviour specification (they were just seen as two different types of components of the AUI metamodel, without any connection between them). I think everybody will agree that this is a serious limitation of the current model, and this is why we were discussing the best way to overcome this.
> 
>  
> The other thing that was discussed was, admittedly, one with minor direct impact on the metamodel, as it concerned the idea whether to have a very generic notion of behaviour, to provide a basic semantics for actions, and for the different types of behaviours one can have to model (task-related processes, navigation, data transformations at the domain level, or syntactic feedback). This is where different proposals have been presented. Depending on the adopted model of behaviour, the connection with the interaction unit will occur through some specific component of this. Even if this might seem a fine issue, it would provide a basis for reasoning at the abstract level, which should provide several benefits, so that one should not think of a specific way of expressing behaviour for each different type.
> 
>  
> Finally, the model of interaction unit should be separated by the model of the behaviour, and this is a matter of cleanness, not so much a research theme, and we should provide for the possibility that an interaction unit provides support to several behaviours, possibly connected with one another.
> 
>  
> 
> 
> Hope this helps clarify the matter
> 
> 
> 
> best
> 
> paolo
> 
> 
> 2012/11/26 Gerrit Meixner <Gerrit.Meixner@dfki.de>
> Dear colleague,
> 
> after our last telco I took some time to think about the current situation
> in our working group and the current draft documents. In the last telco
> several members (e.g., Joelle, Gaelle, Fabio) expressed that they could not
> fully follow the current discussions concerning the meta-model for the AUI
> specification. Therefore I started a discussion with Fabio (as co-chair) and
> Dave (as W3C contact) at the end of last week. Here're our thoughts.
> 
> We think that we're running too much into scientific discussions with only
> little practical relevance. In the last telco we had in-depth scientific
> discussions concerning the AUI meta-model. It seems to be that the AUI
> meta-model is now getting too complex rather than to be easily useful for
> industrial companies. We have to distinguish between scientific work and
> work for practical standardization. It would be better to have a clean AUI
> meta-model, understandable, focused on the AUI concepts, without introducing
> too many additional things related to other models or issues. Furthermore
> the goal of our charter is to develop a standard that can be readily
> exploited by industry for interchange of UI designs between different
> editing tools (http://www.w3.org/2011/01/mbui-wg-charter). An overly complex
> meta-model may harm the realization of that goal and we would rather start
> from a simpler core set of features and allow for future extensions in
> response to industry need rather than second guessing what those might be.
> 
> To draw a conclusion I would suggest to try to publish a first les complex
> AUI meta-model which could be easily used in industry. An extended version
> could then be published in future. The current AUI specification must not be
> perfect, but we have to remember the target audience of the specification:
> practitioners in industry. Perhaps the way forward is to see if we can
> prioritize the features and try to get a feel for which ones are core and
> which ones have only marginal interest? Would it even be worth thinking
> about how we could reach out to industry via a survey of some kind?
> 
> I would be happy to get your opinions. Thanks.
> 
> Best regards
> Gerrit
> 
> ========================
> Dr.-Ing. Gerrit Meixner
> Head of the Human-Machine-Interaction group
> 
> German Research Center for Artificial Intelligence (DFKI)
> Innovative Factory Systems (IFS)
> Trippstadter Strasse 122
> 67663 Kaiserslautern, Germany
> 
> Tel./Fax/Mobile/E-Mail/Web
> +49 (0) 631 / 205 75 3415
> +49 (0) 631 / 205 75 3402
> +49 (0) 157 / 725 95 865
> Gerrit.Meixner@dfki.de
> http://www.dfki.de
> ========================
> Legal statement:
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
> Trippstadter Strasse 122
> 67663 Kaiserslautern
> 
> Geschäftsführung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender), Dr. Walter
> Olthoff
> Vorsitzender des Aufsichtsrats:
> Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> ========================
> 
> 
> 
> 
> 
> 
> -- 
> Paolo Bottoni
> 
> Associate Professor of Computer Science
> 
> Email: bottoni@di.uniroma1.it
> 
> Website: http://w3.uniroma1.it/dipinfo/scheda_docente.asp?cognome=Bottoni&nome=Paolo
> 
> Phone: +39 06 49255369
> 
> Fax: + 39 06 8541842
> 
>  
> Important conferences:
> 
> http://www.etaps.org/
> 
> http://vlhcc2012.di.unisa.it/
> 
> http://www.informatik.uni-bremen.de/icgt2012/
> 
>