notes and decisions from the matchmaker meeting

Wed Jan 16 12:17:24 UTC 2013

Thanks, Vivien! Let's talk at 9:30 EST - 3:30 CET.

Tona

On Wed, Jan 16, 2013 at 12:26 PM, Melcher, Vivien <
Vivien.Melcher at iao.fraunhofer.de> wrote:

>  Hi all, ****
>
> ** **
>
> during our meeting last Friday with Gottfried, the following topics were
> discussed and the following answers given and conclusions drawn: ****
>
> ** **
>
> When is a preference set created and when should it be available for
> editing in the preference managemetn tool? ****
>
>              starting from the user’s first (“basic”, “general” or
> whatever) preference set, and based on statistical data, the statistical
> matchmaker deduces preferences for new devices. When the user confirms the
> newly deduced /created preferences, then a new preference set is created
> and stored in the preference server, and consequential a new preference set
> should be shown in the preference management tool.****
>
> ** **
>
> Device handler: The device handler provides the characteristics of the
> used device. This includes device class, device type (e.g. iPhone 4 or
> iPhone 5), OS, installed software up to the registration number of the
> device. This means, theoretically every device could be presented with its
> own preference set. Of course, the preference set for iPhone 4 and iPhone
> 4s would be very similar. Because of this reason and taking into account
> how complex the system would be if we would provide preference sets for
> every single device, we decided to just support previews of device
> classes.  ****
>
> ** **
>
> Question 2) how could the statistical matchmaker support automated
> “themes”?****
>
> Briefly, the matchmaker creates single decisions about each interface
> component in an individual way at each time of use. The stat. matchmaker
> does not create anything alike a preference set, it rather creates
> continously changing associative relation, comparable to clouds of dots.
> Thus, these results of the stat. matchmaker cannot be displayed as rules,
> as this would be highly inconsistent to the user. So, these dynamic
> conditional preferences are not provided in the preference management tool.
> But there will be the possibility to simulate automatic conditional
> preferences, This enables the user to see how his/her personalized
> preferences would behave in case of changing conditions. ****
>
> ** **
>
> There will be a function of the matchmaker, directly embedded in the
> preference management tool (or any other form of technical connection).
> This will make it possible to get a preview of what the preferences do (in
> nearly real-time) on the distinct end-devices. This changes something about
> the UI of the tool: Now, the user does not need to select specific
> preference sets but he gets straight to the “manage” page where he can
> change between device classes (single devices). The preview refers to the
> actual configuration of the preferences, as well as to the “conditions”
> under the influence of which the user is viewing the device (conditions
> are, for example: Time, Brightness of surroundings, surrounding noise
> level). Using an interaction operator, different conditions can be
> simulated (for example, dragging the brightness slider down to simulate
> darkness). Thus, the user can check what the interface would look like
> under these circumstances.  This indicates, that there will be a permanent
> data transfer between the matchmaker and the preference management tool.**
> **
>
> ** **
>
> As many aspects of the matchmaker have not been defined yet, we are
> required to work with some “dummy” parameters now (like brightness),
> independently of whether it will later be used or exchanged for another
> one. Right now, we have decided to show only device-classes, although we
> might go to “device specific” later. That shouldn’t change the overall
> interaction routine. The preview will only be visible for the selected
> device classes (for example: The PC if the user is using the
> pref.management tool on his PC). Thus, there will not be a need for a
> so-called “basic” preference set that spans several devices but only
> device-specific profiles. ****
>
> ** **
>
> Themes will be a button next to history that will lead to a different
> screen. In our internal discussions we realized that the theme creating and
> editing process is too complex to have a solution by Friday (this is the
> deadline for the internal deliverable), so I decided to limit the 'theme'
> part  in ID102.1 to just a short description of what themes are, that there
> will be a button and that this button will lead to a different screen where
> the user can view, edit, delete, and create a theme. The detailed
> development of the UI will be part of ID102.2. ** **
>
> ** **
>
> Furthermore there won’t be a basic preference set anymore. The first
> preference set the user creates using the preference management tool will
> be assigned to the device class. For example, the user uses the wizard on
> his personal computer to create the first preference set. In this case the
> preference set will be assigned to the class “PC”. If the user (like
> George) wants to take over a setting change for all devices, he could, for
> example select an option on the floating panel that is called “all devices”
> (the opposite would be “only this device” – this could be default until the
> user selects the other option).****
>
> ** **
>
> An example for the simulation of conditional preferences shows the
> following figure****
>
> ****
>
> ** **
>
> I would propose to have the call at 3:30pm CET, then you have a bit more
> time to read all this stuff.****
>
> ** **
>
> Looking forward to hearing you,****
>
> ** **
>
> Vivien****
>
> ** **
>
> Dipl. Psychologin****
>
> Human Factors Engineering ****
>
> Fraunhofer IAO****
>
> Universität Stuttgart IAT****
>
> Nobelstr. 12****
>
> 70569 Stuttgart****
>
> Germany ****
>
> Tel:  +49 (0) 711 970 2173****
>
> Fax: +49 (0) 711 970 2213****
>
> ** **
>
> mailto: vivien.melcher at iao.fraunhofer.de****
>
> http://www.hfe.iao.fraunhofer.de/ ****
>
> ** **
>
> ** **
>
> -----Ursprüngliche Nachricht-----
> Von: Jess Mitchell [mailto:jessmitchell at gmail.com]
> Gesendet: Montag, 14. Januar 2013 16:11
> An: tona monjo
> Cc: Mitchell, Jessica; Vass, Joanna; Arash Sadr; Colin Clark; Krüger, Anne
> Elisabeth; Leuteritz, Jan-Paul; Melcher, Vivien; fluid-work List
> Betreff: Re: Notes from last Cloud4All meeting
>
> ** **
>
> Tona,****
>
> ** **
>
> This page is great! Joanna was also doing some sketching to clarify
> things. I imagine it would be helpful for us all to sync our sketches this
> week. Wonderful start!****
>
> ** **
>
> Jess****
>
> ** **
>
> ** **
>
> On Jan 14, 2013, at 9:59 AM, tona monjo <tonamonjo at gmail.com> wrote:****
>
> ** **
>
> > Hi all,****
>
> > ****
>
> > Since we are going deeper into Cloud4All features and behaviour, I've
> written down some notes from our last meeting. You will find them here: **
> **
>
> > ****
>
> > http://wiki.fluidproject.org/display/fluid/Cloud+for+All+-+exploratory**
> **
>
> > +meetings****
>
> > ****
>
> > Hope they can be useful. Please feel free to modify these notes, correct
> anything that may have been misunderstood, add new points, etc.****
>
> > ****
>
> > Thanks!****
>
> > ****
>
> > Tona****
>
> > ****
>
> > ****
>
> > _______________________________________________________****
>
> > fluid-work mailing list - fluid-work at fluidproject.org To unsubscribe, **
> **
>
> > change settings or access archives, see ****
>
> > http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work****
>
> ** **
>

-- 
Tona Monjo
LATENT, User Experience Design
http://www.latent-design.com
T (+34) 654 402 387
Skype: tona.monjo
Twitter: tona_monjo
Blog: *http://tonamonjo.net/*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130116/03adfab4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 91636 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130116/03adfab4/attachment.jpg>