07:24:35 <RRSAgent> RRSAgent has joined #mbui
07:24:35 <RRSAgent> logging to http://www.w3.org/2013/07/10-mbui-irc
07:25:17 <dsr-grasbrunn> meeting: MBUI F2F, Munich day 1
07:25:31 <dsr-grasbrunn> chair: Fabio
07:25:53 <dsr-grasbrunn> agenda: http://www.w3.org/wiki/Munich_2013_Face_to_Face_Agenda
07:25:53 <dsr-grasbrunn> scribe: Dave
07:25:58 <dsr-grasbrunn> scribenick: dsr
07:26:43 <dsr-grasbrunn> We start by going around the table introducing ourselves. The telephone bridge will be set up shrotl
07:26:54 <dsr-grasbrunn> s/shrotl/shortly/
07:27:13 <dsr-grasbrunn> Topic: Red Hat's interest in MBUI
07:27:37 <dsr-grasbrunn> Heiko, our host, gives us a brief introduction to Red Hat.
07:28:10 <dsr-grasbrunn> Open source company well known for its Linux distributions, we offer support and training.
07:28:29 <dsr-grasbrunn> Fabio: who are your clients?
07:29:01 <dsr-grasbrunn> Heiko: traditionally, financial companies for servers, but more generally for enterprise
07:29:30 <dsr-grasbrunn> Large insurance companies, health care, and other companies across the board.
07:29:42 <dsr-grasbrunn> Jaroslav: what is the relation to jBoss?
07:30:22 <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.
07:31:09 <dsr-grasbrunn> e.g. for business rules and BPM, where you depend on declarative statement of business rules.
07:33:55 <dsr-grasbrunn> jBoss is based upon the Drools forward chaining engine.
07:35:26 <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.
07:36:15 <dsr-grasbrunn> We have software engineers working on middleware components, but mostly they don't have expertise in user interface design.
07:37:02 <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.
07:37:42 <dsr-grasbrunn> We have been exploring the UseML framework for an XML description of the UIs.
07:38:22 <dsr-grasbrunn> A business expert may create a rough UI, that is later refined by a usability expert.
07:38:33 <dsr-grasbrunn> rrsagent, set logs public
07:39:39 <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.
07:40:19 <dsr-grasbrunn> Paolo: how do you model mutual exclusion, where if you do one task you can't then do another.
07:41:06 <dsr-grasbrunn> Heiko: we have suspend and resume operators ...
07:42:36 <dsr-grasbrunn> Heiko: we currently just generate HTML5 as the final UI. We are also considering an eclipse module.
07:42:53 <dsr-grasbrunn> Everything is open source and publicly accessible.
07:44:33 <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.
07:45:28 <dsr-grasbrunn> The structural aspects are much easier to address compared with the behavioural aspects for a given UI design.
07:46:23 <dsr-grasbrunn> It has been very useful to have a shared terminology to facilitate work across different stakeholders.
07:47:03 <dsr-grasbrunn> We support UI extensions and progressive enhancements to a UI, even with contributions by end-users.
07:48:09 <dsr-grasbrunn> With a simpler description of the abstract UI it becomes much easier for people to adjust the UI to their needs.
07:48:53 <dsr-grasbrunn> We have have very strong authorization requirements for the interfaces, controlling which users can do access what features.
07:49:01 <dsr-grasbrunn> s/can do/can/
07:53:27 <dsr-grasbrunn> The tooling is critical for making this all practical.
07:54:27 <dsr-grasbrunn> We can check the consistency of a given UI design against the domain interfaces.
07:56:11 <dsr-grasbrunn> People contribute structural parts (domain interfaces) and the behavioural parts in different orders, So  we need to allow for that.
07:57:15 <dsr-grasbrunn> We are working on  better visual tools for designing and manipulating the full UI design.
07:59:08 <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.
08:01:28 <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?
08:03:07 <dsr-grasbrunn> Heiko: not really. We define product/domain specific containers as the basis for forms.
08:04:53 <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.
08:06:41 <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.
08:07:08 <dsr-grasbrunn> Topic: Review of MBUI Use Case study
08:09:36 <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/
08:10:58 <dsr-grasbrunn> Jaroslav: it is important to describe a concrete example in more details, so that readers can understand how the models at different levels of description relate to one another.
08:11:53 <dsr-grasbrunn> s/details/detail/
08:13:03 <dsr-grasbrunn> Vivian and Jaroslav discuss what's needed  ...
08:13:53 <dsr-grasbrunn> Dave: what timescale are we talking about for finishing this?
08:14:08 <dsr-grasbrunn> Joelle: I was expecting this to have been done by today.
08:15:27 <dsr-grasbrunn> Gaelle: can we do this collaboratively?
08:16:32 <dsr-grasbrunn> Jaroslav: I would expect to see a CTT diagram and a text-based description of tasks, and likewise for the AUI.
08:17:20 <dsr-grasbrunn> Fabio: to avoid the document becoming too large, we can cite external documents with the full models.
08:19:40 <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.
08:20:18 <dsr-grasbrunn> Carlos: we need to explain the Cameleon framework first.
08:20:24 <dsr-grasbrunn> Joelle: yes
08:20:41 <hbraun> hbraun has joined #mbui
08:20:53 <dsr-grasbrunn> Carlos: who are the target readers for the document?
08:21:10 <dsr-grasbrunn> Joelle: UI developers and tool vendors.
08:22:53 <dsr-grasbrunn> Jaroslav notes that there is a lack of consistency across our documents.
08:32:57 <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
08:33:35 <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 --
08:38:31 <hbraun> hbraun has joined #mbui
08:41:20 <dsr-grasbrunn> ... we shift rooms as a work around the wiring problem
08:41:33 <Fabio> Fabio has joined #mbui
08:41:39 <joelle> joelle has joined #mbui
08:42:48 <Jaroslav> Jaroslav has joined #mbui
08:43:00 <gaelle> gaelle has joined #mbui
08:45:19 <paolo> paolo has joined #mbui
08:46:30 <dsr-grasbrunn> we reconvene, and Heiko projects the intro document, see https://docs.google.com/document/d/1Xp50GZ8EfY017AT_pCMBq5PeK8cwNEZi1a8hXexJkCc/
08:46:49 <hbraun> here's the dial-in number: +49 89 205071241
08:48:53 <dsr-grasbrunn> We discuss what we want to see for the treatment of the use case in the introductory document.
08:49:24 <dsr-grasbrunn> There needs to be a consistent treatment of the terms used.
08:51:04 <dsr-grasbrunn> Fabio: the meta model is quite simple, e.g. compared with the one we started with in Serenoa.
08:51:41 <dsr-grasbrunn> Joelle points out some minor inconsistencies, e.g. the spelling of colour in one place and color in another.
08:52:23 <dsr-grasbrunn> Joelle we really need to get this ready for publication.
08:53:53 <dsr-grasbrunn> Davide joins us remotely via the telephone bridge
08:56:57 <dsr-grasbrunn> Gaelle: the task models needs to be explained, e.g. the interleaving operator.
08:58:20 <dsr-grasbrunn> Gaelle: the case study needs to be convincing about the value of using task models.
08:58:27 <davide_> davide_ has joined #mbui
08:59:03 <dsr-grasbrunn> Carlos: Fabio's example of the digital home is for me easier to understand
08:59:43 <dsr-grasbrunn> Gaelle: we don't need to start afresh, it isn't a huge amount of work!
09:00:19 <dsr-grasbrunn> ... Nick arrives
09:01:02 <dsr-grasbrunn> Joelle: we need to show how the models relate to different target platforms e.g. smart phones.
09:01:39 <dsr-grasbrunn> Carlos is right, it makes sense to start from the final UI and show how this is derived.
09:02:01 <dsr-grasbrunn> Gaelle: we just need to take the point of view of the end user.
09:04:41 <dsr-grasbrunn> Vivian projects the diagam from http://sites.uclouvain.be/mbui/
09:05:40 <dsr-grasbrunn> s/diagam/diagram/
09:06:39 <dsr-grasbrunn> This shows the car rental use case AUI and task model
09:08:25 <dsr-grasbrunn> Fabio: the task model is abstract and doesn't specify the final UI
09:10:06 <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
09:10:53 <dsr-grasbrunn> Vivian: the AUI should be platform independent.
09:11:24 <dsr-grasbrunn> Paolo: the AUI should be expressed in terms of containers ...
09:12:33 <dsr-grasbrunn> Jaroslav: would the clustering of abstract interaction units depend on the characteristics of the target devices.
09:13:00 <dsr-grasbrunn> Fabio: the AUI vocabulary is modality independent.
09:13:15 <dsr-grasbrunn> Paolo: we could handle this at the task model
09:13:53 <dsr-grasbrunn> Joelle: we don't necessarily start from the task models, sometimes you start from the abstract UI
09:15:30 <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 generat these UIs
09:15:57 <dsr-grasbrunn> s/generat/generate/
09:17:27 <dsr-grasbrunn> Carlos: in the task model there is a single action to submit the data collected from the user.
09:18:53 <dsr-grasbrunn> ... some confusion ensues
09:19:53 <dsr-grasbrunn> Joelle the mapping from the task model to the final UI is not one to one.
09:19:56 <Nick_Kaklanis> Nick_Kaklanis has joined #mbui
09:20:13 <Nick_Kaklanis> Present+ Nick_Kaklanis
09:20:53 <dsr-grasbrunn> Jaroslav: you can't revert a submit (semantics are transactional)
09:22:53 <dsr-grasbrunn> Present+ Dave, Paolo, Fabio, Heiko, Nick, Michael, Carlos, Joelle, Gaelle, Davide
09:23:07 <dsr-grasbrunn> Regrets: Jean, Gerrit
09:24:26 <dsr-grasbrunn> Dave thinks the discussion is mostly about the domain model ...
09:25:53 <dsr-grasbrunn> and the ordering semantics imposed by it
09:26:41 <dsr-grasbrunn> Fabio: how do we want to proceed (as we are running short of time for this agenda item)
09:27:43 <dsr-grasbrunn> Heiko: so the plan is to use a single use case consistently across our documents, right?
09:27:53 <dsr-grasbrunn> Fabio: yes
09:28:41 <dsr-grasbrunn> Carlos: we could have further use cases, although in less detail
09:31:03 <dsr-grasbrunn> We discuss the initial wording for motivating the car rental use case
09:31:18 <dsr-grasbrunn> Joelle volunteers to draft the context of use
09:32:22 <dsr-grasbrunn> 1. The user is at home at her PC.
09:33:14 <dsr-grasbrunn> 2. The user is walking fast along a quiet street with her smart phone
09:34:57 <dsr-grasbrunn> Fabio: if you are walking fast your attention is not on the screen.
09:35:38 <dsr-grasbrunn> Joelle: let's now look at the task model ...
09:36:39 <dsr-grasbrunn> Dave: the task model needs to relate to the domain model at some level
09:37:28 <dsr-grasbrunn> Gaelle invites Jaroslav to describe the task model
09:38:44 <dsr-grasbrunn> n.b. for the second context of use, we anticipate the use of vocal interaction with the smart phone.
09:39:38 <dsr-grasbrunn> Jaroslav: you should put the most important task first ...
09:40:34 <dsr-grasbrunn> Fabio: at the task level should avoid unnecessary details, as these should be added at the concrete UI level for the target platforms.
09:40:53 <dsr-grasbrunn> s/level/level, you/
09:45:42 <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.
09:46:24 <dsr-grasbrunn> You typically pick up and drop off the car from a Hertz site, e.g. an airport or railway station.
09:47:16 <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.
09:47:54 <dsr-grasbrunn> Heiko: we should look a simplified use cases based upon real world examples.
09:48:22 <dsr-grasbrunn> s/look a/look at/
09:50:57 <dsr-grasbrunn> Paolo suggests refining task models based upon the availability of resources and the constraints that apply to them.
09:52:09 <dsr-grasbrunn> Fabio: some transformations for particular constraints can be done at the task level or at lower levels.
09:54:57 <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.
09:55:40 <dsr-grasbrunn> Joelle: it needs to specify who, what, when and where.
09:57:19 <dsr-grasbrunn> Dave: what covers the type of car, options such as booster seats for small children, and insurance options.
09:59:14 <dsr-grasbrunn> Gaelle: the main tasks cover expressing what you want, making a selection, reviewing the details, then making the payment.
10:05:00 <dsr-grasbrunn> We use the Hertz website as a guide to constructing our simplified task model
10:05:28 <dsr-grasbrunn> Joelle: you first need to specify where and when, but these tasks are not ordered.
10:07:57 <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?
10:16:02 <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.
10:22:24 <dsr-grasbrunn> Joelle and Gaelle present their proposal for the task model
10:23:05 <dsr-grasbrunn> Dave notes that task models can be decomposed into modular design exercises done by different teams.
10:24:03 <dsr-grasbrunn> We don't need to cover everything in a single task model.
10:25:42 <dsr-grasbrunn> Joelle: the what booking task subdivides into where, when and what which need to precede the pay task
10:30:11 <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.
10:32:53 <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.
10:35:53 <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.
10:36:34 <dsr-grasbrunn> Fabio: we could add that in the next update the the task model specification.
10:37:21 <paolo> Paolo: we could characterise the tasks in terms of the resources they make available to the process in their post-conditions
10:39:00 <dsr-grasbrunn> Dave asks for how we want to address the less likely case of users wanting to drop off at a different location?
10:39:15 <dsr-grasbrunn> Fabio: we can make that into an optional task.
10:39:27 <dsr-grasbrunn> rrsagent, make minutes
10:39:27 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/10-mbui-minutes.html dsr-grasbrunn
10:41:21 <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
10:41:23 <sfeu> sfeu has joined #mbui
11:56:47 <hbraun> davide_: ping
11:56:57 <hbraun> davide_: we are about to continue
11:57:43 <dsr-grasbrunn> ... we break for lunch
11:59:53 <dsr-grasbrunn> Topic: What is left to do on the Introduction to MBUI?
12:00:23 <dsr-grasbrunn> Improve the consistency. Update the use case based on the morning's discussion.
12:02:43 <dsr-grasbrunn> Jaroslav has made some notes on the white board diagram for the car rental task model provided by Joelle and Gaelle.
12:04:17 <dsr-grasbrunn> Dave notes that Hertz only shows the cars they reckon will be available from your selected pick up location and date.
12:04:53 <dsr-grasbrunn> Jaroslav: so there is a dependency ordering on the tasks.
12:06:04 <dsr-grasbrunn> Joelle the commit and pay task is a critical task as it can't be back tracked,
12:07:01 <dsr-grasbrunn> Action: Jaroslav to draw an updated CTT diagram and circulate the exported XML file by  end of 10 July 2013
12:09:53 <dsr-grasbrunn> Heiko: do we need to include an explicit domain model?
12:10:55 <dsr-grasbrunn> Dave: I think this would be considered important by Web developers who are very much interested in the boundary from the user interface and the back end application information systems.
12:11:36 <dsr-grasbrunn> s/from/between/
12:13:24 <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.
12:15:53 <dsr-grasbrunn> In my opinion the domain, task and abstract ui models should be in the same document for the convenience of readers.
12:17:08 <dsr-grasbrunn> Gaelle: should we have a new document just for the case?
12:17:53 <dsr-grasbrunn> Joelle: so all the models are extracted from the other documents and referenced.
12:18:09 <dsr-grasbrunn> Gaelle: we could then have separate documents for each use case.
12:19:31 <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.
12:28:02 <dsr-grasbrunn> Dave: the introductory document should be readable on its own.
12:28:21 <dsr-grasbrunn> Gaelle asks Dave to create a new document for the car rental study
12:28:53 <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/
12:29:44 <Nick_Kaklanis> Nick_Kaklanis has joined #mbui
12:31:59 <dsr-grasbrunn> Fabio: we need to decide on next steps ...
12:33:19 <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.
12:33:31 <dsr-grasbrunn> Joelle: I will work on it this evening.
12:34:30 <dsr-grasbrunn> Fabio: I think we can now proceed to other agenda items.
12:34:40 <dsr-grasbrunn> Topic Updating the Task model specification
12:37:40 <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".
12:38:34 <dsr-grasbrunn> Dave: we should then aim to push out an updated public working draft.
12:38:57 <dsr-grasbrunn> We can later move to a last call working draft once the working group notes have been published.
12:39:30 <dsr-grasbrunn> Fabio: ISTI will update the html version that was previously published.
12:39:53 <dsr-grasbrunn> Dave: thanks - it was a lot of work to generate clean HTML from the google doc, so that is much appreciated.
12:40:57 <dsr-grasbrunn> Fabio: the specification is now structured to make it easier to add new task types.
12:42:20 <dsr-grasbrunn> Action: Fabio and colleagues to provide an updated draft by the next teleconference (July 19)
12:42:53 <dsr-grasbrunn> Topic: The Abstract UI meta model specification
12:43:08 <dsr-grasbrunn> see https://docs.google.com/document/d/1UGZz_xaPuSbMtRb4a-14tM9CM8tHmbEWuLVuNNnx25o/edit
12:43:59 <dsr-grasbrunn> Vivian provides a short status report.
12:46:06 <dsr-grasbrunn> Carlos: where is the output event for when the system provides info back to the user?
12:46:30 <dsr-grasbrunn> Heiko: we have a DataInputOutput event that can be used for that.
12:47:06 <dsr-grasbrunn> Paolo: we aren't aiming to be comprehensive in the set of events, what you see are essentially examples.
12:48:00 <dsr-grasbrunn> Joelle: we have a distinction between interactors and events
12:49:14 <dsr-grasbrunn> Heiko: what was the motivation to merge the input and output event?
12:49:57 <dsr-grasbrunn> Paolo: the description makes the purpose clear: to support data input, output or both.
12:51:03 <dsr-grasbrunn> You could say it is too general, but I don't see it as a problem
12:51:20 <dsr-grasbrunn> s/it as/that as/
12:52:22 <dsr-grasbrunn> Fabio: is the resource model explained here?
12:52:33 <dsr-grasbrunn> Paolo: you're right, it is missing
12:52:53 <dsr-grasbrunn> Jaroslav: Paolo could you provide one?
12:54:52 <hbraun> the uml diagrams are kept here:  http://code.google.com/p/mbui-diagrams/ t
12:57:29 <dsr-grasbrunn> Dave: I've added a link to it from the wiki page for editor's drafts
12:58:24 <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
13:02:36 <dsr-grasbrunn> We discuss the attribute "isCompound" which essentially means whether the interaction unit is composed from lower level components.
13:04:20 <dsr-grasbrunn> s/means/signals/
13:04:54 <dsr-grasbrunn> Jaroslav: are they any methods to get the compound components?
13:05:05 <dsr-grasbrunn> Fabio: no, we should add them
13:05:32 <dsr-grasbrunn> Heiko: the attribute seems redundant, right
13:05:53 <dsr-grasbrunn> Gaelle: yes, you're right
13:07:35 <dsr-grasbrunn> .... Davide rejoins remotely on the audio bridge
13:09:29 <dsr-grasbrunn> Gaelle: we are losing flexibility with the current meta model for composition.
13:10:43 <dsr-grasbrunn> Paolo: if we leave composition to the task model, we lose flexibility.
13:11:26 <dsr-grasbrunn> Gaelle: the task model is rigid (e.g. in its set of temporal operators), here in the AUI we need greater flexibility.
13:16:12 <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.
13:17:28 <dsr-grasbrunn> Fabio: would the latter make sense?
13:19:54 <dsr-grasbrunn> Paolo steps up to the board to clarify his point about the rigidity of the current decomposition meta model for tasks
13:21:18 <dsr-grasbrunn> Gaelle: composition should be a common pattern for the meta-models across the levels in the Cameleon framework
13:24:54 <dsr-grasbrunn> Gaelle: composition is an entity per se that is made explicit at all levels of models
13:25:14 <dsr-grasbrunn> Jaroslav: do we have an operator then for this?
13:26:27 <dsr-grasbrunn> s/then for/for/
13:26:55 <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
13:29:04 <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
13:31:33 <dsr-grasbrunn> Gaelle: I want to remove the attribute useCaseCoverage
13:32:32 <fabio> fabio has joined #mbui
13:33:02 <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?
13:33:43 <dsr-grasbrunn> Paolo: we may not want to bind to use cases in all situations.
13:34:06 <dsr-grasbrunn> Fabio: useCaseCoverage sounds like a documentation concept.
13:35:44 <dsr-grasbrunn> Joelle reads out the descriptions of the attributes on AbstractInteractionUnit
13:36:21 <dsr-grasbrunn> Fabio: securityLevel seems similar to "critical" for task models.
13:37:00 <dsr-grasbrunn> Vivian: security can be used in relation to access control - locking down which users can access what features.
13:37:36 <dsr-grasbrunn> Carlos: why a five point security scale?
13:38:25 <dsr-grasbrunn> Dave: I would have thought that for access control you want names that you can related to access control policies
13:38:31 <dsr-grasbrunn> s/related/relate/
13:39:28 <dsr-grasbrunn> Gaelle: these attributes are here to allow people to start by designing the AUI and then to come up with the task model.
13:39:41 <dsr-grasbrunn> s/then/later/
13:40:00 <dsr-grasbrunn> rrsagent, make minutes
13:40:00 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/10-mbui-minutes.html dsr-grasbrunn
13:40:54 <dsr-grasbrunn> Heiko: companies vary considerably in how they deal with security.
13:41:16 <dsr-grasbrunn> We also have to consider privacy ...
13:42:21 <dsr-grasbrunn> Gaelle: perhaps we need a generic mechanism for annotations and allow for extensibility
13:43:37 <dsr-grasbrunn> Joelle: who wants to volunteer to update the AUI metamodel?
13:45:16 <dsr-grasbrunn> I would rather we updated it right now, right here!
13:46:23 <dsr-grasbrunn> Gaelle summarises her proposal for the new framework for the meta model
13:49:54 <dsr-grasbrunn> Paolo volunteers to try to capture this in words for the minutes.  Discussion ensures on the details.
13:50:25 <paolo> Gaelle: all the metamodels, no matter their level of abstraction, are based on the following conventions:
13:50:37 <dsr-grasbrunn> Paolo notes that instantiation is needed not subclassing for that would give the wrong kind of flexibility.
13:51:24 <paolo> there are entities, these are composed through a Composition classes, and there is a mechanism for annotating entities with domain-specific levels
13:52:12 <paolo> all the other metamodels realise these mechanisms
13:53:12 <gaelle> gaelle has joined #mbui
13:54:41 <dsr-grasbrunn> rrsagent, make minutes
13:54:41 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/10-mbui-minutes.html dsr-grasbrunn
13:55:05 <joelle_> joelle_ has joined #mbui
13:55:26 <dsr-grasbrunn> rrsagent, make minutes
13:55:26 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/10-mbui-minutes.html dsr-grasbrunn
14:00:54 <dsr-grasbrunn> Gaelle: draws the updated meta model on the flip chart
14:01:02 <dsr-grasbrunn> Paolo: I am updating the model electronically.
14:22:56 <gaelle> 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)
14:24:36 <gaelle> 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
14:25:32 <Nick_Kaklanis> 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
14:31:37 <gaelle_> gaelle_ has joined #mbui
14:37:54 <dsr-grasbrunn> we resume after a coffee break while the editors are busy updating the AUI meta models.
14:38:03 <dsr-grasbrunn> Paolo presents the new meta model.
14:39:23 <dsr-grasbrunn> Gaelle asks Paolo to provide examples.
14:42:13 <dsr-grasbrunn> 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.
14:42:39 <dsr-grasbrunn> Perhaps we should spend a little time on the personas for the people we want to read our documents?
14:44:08 <dsr-grasbrunn> Paolo steps up to the screen whilst asking Vivian to make changes to the naming of the components in the UML editor.
14:46:26 <dsr-grasbrunn> The grey boxes are generic and used for annotatons. The yellow(?) boxes are specific to the AUI
14:47:10 <hbraun> dsr-grasbrunn: can you remind of printing later on, when we finished todays session?
14:53:06 <dsr-grasbrunn> Topic: The Glossary
14:53:24 <dsr-grasbrunn> Fabio: lets put a finish time of 5:30pm for this session.
14:54:04 <dsr-grasbrunn> Jaroslav: one general question is how to handle abbreviations, as this hampers readability
14:54:54 <dsr-grasbrunn> Fabio: usually these are put somewhere
14:55:25 <dsr-grasbrunn> Jaraslav: an example is the use of AIU for abstract interation unit.
14:55:54 <dsr-grasbrunn> I would just expand these abbreviations.
14:55:54 <dsr-grasbrunn> Dave agrees
14:56:02 <dsr-grasbrunn> General agreement around the room
14:57:33 <dsr-grasbrunn> We do however need to define the common abbreviations used in our other documents.
14:58:03 <dsr-grasbrunn> Jaroslav: how to treat citations and references as there a lot of them
14:58:14 <dsr-grasbrunn> Fabio: I would remove them
14:59:38 <dsr-grasbrunn> In the short term Jaroslav will move the references into a new column so that we don't lose them
15:00:54 <dsr-grasbrunn> Jaroslav asks Joelle to review the terms migratory UI, nomadic UI and plastic UI
15:03:38 <dsr-grasbrunn> See Jaroslav's recent emai: http://lists.w3.org/Archives/Public/public-mbui/2013Jul/0009.html
15:08:22 <dsr-grasbrunn> Jaroslav would like to have a column with synonyms and related words in the published document.
15:08:54 <dsr-grasbrunn> Gaelle: what is the norm for glossaries in W3C?
15:09:33 <dsr-grasbrunn> 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!
15:20:20 <dsr-grasbrunn> we discuss the wording of the glossary items one by one.
15:21:09 <dsr-grasbrunn> 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,
15:21:56 <dsr-grasbrunn> Gaelle: we should recommend certain terms for a consistent way of talking about model-based design.
15:24:44 <dsr-grasbrunn> Dave notes that the current wording for "Abstraction" is too hard for the target audience and as such needs rewriting into something simpler.
15:26:37 <dsr-grasbrunn> 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.
15:32:44 <sfeu> sfeu has joined #mbui
15:33:05 <dsr-grasbrunn> We continue through the terms ...
15:33:29 <dsr-grasbrunn> (note we've reached the 5:30pm local time deadline we planned to stop)
15:36:24 <dsr-grasbrunn> we agree to continue to 6pm
15:56:27 <davide_> the call dropped, I'm leaving now... See you tomorrow
16:21:44 <hbraun> hbraun has joined #mbui
17:01:12 <dsr-grasbrunn> dsr-grasbrunn has joined #mbui