Cloud4all WP204/WP205 Meeting on 2014-04-04

From wiki.gpii
Jump to: navigation, search


Telephone Bridge

1. To talk free using the Web click: Be sure to set AUDIO to Mic and Speaker (VoIP) - a headset is recommended.

Important Information for the Meeting

This is a meeting of WP204 and WP205 (Matchmaker) within the European Project Cloud4All. However, the minutes of the meeting will be made available to the public to allow people outside Cloud4All to follow the development of the matchmaker. If, in the meeting, you want to share confidential information that should not appear in the public minutes, you need to state so in the meeting. This is in line with the Cloud4All Consortium Agreement, section 10.


  • Andy
  • Ignacio
  • Kasper
  • Claudia
  • Dana
  • Javi
  • Jess
  • Nick
  • Christophe

Minutes of Previous Meetings

Matchmaker Feedback Loop


The Google Docs is a collection of potential functions in the feedback loop. They are based on the assumption that when the users encounters a new context (new device, environment, manual setting change), the matchmaker would infer new preferences as recommendations for the user. If the user is on the same device & context as previous, time the previous settings can be applied again.

E.g. R1: Transparency: The user should be able to inspect the settings; cf the PCP.

Main question for Architecture seems to be whether it is possible to distinguish between old and new contexts.

The context can partially be dealt with by the Mini-Matchmaker; in that case, the architecture does not necessarily know about a new context?

R1: Transparency

Matchmaker would return decisions and/or recommendations. Decision implies that the settings are implied directly; recommendations means that they are proposed to the user, who decides whether they should be applied.

User can also be provided with information about shortcuts and other info for using a solution.

Store: Inferred preferences don't become real preferences until they have been confirmed by the user. Then they would be stored as real preferences in the Preference Set.

"Inspect" is not the same as "preview"? Inspect: display what would be applied to the systems, i.e. the actual values. We need to think about whether this would make much sense to users. The previews each show a subset of what would be applied to the system.


We need a mechanism to display inferred preferences.

A button may enable the user to say they like the current system and they want to store this configuration. This works well for things that users like, but it is harder to deal with things that the user does not like. A like-vs-dislike feedback makes it hard to find what needs to be changed, especially for the rule-based matchmaker. (So like/dislike is not informative enough.)

Andy: We could store the info that user X likes config Y in context Z with "context Z" as a part of a condition, and then analyse these data?

Claudia: May work for the statistical matchmaker, but the rating does not really help for the rule-based matchmaker, especially if the rating is not positive.

Dana: If the feedback would be settings tweaked by the user. I.e. let the user choose "I like this" or "I want to tweak this".

Claudia: Yes, that would work.

Andy: Like/dislike instead of ratings?

See also Gregg's concept of "try different" or "try harder" (March 2013, now captured in two JIRAs so they won't get lost: GPII-696 and GPII-697).

Andy: (...) Poke the MM with "dislike" or "try harder" and have the MM return a "form" that allows people to provide feedback on specific active preferences. Use the info that the user has already often change an inferred setting (e.g. font size) to another value. The STMM already gives confidence values to each inferred setting.

Andy: Another option is to flag certain preferences as "uncertain" in the UI.

Preview and Test

Adopt This is implicit feedback to the matchmaker - ...

Discard Rejection of inferred preferences would be feedback to the matchmaker, i.e. "don't recommend this again".


Override & Turn Off "Meta-preferences": override recommendations; turn off recommendations.

Andy working on matchmaker flow diagrams. Prefers to keep things simple and to avoid bi-directional communication between user UI and matchmakers because this works against the idea of loosely coupled components.

Google Doc will serve as input for the flow diagrams.

See also the ideas for in-context recommendations in page for in the PMT designs.

Next Meetings and Topics

  • Next meeting: ?

Previous meetings: see Matchmaker Meetings.