Munich 2013 Face to Face Agenda and Minutes
Agenda
Wednesday 10th July
Conference Call number: +49 89 205071241
The meeting will start promptly at 9am and run as long as we feel is appropriate
09.00 - 10.00 * Invited presentation on Red Hat's interest in MBUI
10.00 - 10.30 * Review of MBUI Use Case study
10.30 - 11.00 * Updated Public Working Draft for Task Models - What changes we want to apply to the FPWD from 2 August 2012
11.00 - 12.30 * Preparing the Abstract UI for transition to First Public Working Draft
12.30 - 14.00 Lunch
14.00 - 15.00 * Preparing the Abstract UI for transition to First Public Working Draft
15.00 - 17.00 * Preparing the Glossary for publication as a Working Group Note
- Clarification on the intended audience
- Checking for consistency
- Which entries we feel can be dropped
17.00 - 18.00 * Preparing the Introduction to MBUI for publication as a Working Group Note
Group receipt for Wednesday evening's dinner at the Ilios restaurant
Thursday 11th July
The meeting will start at 9am and run until lunchtime.
- 9.00 - 10.00 The new Ubiquitous Application Design Community Group
- 10.00 - 10.30 What is involved in moving specs along the W3C Recommendation Track
- See the W3C Recommendation Track Process
- How can we demonstrate interoperability across all features in the task and abstract UI model specifications?
- Who will be able to provide implementation reports?
- 10.30 - 11.00 What do we expect to have achieved by the end of the current charter (30 November 2013)
- How can we attract greater industry participation in the working group?
- 11.00 - 12.00 What do we need to do about rechartering?
- See current charter
Minutes
We will aim to have the minutes explicitly in the wiki pages, based upon notes from the IRC channel and those taken separately. The following links are temporary, as the final minutes will appear as part of this page.
Meeting summary from handwritten notes by Michael Bauer
Present
- Dave, Paolo, Fabio, Heiko, Nick, Michael, Carlos, Joelle, Gaelle, Davide (remote)
Regrets
- Jean, Gerrit
Chair
- Fabio
Scribe
- Dave + others
Summary of Action Items
NEW ACTION: Fabio and colleagues to provide an updated draft by the next teleconference (July 19)
NEW ACTION: Jaroslav to draw an updated CTT diagram and circulate the exported XML file by end of 10 July 2013
Wednesday Topics
- Red Hat's interest in MBUI
- Review of MBUI Use Case study
- What is left to do on the Introduction to MBUI?
- The Abstract UI meta model specification
We start by going around the table introducing ourselves. The telephone bridge will be set up shortly
Red Hat's interest in MBUI
- Heiko's slides (pdf)
Heiko, our host, gives us a brief introduction to Red Hat. Open source company well known for its Linux distributions, we offer support and training.
Fabio: who are your clients?
Heiko: traditionally, financial companies for servers, but more generally for enterprise Large insurance companies, health care, and other companies across the board.
Jaroslav: what is the relation to jBoss?
Heiko: we acquired jBoss 6 years ago, and it is now run as its own business unit, focusing on a Java server platform. e.g. for business rules and BPM, where you depend on declarative statement of business rules. jBoss is based upon the Drools forward chaining engine.
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.
We have software engineers working on middleware components, but mostly they don't have expertise in user interface design. 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. We have been exploring the UseML framework for an XML description of the UIs.
A business expert may create a rough UI, that is later refined by a usability expert.
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.
Paolo: how do you model mutual exclusion, where if you do one task you can't then do another.
Heiko: we have suspend and resume operators ...
Heiko: we currently just generate HTML5 as the final UI. We are also considering an eclipse module. Everything is open source and publicly accessible. 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. The structural aspects are much easier to address compared with the behavioural aspects for a given UI design. It has been very useful to have a shared terminology to facilitate work across different stakeholders.
We support UI extensions and progressive enhancements to a UI, even with contributions by end-users. With a simpler description of the abstract UI it becomes much easier for people to adjust the UI to their needs.
We have have very strong authorization requirements for the interfaces, controlling which users can access what features. The tooling is critical for making this all practical. We can check the consistency of a given UI design against the domain interfaces.
People contribute structural parts (domain interfaces) and the behavioural parts in different orders, So we need to allow for that. We are working on better visual tools for designing and manipulating the full UI design.
Different stakeholders contribute different aspects to a design and this would be close to impossible without the models as a shared underlying description.
Jaroslav refers to XForms and SCXML as providing a vocabulary for UI aspects, have you considered using any of these in your work?
Heiko: not really. We define product/domain specific containers as the basis for forms.
Dave: W3C groups in many cases use WebIDL for specifying interfaces, I've been looking at extending this with annotations inspired by XForms.
Jaroslav asks if Heiko could give a short presentation of the details of the Red Hat framework, perhaps this evening or tomorrow morning.
Review of MBUI Use Case study
Vivian: the use case study is depicted in figure 2 in the Intoduction to MBUI
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.
Vivian and Jaroslav discuss what's needed ...
Dave: what timescale are we talking about for finishing this?
Joelle: I was expecting this to have been done by today.
Gaelle: can we do this collaboratively?
Jaroslav: I would expect to see a CTT diagram and a text-based description of tasks, and likewise for the AUI.
Fabio: to avoid the document becoming too large, we can cite external documents with the full models.
Dave: the introduction does need to provide sufficient details to motivate people to read more, but without embroiling them in too many details.
Carlos: we need to explain the Cameleon framework first.
Joelle: yes
Carlos: who are the target readers for the document?
Joelle: UI developers and tool vendors.
Jaroslav notes that there is a lack of consistency across our documents.
Joelle: it would be a lot easier if we could project the documents so that can all see just what is being referred to
... we take a break while the projection system wiring is sorted out -- the room was recently reconfigured and isn't working just yet --
... we shift rooms as a work around the wiring problem
we reconvene, and Heiko projects the intro document
We discuss what we want to see for the treatment of the use case in the introductory document. There needs to be a consistent treatment of the terms used.
Fabio: the meta model is quite simple, e.g. compared with the one we started with in Serenoa.
Joelle points out some minor inconsistencies, e.g. the spelling of colour in one place and color in another.
Joelle: we really need to get this ready for publication.
Davide joins us remotely via the telephone bridge
Gaelle: the task models needs to be explained, e.g. the interleaving operator.
Gaelle: the case study needs to be convincing about the value of using task models.
Carlos: Fabio's example of the digital home is for me easier to understand
Gaelle: we don't need to start afresh, it isn't a huge amount of work!
... Nick arrives
Joelle: we need to show how the models relate to different target platforms e.g. smart phones.
Carlos is right, it makes sense to start from the final UI and show how this is derived.
Gaelle: we just need to take the point of view of the end user.
Vivian projects the diagram from http://sites.uclouvain.be/mbui/ This shows the car rental use case AUI and task model
Fabio: the task model is abstract and doesn't specify the final UI
Gaelle draws a diagram with one task model, two resultant AUI models, and showing that a given AUI model can be used for multiple CUI models, and in turn for multiple final UIs
Vivian: the AUI should be platform independent.
Paolo: the AUI should be expressed in terms of containers ...
Jaroslav: would the clustering of abstract interaction units depend on the characteristics of the target devices.
Fabio: the AUI vocabulary is modality independent.
Paolo: we could handle this at the task model
Joelle: we don't necessarily start from the task models, sometimes you start from the abstract UI
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
Carlos: in the task model there is a single action to submit the data collected from the user.
... some confusion ensues
Joelle the mapping from the task model to the final UI is not one to one.
Jaroslav: you can't revert a submit (semantics are transactional)
Dave thinks the discussion is mostly about the domain model ... and the ordering semantics imposed by it
Fabio: how do we want to proceed (as we are running short of time for this agenda item)
Heiko: so the plan is to use a single use case consistently across our documents, right?
Fabio: yes
Carlos: we could have further use cases, although in less detail We discuss the initial wording for motivating the car rental use case
Joelle volunteers to draft the context of use
1. The user is at home at her PC. 2. The user is walking fast along a quiet street with her smart phone
Fabio: if you are walking fast your attention is not on the screen.
Joelle: let's now look at the task model ...
Dave: the task model needs to relate to the domain model at some level
Gaelle invites Jaroslav to describe the task model
n.b. for the second context of use, we anticipate the use of vocal interaction with the smart phone.
Jaroslav: you should put the most important task first ...
Fabio: at the task level should avoid unnecessary details, as these should be added at the concrete UI level, you for the target platforms.
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. You typically pick up and drop off the car from a Hertz site, e.g. an airport or railway station.
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.
Heiko: we should look at simplified use cases based upon real world examples.
Paolo suggests refining task models based upon the availability of resources and the constraints that apply to them.
Fabio: some transformations for particular constraints can be done at the task level or at lower levels.
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.
Joelle: it needs to specify who, what, when and where.
Dave: what covers the type of car, options such as booster seats for small children, and insurance options.
Gaelle: the main tasks cover expressing what you want, making a selection, reviewing the details, then making the payment. We use the Hertz website as a guide to constructing our simplified task model
Joelle: you first need to specify where and when, but these tasks are not ordered.
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?
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.
Joelle and Gaelle present their proposal for the task model
Dave notes that task models can be decomposed into modular design exercises done by different teams. We don't need to cover everything in a single task model.
Joelle: the what booking task subdivides into where, when and what which need to precede the pay task
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.
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.
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.
Fabio: we could add that in the next update the the task model specification.
Paolo: we could characterise the tasks in terms of the resources they make available to the process in their post-conditions
Dave asks for how we want to address the less likely case of users wanting to drop off at a different location?
Fabio: we can make that into an optional task.
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
... we break for lunch
What is left to do on the Introduction to MBUI?
Improve the consistency. Update the use case based on the morning's discussion.
Jaroslav has made some notes on the white board diagram for the car rental task model provided by Joelle and Gaelle.
Dave notes that Hertz only shows the cars they reckon will be available from your selected pick up location and date.
Jaroslav: so there is a dependency ordering on the tasks. Joelle the commit and pay task is a critical task as it can't be back tracked,
ACTION: Jaroslav to draw an updated CTT diagram and circulate the exported XML file by end of 10 July 2013
Heiko: do we need to include an explicit domain model?
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.
Heiko: people will take different approaches to what is developed first, the domain model make come after the initial work on the task model. In my opinion the domain, task and abstract ui models should be in the same document for the convenience of readers.
Gaelle: should we have a new document just for the case?
Joelle: so all the models are extracted from the other documents and referenced.
Gaelle: we could then have separate documents for each use case.
Paolo: sometimes you only want to use one model, and don't need the full set of models for a given use case.
Dave: the introductory document should be readable on its own.
Gaelle asks Dave to create a new document for the car rental study
Dave: I copied the intro document, so now you all need to edit it as appropriate, see [ttps://docs.google.com/document/d/1BnITI7AoeZAlOMiRvLW0Yt45nsx9wCT3AVTgmLDu2G0/ car rental study]
Fabio: we need to decide on next steps ...
Our next teleconference will be Friday, 19 July. We should have the intro and use case documents ready for Group review by then.
Joelle: I will work on it this evening.
Fabio: I think we can now proceed to other agenda items.
Updating the Task model specification
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".
Dave: we should then aim to push out an updated public working draft. We can later move to a last call working draft once the working group notes have been published.
Fabio: ISTI will update the html version that was previously published.
Dave: thanks - it was a lot of work to generate clean HTML from the google doc, so that is much appreciated.
Fabio: the specification is now structured to make it easier to add new task types.
ACTION: Fabio and colleagues to provide an updated draft by the next teleconference (July 19)
The Abstract UI meta model specification
Vivian provides a short status report.
Carlos: where is the output event for when the system provides info back to the user?
Heiko: we have a DataInputOutput event that can be used for that.
Paolo: we aren't aiming to be comprehensive in the set of events, what you see are essentially examples.
Joelle: we have a distinction between interactors and events
Heiko: what was the motivation to merge the input and output event?
Paolo: the description makes the purpose clear: to support data input, output or both. You could say it is too general, but I don't see that as a problem
Fabio: is the resource model explained here?
Paolo: you're right, it is missing
Jaroslav: Paolo could you provide one?
Heiko: the uml diagrams are kept here: http://code.google.com/p/mbui-diagrams/
Dave: I've added a link to it from the wiki page for editor's drafts
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
We discuss the attribute "isCompound" which essentially signals whether the interaction unit is composed from lower level components.
Jaroslav: are they any methods to get the compound components?
Fabio: no, we should add them
Heiko: the attribute seems redundant, right
Gaelle: yes, you're right
.... Davide rejoins remotely on the audio bridge
Gaelle: we are losing flexibility with the current meta model for composition.
Paolo: if we leave composition to the task model, we lose flexibility.
Gaelle: the task model is rigid (e.g. in its set of temporal operators), here in the AUI we need greater flexibility.
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.
Fabio: would the latter make sense?
Paolo steps up to the board to clarify his point about the rigidity of the current decomposition meta model for tasks
Gaelle: composition should be a common pattern for the meta-models across the levels in the Cameleon framework
Gaelle: composition is an entity per se that is made explicit at all levels of models
Jaroslav: do we have an operator for this?
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: the rationale is that the semantics of the composition relation makes it difficult to create intermediate levels, once a subtree has been created
Gaelle: I want to remove the attribute useCaseCoverage
Heiko: this needs to be revisited by Jean, why don't we remove everything that isn't obvious to people in the room?
Paolo: we may not want to bind to use cases in all situations.
Fabio: useCaseCoverage sounds like a documentation concept.
Joelle reads out the descriptions of the attributes on AbstractInteractionUnit
Fabio: securityLevel seems similar to "critical" for task models.
Vivian: security can be used in relation to access control - locking down which users can access what features.
Carlos: why a five point security scale?
Dave: I would have thought that for access control you want names that you can relate to access control policies
Gaelle: these attributes are here to allow people to start by designing the AUI and later to come up with the task model.
Heiko: companies vary considerably in how they deal with security. We also have to consider privacy ...
Gaelle: perhaps we need a generic mechanism for annotations and allow for extensibility
Joelle: who wants to volunteer to update the AUI metamodel?
I would rather we updated it right now, right here! Gaelle summarises her proposal for the new framework for the meta model
Paolo volunteers to try to capture this in words for the minutes. Discussion ensures on the details.
Gaelle: all the metamodels, no matter their level of abstraction, are based on the following conventions:
Paolo notes that instantiation is needed not subclassing for that would give the wrong kind of flexibility. There are entities, these are composed through a Composition classes, and there is a mechanism for annotating entities with domain-specific levels all the other metamodels realise these mechanisms
Gaelle: draws the updated meta model on the flip chart
Paolo: I am updating the model electronically.
The point is to make the metamodels consistent in the way of modeling, and concise, ie. limited to the scope they are in charge of. The fact that a model is a composition of entities, that an entity can be annotated, and so on is generic and so should be capitalized in the commons, ie. the UImodel. Each level of abstraction inherits from this generic model, and thus focuses on the specificities it has (enumerations of tasks, AUI composition roles)
If we have annotations that make sense at all the levels of abstraction (e.g., important, frequent, critical, ...), then they should be also enumerated in the commons
a paragraph regarding the definition of the user that was at the end of the introductory document has been deleted and pasted it in this document: https://docs.google.com/document/d/1-Nzb3_R6bJnqe7CZ7_mVJLRaqTVDz26ssNLV_pSW_TQ/edit
we resume after a coffee break while the editors are busy updating the AUI meta models.
Paolo presents the new meta model.
Gaelle asks Paolo to provide examples.
In the coffee break Heiko noted that simplifying the meta model is important for use by businesses. The number of documents remains an issue, and we really need a short introduction that can be read in a few minutes. Something that a developer or manager can understand, and which doesn't need to reflect the rigour expected in research papers.
Perhaps we should spend a little time on the personas for the people we want to read our documents?
Paolo steps up to the screen whilst asking Vivian to make changes to the naming of the components in the UML editor.
The grey boxes are generic and used for annotatons. The yellow(?) boxes are specific to the AUI
dsr-grasbrunn: can you remind of printing later on, when we finished todays session?
The Glossary
Fabio: lets put a finish time of 5:30pm for this session.
Jaroslav: one general question is how to handle abbreviations, as this hampers readability
Fabio: usually these are put somewhere
Jaraslav: an example is the use of AIU for abstract interation unit.
I would just expand these abbreviations.
Dave agrees
General agreement around the room
We do however need to define the common abbreviations used in our other documents.
Jaroslav: how to treat citations and references as there a lot of them
Fabio: I would remove them
In the short term Jaroslav will move the references into a new column so that we don't lose them
Jaroslav asks Joelle to review the terms migratory UI, nomadic UI and plastic UI 1
Jaroslav would like to have a column with synonyms and related words in the published document.
Gaelle: what is the norm for glossaries in W3C?
Dave: not sure that there is one, we should perhaps follow Heiko's suggestion of coming up with the personas for our target readers, and ask them!
we discuss the wording of the glossary items one by one.
Heiko: is the glossary an optional document? In my opinion, it shouldn't be essential for people reading the other documents, and we could be using our time more effectively on other matters,
Gaelle: we should recommend certain terms for a consistent way of talking about model-based design.
Dave notes that the current wording for "Abstraction" is too hard for the target audience and as such needs rewriting into something simpler.
He adds that the introduction to model-based UI should be a short easy to read introduction that doesn't require people to read the glossary, which is something that people could turn to as follow on background reading as they feel the desire to dig deeper.
We continue through the terms ...
(note we've reached the 5:30pm local time deadline we planned to stop)
we agree to continue to 6pm
Davide: the call dropped, I'm leaving now... See you tomorrow
... we break for the evening and a group dinner at the near greek restaurant "The Ilios"
Thursday Morning Topics
- W3C Ubiquitous Application Design Community Group
- Next steps for the MBUI Working Group
- Further steps for the AUI meta model
W3C Ubiquitous Application Design Community Group
Gaelle: the dialogue model is the behavioural aspect of the AUI model
Dave presents Community groups and the Ubiquitous Application Design Community Group in particular, inviting members of the working group to join
Next steps for the MBUI Working Group
Dave presents the steps involved in the production of a W3C Recommendation
Gaelle: do we need to have a consistent way of metamodeling?
Fabio: plan for the aui: by the next audioconference a clean version should be read for final check before publicizing the fiorst working group note
Heiko: not at this stage, we will need implementations to show that things work together
Fabio: we can use the introductory document to provide an overview
Discussion on how to achieve two independent implementations
Dave: the implementations have to cover all features
Dave: we could have a test fest, with people in a room exchanging models over different tools.
Dave illustrates the options for dealing with the impending November deadline
Joelle: best option could be to launch a community group in which to do the implementation and then to recharter the WG
Heiko: the only realistic way is to build a community and take from there
Dave: in summary, we should aim to move Task Models and Abstract UI specs through Last Call and into Candidate Recommendations by end of November when the charter expires. This will entail seeking review by other groups, and defining the exit criteria for the Candidate Recommendations.
The Community Group could then shepherd the work on gathering implementation reports and plans for future standization. We could then propose new charters to take this into the REC track.
Red Hat could provide implementation report for the Abstract UI, but not the Task Models spec. ISTI/CNR could do both. We need to collect such commitments from other organizations.
Heiko: the exit criteria should extend to the requirement to take the test models all the way to final UI to ensure that the specs and implementations have relevance to the real world.
Further steps for the AUI meta model
This is a continuation of yesterday's session on the AUI. Paolo talks about the idea of templates.
Heiko: cites login dialogue that can be embedded within a larger UI, as a motivation for templates.
Paolo: classic idea is declare the basic behaviour in a way that can then be refined in different contexts. The parameters for a template determine how much freedom there is to refine it.
Jaroslav: isn't that a matter of restrictions at the data binding level?
Paolo: yes, this is about the relationship between the abstract UI and the domain model. It would be interesting to explore use cases where templates are useful for reuse within the AUI itself. I create a template to create something, when I create that something it might have a number of interactors corresponding to buttons where the template limits this to 2 to 5 buttons.
One question is what happens when a designer modifies directly an instance of a template in a way that violates the constraints imposed by the template, is it still an instance of that template?
Fabio asks Heiko if he thinks this notion of template is valuable to his needs?
Heiko: I am still trying to understand the implications.
Paolo: the constraints imposed by a template might relate to multiplicity of interactors, and to the events that the instance should handle.
Jaroslav: currently templates aren't described adequately in our introduction and glossary.
Heiko asks for clarifications, perhaps through a simple example.
Dave notes that templating is a common design pattern for web apps, e.g. using the PHP import statement.
Paolo presents some examples starting with a button group which can be used for such purposes as a save changes dialogue with buttons for yes, no and cancel.
Note that if you just want a direct instance of a particular dialogue pattern, you don't need the power of templates.
Paolo describes the range of possible template mechanisms. You need to specific a fixed part and a variable part that is specified by the instatiation of the template.
We break as it is nearly noon
Our many thanks to Heiko and Red Hat for hosting the meeting.