<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

What is left to do on the Introduction to
MBUI?

<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> 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> 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> 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.