See also: IRC log
<dsr-grasbrunn> scribe: Dave
<dsr-grasbrunn> scribenick: dsr
<dsr-grasbrunn> We start by going around the table introducing ourselves. The telephone bridge will be set up shortly
<dsr-grasbrunn> Heiko, our host, gives us a brief introduction to Red Hat.
<dsr-grasbrunn> Open source company well known for its Linux distributions, we offer support and training.
<dsr-grasbrunn> Fabio: who are your clients?
<dsr-grasbrunn> Heiko: traditionally, financial companies for servers, but more generally for enterprise
<dsr-grasbrunn> Large insurance companies, health care, and other companies across the board.
<dsr-grasbrunn> Jaroslav: what is the relation to jBoss?
<dsr-grasbrunn> Heiko: we acquired jBoss 6 years ago, and it is now run as its own business unit, focusing on a Java server platform.
<dsr-grasbrunn> e.g. for business rules and BPM, where you depend on declarative statement of business rules.
<dsr-grasbrunn> jBoss is based upon the Drools forward chaining engine.
<dsr-grasbrunn> Heiko: on the one hand we need to bring the various software components together, but we also need to present a consistent user interface for managing them.
<dsr-grasbrunn> We have software engineers working on middleware components, but mostly they don't have expertise in user interface design.
<dsr-grasbrunn> One of the benefits for model based UI design is to enable the full range of stakeholders to engage in the design and review process.
<dsr-grasbrunn> We have been exploring the UseML framework for an XML description of the UIs.
<dsr-grasbrunn> A business expert may create a rough UI, that is later refined by a usability expert.
<dsr-grasbrunn> We go directly from the AUI to the final UI. We don't make use of task models, but do take advantage of the temporal operators.
<dsr-grasbrunn> Paolo: how do you model mutual exclusion, where if you do one task you can't then do another.
<dsr-grasbrunn> Heiko: we have suspend and resume operators ...
<dsr-grasbrunn> Heiko: we currently just generate HTML5 as the final UI. We are also considering an eclipse module.
<dsr-grasbrunn> Everything is open source and publicly accessible.
<dsr-grasbrunn> We have explored for some time the right level of abstraction to meet our UI, and the W3C MBUI WG looked very relevant to our needs.
<dsr-grasbrunn> The structural aspects are much easier to address compared with the behavioural aspects for a given UI design.
<dsr-grasbrunn> It has been very useful to have a shared terminology to facilitate work across different stakeholders.
<dsr-grasbrunn> We support UI extensions and progressive enhancements to a UI, even with contributions by end-users.
<dsr-grasbrunn> With a simpler description of the abstract UI it becomes much easier for people to adjust the UI to their needs.
<dsr-grasbrunn> We have have very strong authorization requirements for the interfaces, controlling which users can access what features.
<dsr-grasbrunn> The tooling is critical for making this all practical.
<dsr-grasbrunn> We can check the consistency of a given UI design against the domain interfaces.
<dsr-grasbrunn> People contribute structural parts (domain interfaces) and the behavioural parts in different orders, So we need to allow for that.
<dsr-grasbrunn> We are working on better visual tools for designing and manipulating the full UI design.
<dsr-grasbrunn> Different stakeholders contribute different aspects to a design and this would be close to impossible without the models as a shared underlying description.
<dsr-grasbrunn> Jaroslav refers to XForms and SCXML as providing a vocabulary for UI aspects, have you considered using any of these in your work?
<dsr-grasbrunn> Heiko: not really. We define product/domain specific containers as the basis for forms.
<dsr-grasbrunn> Dave: W3C groups in many cases use WebIDL for specifying interfaces, I've been looking at extending this with annotations inspired by XForms.
<dsr-grasbrunn> Jaroslav asks if Heiko could give a short presentation of the details of the Red Hat framework, perhaps this evening or tomorrow morning.
<dsr-grasbrunn> Vivian: the use case study is depicted in figure 2 in the intoduction to MBUI, see https://docs.google.com/document/d/1Xp50GZ8EfY017AT_pCMBq5PeK8cwNEZi1a8hXexJkCc/
<dsr-grasbrunn> Jaroslav: it is important to describe a concrete example in more detail, so that readers can understand how the models at different levels of description relate to one another.
<dsr-grasbrunn> Vivian and Jaroslav discuss what's needed ...
<dsr-grasbrunn> Dave: what timescale are we talking about for finishing this?
<dsr-grasbrunn> Joelle: I was expecting this to have been done by today.
<dsr-grasbrunn> Gaelle: can we do this collaboratively?
<dsr-grasbrunn> Jaroslav: I would expect to see a CTT diagram and a text-based description of tasks, and likewise for the AUI.
<dsr-grasbrunn> Fabio: to avoid the document becoming too large, we can cite external documents with the full models.
<dsr-grasbrunn> Dave: the introduction does need to provide sufficient details to motivate people to read more, but without embroiling them in too many details.
<dsr-grasbrunn> Carlos: we need to explain the Cameleon framework first.
<dsr-grasbrunn> Joelle: yes
<dsr-grasbrunn> Carlos: who are the target readers for the document?
<dsr-grasbrunn> Joelle: UI developers and tool vendors.
<dsr-grasbrunn> Jaroslav notes that there is a lack of consistency across our documents.
<dsr-grasbrunn> Joelle: it would be a lot easier if we could project the documents so that can all see just what is being referred to
<dsr-grasbrunn> ... we take a break while the projection system wiring is sorted out -- the room was recently reconfigured and isn't working just yet --
<dsr-grasbrunn> ... we shift rooms as a work around the wiring problem
<dsr-grasbrunn> we reconvene, and Heiko projects the intro document, see https://docs.google.com/document/d/1Xp50GZ8EfY017AT_pCMBq5PeK8cwNEZi1a8hXexJkCc/
<hbraun> here's the dial-in number: +49 89 205071241
<dsr-grasbrunn> We discuss what we want to see for the treatment of the use case in the introductory document.
<dsr-grasbrunn> There needs to be a consistent treatment of the terms used.
<dsr-grasbrunn> Fabio: the meta model is quite simple, e.g. compared with the one we started with in Serenoa.
<dsr-grasbrunn> Joelle points out some minor inconsistencies, e.g. the spelling of colour in one place and color in another.
<dsr-grasbrunn> Joelle we really need to get this ready for publication.
<dsr-grasbrunn> Davide joins us remotely via the telephone bridge
<dsr-grasbrunn> Gaelle: the task models needs to be explained, e.g. the interleaving operator.
<dsr-grasbrunn> Gaelle: the case study needs to be convincing about the value of using task models.
<dsr-grasbrunn> Carlos: Fabio's example of the digital home is for me easier to understand
<dsr-grasbrunn> Gaelle: we don't need to start afresh, it isn't a huge amount of work!
<dsr-grasbrunn> ... Nick arrives
<dsr-grasbrunn> Joelle: we need to show how the models relate to different target platforms e.g. smart phones.
<dsr-grasbrunn> Carlos is right, it makes sense to start from the final UI and show how this is derived.
<dsr-grasbrunn> Gaelle: we just need to take the point of view of the end user.
<dsr-grasbrunn> Vivian projects the diagram from http://sites.uclouvain.be/mbui/
<dsr-grasbrunn> This shows the car rental use case AUI and task model
<dsr-grasbrunn> Fabio: the task model is abstract and doesn't specify the final UI
<dsr-grasbrunn> Gaelle draws a diagram with one task model, two resultant AUI models, and showing that a given AUI model can be used for mulitple CUI models, and in turn for multiple final UIs
<dsr-grasbrunn> Vivian: the AUI should be platform independent.
<dsr-grasbrunn> Paolo: the AUI should be expressed in terms of containers ...
<dsr-grasbrunn> Jaroslav: would the clustering of abstract interaction units depend on the characteristics of the target devices.
<dsr-grasbrunn> Fabio: the AUI vocabulary is modality independent.
<dsr-grasbrunn> Paolo: we could handle this at the task model
<dsr-grasbrunn> Joelle: we don't necessarily start from the task models, sometimes you start from the abstract UI
<dsr-grasbrunn> Dave: it makes sense to start from small number of screen shots on the use case on a desktop and a smart phone, and then explain how the models make it easier to generate these UIs
<dsr-grasbrunn> Carlos: in the task model there is a single action to submit the data collected from the user.
<dsr-grasbrunn> ... some confusion ensues
<dsr-grasbrunn> Joelle the mapping from the task model to the final UI is not one to one.
<dsr-grasbrunn> Jaroslav: you can't revert a submit (semantics are transactional)
<dsr-grasbrunn> Dave thinks the discussion is mostly about the domain model ...
<dsr-grasbrunn> and the ordering semantics imposed by it
<dsr-grasbrunn> Fabio: how do we want to proceed (as we are running short of time for this agenda item)
<dsr-grasbrunn> Heiko: so the plan is to use a single use case consistently across our documents, right?
<dsr-grasbrunn> Fabio: yes
<dsr-grasbrunn> Carlos: we could have further use cases, although in less detail
<dsr-grasbrunn> We discuss the initial wording for motivating the car rental use case
<dsr-grasbrunn> Joelle volunteers to draft the context of use
<dsr-grasbrunn> 1. The user is at home at her PC.
<dsr-grasbrunn> 2. The user is walking fast along a quiet street with her smart phone
<dsr-grasbrunn> Fabio: if you are walking fast your attention is not on the screen.
<dsr-grasbrunn> Joelle: let's now look at the task model ...
<dsr-grasbrunn> Dave: the task model needs to relate to the domain model at some level
<dsr-grasbrunn> Gaelle invites Jaroslav to describe the task model
<dsr-grasbrunn> n.b. for the second context of use, we anticipate the use of vocal interaction with the smart phone.
<dsr-grasbrunn> Jaroslav: you should put the most important task first ...
<dsr-grasbrunn> Fabio: at the task level should avoid unnecessary details, as these should be added at the concrete UI level, you for the target platforms.
<dsr-grasbrunn> Dave notes that the current task model for the car rental example isn't realistic compared with actual car rental apps from the likes of the Hertz company.
<dsr-grasbrunn> You typically pick up and drop off the car from a Hertz site, e.g. an airport or railway station.
<dsr-grasbrunn> The tasks focus on how you are able to identify these sites, e.g. with the name of the airport, or by drilling down from the country, region, town and so forth.
<dsr-grasbrunn> Heiko: we should look at simplified use cases based upon real world examples.
<dsr-grasbrunn> Paolo suggests refining task models based upon the availability of resources and the constraints that apply to them.
<dsr-grasbrunn> Fabio: some transformations for particular constraints can be done at the task level or at lower levels.
<dsr-grasbrunn> Heiko: if there are big differences between the needs of the two contexts of use, then it would be easier to understand with separate task models.
<dsr-grasbrunn> Joelle: it needs to specify who, what, when and where.
<dsr-grasbrunn> Dave: what covers the type of car, options such as booster seats for small children, and insurance options.
<dsr-grasbrunn> Gaelle: the main tasks cover expressing what you want, making a selection, reviewing the details, then making the payment.
<dsr-grasbrunn> We use the Hertz website as a guide to constructing our simplified task model
<dsr-grasbrunn> Joelle: you first need to specify where and when, but these tasks are not ordered.
<dsr-grasbrunn> Dave wonders about how you capture the fact that it is rare to return the car to a different location than where you picked it up, isn't this part of the domain model?
<dsr-grasbrunn> We discuss the task for selecting a pick up and drop off site. The details are likely to vary according to the context of use.
<dsr-grasbrunn> Joelle and Gaelle present their proposal for the task model
<dsr-grasbrunn> Dave notes that task models can be decomposed into modular design exercises done by different teams.
<dsr-grasbrunn> We don't need to cover everything in a single task model.
<dsr-grasbrunn> Joelle: the what booking task subdivides into where, when and what which need to precede the pay task
<dsr-grasbrunn> Dave: when approaching UI design, a starting point is typically a statement of the business needs including characterisation of the target users. This can then be mapped into the domain and task models.
<dsr-grasbrunn> Joelle: price comparison sites seem to generalize the domain model to cover multiple websites, e.g. Hertz and Avis, one example is how far away the car rental site is located.
<dsr-grasbrunn> Gaelle: we need to be able to indicate that a task is a critical one. This is for tasks where there is a big penalty to the user for making a mistake.
<dsr-grasbrunn> Fabio: we could add that in the next update the the task model specification.
<paolo> Paolo: we could characterise the tasks in terms of the resources they make available to the process in their post-conditions
<dsr-grasbrunn> Dave asks for how we want to address the less likely case of users wanting to drop off at a different location?
<dsr-grasbrunn> Fabio: we can make that into an optional task.
<paolo> Paolo: the drop off at a different location is really a subtask of "define return location", either you accept the default location or you set a different one
<hbraun> davide_: ping
<hbraun> davide_: we are about to continue
<dsr-grasbrunn> ... we break for lunch
<dsr-grasbrunn> Improve the consistency. Update the use case based on the morning's discussion.
<dsr-grasbrunn> Jaroslav has made some notes on the white board diagram for the car rental task model provided by Joelle and Gaelle.
<dsr-grasbrunn> Dave notes that Hertz only shows the cars they reckon will be available from your selected pick up location and date.
<dsr-grasbrunn> Jaroslav: so there is a dependency ordering on the tasks.
<dsr-grasbrunn> Joelle the commit and pay task is a critical task as it can't be back tracked,
<dsr-grasbrunn> ACTION: Jaroslav to draw an updated CTT diagram and circulate the exported XML file by end of 10 July 2013 [recorded in http://www.w3.org/2013/07/10-mbui-minutes.html#action01]
<dsr-grasbrunn> Heiko: do we need to include an explicit domain model?
<dsr-grasbrunn> Dave: I think this would be considered important by Web developers who are very much interested in the boundary between the user interface and the back end application information systems.
<dsr-grasbrunn> Heiko: people will take different approaches to what is developed first, the domain model make come after the initial work on the task model.
<dsr-grasbrunn> In my opinion the domain, task and abstract ui models should be in the same document for the convenience of readers.
<dsr-grasbrunn> Gaelle: should we have a new document just for the case?
<dsr-grasbrunn> Joelle: so all the models are extracted from the other documents and referenced.
<dsr-grasbrunn> Gaelle: we could then have separate documents for each use case.
<dsr-grasbrunn> Paolo: sometimes you only want to use one model, and don't need the full set of models for a given use case.
<dsr-grasbrunn> Dave: the introductory document should be readable on its own.
<dsr-grasbrunn> Gaelle asks Dave to create a new document for the car rental study
<dsr-grasbrunn> Dave: I copied the intro document, so now you all need to edit it as appropriate, see https://docs.google.com/document/d/1BnITI7AoeZAlOMiRvLW0Yt45nsx9wCT3AVTgmLDu2G0/
<dsr-grasbrunn> Fabio: we need to decide on next steps ...
<dsr-grasbrunn> Our next teleconference will be Friday, 19 July. We should have the intro and use case documents ready for Group review by then.
<dsr-grasbrunn> Joelle: I will work on it this evening.
<dsr-grasbrunn> Fabio: I think we can now proceed to other agenda items.
<dsr-grasbrunn> Topic Updating the Task model specification
<dsr-grasbrunn> Fabio: we have already agreed a number of changes. To clean up the introduction, to move out the example model and reference the use case document, and to add support to the schema for marking tasks as "critical".
<dsr-grasbrunn> Dave: we should then aim to push out an updated public working draft.
<dsr-grasbrunn> We can later move to a last call working draft once the working group notes have been published.
<dsr-grasbrunn> Fabio: ISTI will update the html version that was previously published.
<dsr-grasbrunn> Dave: thanks - it was a lot of work to generate clean HTML from the google doc, so that is much appreciated.
<dsr-grasbrunn> Fabio: the specification is now structured to make it easier to add new task types.
<dsr-grasbrunn> ACTION: Fabio and colleagues to provide an updated draft by the next teleconference (July 19) [recorded in http://www.w3.org/2013/07/10-mbui-minutes.html#action02]
<dsr-grasbrunn> see https://docs.google.com/document/d/1UGZz_xaPuSbMtRb4a-14tM9CM8tHmbEWuLVuNNnx25o/edit
<dsr-grasbrunn> Vivian provides a short status report.
<dsr-grasbrunn> Carlos: where is the output event for when the system provides info back to the user?
<dsr-grasbrunn> Heiko: we have a DataInputOutput event that can be used for that.
<dsr-grasbrunn> Paolo: we aren't aiming to be comprehensive in the set of events, what you see are essentially examples.
<dsr-grasbrunn> Joelle: we have a distinction between interactors and events
<dsr-grasbrunn> Heiko: what was the motivation to merge the input and output event?
<dsr-grasbrunn> Paolo: the description makes the purpose clear: to support data input, output or both.
<dsr-grasbrunn> You could say it is too general, but I don't see that as a problem
<dsr-grasbrunn> Fabio: is the resource model explained here?
<dsr-grasbrunn> Paolo: you're right, it is missing
<dsr-grasbrunn> Jaroslav: Paolo could you provide one?
<hbraun> the uml diagrams are kept here: http://code.google.com/p/mbui-diagrams/ t
<dsr-grasbrunn> Dave: I've added a link to it from the wiki page for editor's drafts
<dsr-grasbrunn> Heiko: we don't all of us understand all of the details of the AUI meta model, I think that is a sign that it is too complex
<dsr-grasbrunn> We discuss the attribute "isCompound" which essentially signals whether the interaction unit is composed from lower level components.
<dsr-grasbrunn> Jaroslav: are they any methods to get the compound components?
<dsr-grasbrunn> Fabio: no, we should add them
<dsr-grasbrunn> Heiko: the attribute seems redundant, right
<dsr-grasbrunn> Gaelle: yes, you're right
<dsr-grasbrunn> .... Davide rejoins remotely on the audio bridge
<dsr-grasbrunn> Gaelle: we are losing flexibility with the current meta model for composition.
<dsr-grasbrunn> Paolo: if we leave composition to the task model, we lose flexibility.
<dsr-grasbrunn> Gaelle: the task model is rigid (e.g. in its set of temporal operators), here in the AUI we need greater flexibility.
<dsr-grasbrunn> Carlos: in the task model, a task may have an explicit set of sub-tasks, but you can't have a given task decompose into different sets of sub-tasks.
<dsr-grasbrunn> Fabio: would the latter make sense?
<dsr-grasbrunn> Paolo steps up to the board to clarify his point about the rigidity of the current decomposition meta model for tasks
<dsr-grasbrunn> Gaelle: composition should be a common pattern for the meta-models across the levels in the Cameleon framework
<dsr-grasbrunn> Gaelle: composition is an entity per se that is made explicit at all levels of models
<dsr-grasbrunn> Jaroslav: do we have an operator for this?
<paolo> Paolo: the task model is structured through the pattern CompoundElement - Composition Entity - aggregation of entitities of the same type of the compound element, in the same way as the Task model
<paolo> Paolo: the rationale is that the semantics of the composition relation makes it difficult to create intermediate levels, once a subtree has been created
<dsr-grasbrunn> Gaelle: I want to remove the attribute useCaseCoverage
<dsr-grasbrunn> Heiko: this needs to be revisited by Jean, why don't we remove everything that isn't obvious to people in the room?
<dsr-grasbrunn> Paolo: we may not want to bind to use cases in all situations.
<dsr-grasbrunn> Fabio: useCaseCoverage sounds like a documentation concept.
<dsr-grasbrunn> Joelle reads out the descriptions of the attributes on AbstractInteractionUnit
<dsr-grasbrunn> Fabio: securityLevel seems similar to "critical" for task models.
<dsr-grasbrunn> Vivian: security can be used in relation to access control - locking down which users can access what features.
<dsr-grasbrunn> Carlos: why a five point security scale?
<dsr-grasbrunn> Dave: I would have thought that for access control you want names that you can relate to access control policies
<dsr-grasbrunn> Gaelle: these attributes are here to allow people to start by designing the AUI and later to come up with the task model.
<dsr-grasbrunn> Heiko: companies vary considerably in how they deal with security.
<dsr-grasbrunn> We also have to consider privacy ...
<dsr-grasbrunn> Gaelle: perhaps we need a generic mechanism for annotations and allow for extensibility
<dsr-grasbrunn> Joelle: who wants to volunteer to update the AUI metamodel?
<dsr-grasbrunn> I would rather we updated it right now, right here!
<dsr-grasbrunn> Gaelle summarises her proposal for the new framework for the meta model
<dsr-grasbrunn> Paolo volunteers to try to capture this in words for the minutes. Discussion ensures on the details.
<paolo> Gaelle: all the metamodels, no matter their level of abstraction, are based on the following conventions:
<dsr-grasbrunn> Paolo notes that instantiation is needed not subclassing for that would give the wrong kind of flexibility.
<paolo> there are entities, these are composed through a Composition classes, and there is a mechanism for annotating entities with domain-specific levels
<paolo> all the other metamodels realise these mechanisms
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/shrotl/shortly/ Succeeded: s/can do/can/ Succeeded: s/details/detail/ Succeeded: s/diagam/diagram/ Succeeded: s/generat/generate/ Succeeded: s/level/level, you/ Succeeded: s/look a/look at/ Succeeded: s/from/between/ Succeeded: s/it as/that as/ Succeeded: s/means/signals/ Succeeded: s/then for/for/ Succeeded: s/related/relate/ Succeeded: s/then/later/ Found Scribe: Dave Found ScribeNick: dsr WARNING: No scribe lines found matching ScribeNick pattern: <dsr> ... WARNING: 0 scribe lines found (out of 248 total lines.) Are you sure you specified a correct ScribeNick? Present: Nick_Kaklanis Dave Paolo Fabio Heiko Nick Michael Carlos Joelle Gaelle Davide Regrets: Jean Gerrit Agenda: http://www.w3.org/wiki/Munich_2013_Face_to_Face_Agenda Got date from IRC log name: 10 Jul 2013 Guessing minutes URL: http://www.w3.org/2013/07/10-mbui-minutes.html People with action items: colleagues fabio jaroslav[End of scribe.perl diagnostic output]