[Architecture] Communication between Matchmaker and PCP

Andrés Iglesias Pérez aiglesias at technosite.es
Tue Apr 29 01:54:45 EDT 2014


Hi Colin,
Thanks for these references, I'll read it asap as they seem very meaningful to my task of adding environmental (contextual) conditions in the conditional format.

Regarding your question,
>> Andrés, I’m not following your terminological distinction between Decision and Recommendation. Can you step back and describe a bit more about what you’re considering? Is this intended to address the Matchmaker recommendation use case?

Does this excerpt from " [Ux] Minutes of the GREAT PCP/PMT PLANNING MARATHON" help?
"
Matchmaker Feedback (A205.1) 
Communcation line (some API) between MMs and PMT/PCP tools
Recommendation system: split MM feedback init decisions + recommendations + interaction help (decisions are automatically applied; recommendations require user confirmation)
Keep MM and PCP UI decoupled from each other, i.e. "lightweight communication"  between these two components. 
The RB-MM can split its output into decision+recomendation. Let's put an example here:
Andres is a blind user and the RB-MM doesn't know his preferred speech rate, voice and pitch.
In order to be accessible, the *decision* is to apply a Screen Reader. But the parameters are setted in a conservative way (slow speech rate, male voice, low pitch)
But based on '''put a reasoner schema here, e.g. close users in the same country''' the RB-MM thinks that the best parameters would be (fast speech rate, female voice, high pitch). Applying directly that settings could lead to a not accessible UI so they're passed to the PCP as *recommendation*
e.g. a combo-box with injected options, named "GPII preset 1" , "GPII preset 2" etc
Andres could as well adjust his settings one by one, but to make things easier to him the PCP offers that combobox
If Andres changes from "GPII preset 1" to "GPII preset 2" all these settings will be changed at the same time.
5-star rating system or some other means for users to guide the matchmakers in how well they did. Eg. a button saying "like" and "dislike", allowing users to change settings, etc.(A star-rating system alone would not be expressive enough for a matchmaker to find out what went wrong or what should be improved. Additional input from the user would be requested when the rating is bad.) A 5-star rating system does have this input loop anyway. Think in your skype evaluation on the quality of the conversation.

"

I may elaborate a further response. Nevertheless I'll explain that in Crete ;) And I'm aware that I'm absolutely behind schedule in updating the wiki (that remembers to me the joke "of course I'm a solipsist, aren't we all? :-D )

Full minutes at: http://lists.gpii.net/pipermail/ux/2014-April/000933.html 

Kind Regards,
--
Andrés Iglesias Pérez
Researcher @ R&D Department, Technosite,  Fundosa Group
C/ Albasanz, 16, 3ºB. 28037. Madrid. Spain
(0034) 91 121 03 30 


-----Mensaje original-----
De: Colin Clark [mailto:colinbdclark at gmail.com] 
Enviado el: lunes, 28 de abril de 2014 21:59
Para: Andrés Iglesias Pérez; amilchev at asteasolutions.com
CC: architecture at lists.gpii.net Architecture
Asunto: Re: [Architecture] Communication between Matchmaker and PCP

Hi Andrés and Alexander,

In case it is helpful, here is a quick summary of how we’ve designed the interaction between the PCP and the Matchmakers so far, which covers the configuration of the available adjusters.

The Preferences Framework (with which the PCP is built) provides two declarative (i.e. JSON) specifications that describe all the information needed by the PCP to render a tailored set of adjusters for the current user. These are called the Primary and Auxillary Schemas. The overall approach is described in these wiki pages:

http://wiki.gpii.net/w/Preferences_Framework_Overview#How_Developers_Build_Preferences_Editors_Using_the_Framework
http://wiki.gpii.net/w/How_the_Preferences_Framework_Works

Examples of the schemas are included in the Preferences Framework documentation, which ships as part of Infusion:

http://wiki.fluidproject.org/display/docs/Primary+Schema+for+Preferences+Framework
http://wiki.fluidproject.org/display/docs/Auxiliary+Schema+for+Preferences+Framework

The PCP already uses a default instance of both of these JSON documents to render its user interface. Alex, you’re of course very familiar with these, but here are links for the benefit of others:

https://github.com/GPII/prefsEditors/blob/master/src/shared/schemas/js/primarySchema.js
https://github.com/GPII/prefsEditors/blob/master/src/shared/schemas/js/pcpSchema.js

These documents can be generated by a Matchmaker and sent to the PCP to render. We don’t yet have a communication channel to do this, but presumably we should define a new REST endpoint on the Flow Manager for the PCP to call. Alex is this communication channel something you’ve thought about at all?

To answer Gregg’s question about latency, I think the key is to not constantly re-render the user interface, but to do so at key-in time and then only when major changes are detected that may require a change in the PCP. A user would inevitably be confused by a UI that is constantly changing or shifting around. If we’re only rendering the PCP’s user interface rarely, latency shouldn’t be a concern.

Andrés, I’m not following your terminological distinction between Decision and Recommendation. Can you step back and describe a bit more about what you’re considering? Is this intended to address the Matchmaker recommendation use case?

Thanks,

Colin

On Apr 25, 2014, at 8:38 AM, Andrés Iglesias Pérez <aiglesias at technosite.es> wrote:

> Hi Alexander and all,
> 
> Should we talk about  how the interaction between the Matchmaker and PCP should be achieved for the first Milestone or for the final product?
> 
> I'm saying that because I'm missing the "Status bar" in your initial approach.
> 
> Regarding your specific proposals, i'm <AI/> hereinafter
> 	• will the MM provide user's needs (e.g. "low vision") or directly suggest adjusters to be shown (e.g. Contrast, Magnification)? I suggest the second choice since compactness is what PCP is primarily aiming for.
> 		• <AI> Actually we have *forbidden* to send such a specific info about the user. We send the settings. I'm fostering the split of what we send between Decision+Recommendation (+ 2 more out of scope here). The Decision part is what is setted directly, so there's no need to communicate it to the PCP provided that the PCP is scanning the current settings of the device (otherwise we'll be in trouble if the user sets something out of the PCP) and the Recommendation part is kind of a recipe to adjust several settings in a snap (I call it "to inject an option in a combobox but the final form will be decided by the UX'ers. </AI>
> 	• if so, will the MM inform of specific adjusters or whole adjuster groups?
> 		• <AI> decision->specific adjusters to the UI-less component that actually performs the changes in the user device. recommendation -> it's still open to discussion (as everything indeed) but I can imagine a tuple (string in human-friendly language to show, json that the PCP can recognize to provoke the subsequent adjustments in the UI) </AI>
> 	• will the PCP inform of the rating selected by the user only or both the rating + the final set of adjuster values he/she has left? I suppose again the second option is more reasonable here.
> 		• <AI> Whatever the final form, the rating is intended to bridge the gap between the users that leave without touching any setting just because it didn't fit their needs and the users that adjust manually every tiny detail. It's easier to press a button to say "Hey I don't like that UI" than to spend 15+ minutes adjusting the settings, doesn't it? 
> 		• So you should expect the user to employ just one of the two 
> options. Moreover I will send the rating as soon as it is provided, 
> rather than waiting for more actions of the user. That's like an 
> ultimatum to us in order to "Try harder"(tm) </AI>
> 
> We should think of the best way to create a proper pipeline between MM and PCP, through which we'll perform the communication in both directions. After that, we need to discuss the exact format in which the messages will be sent.
> 
> <AI>Socket.io is my best candidate, keeping in mind that when you only 
> have a hammer everything around starts looking like a nail
> 
> Thanks for opening this discussion ツ
> 
> 
> </AI>​
> 
> --
> Andrés Iglesias Pérez | Andres Iglesias-Perez Investigador  I+D+i | 
> R&D Researcher Departamento de I+D+i | R&D Department Dirección de 
> Tecnologías Accesibles e I+D+i | Accessible Technology and R&D&i 
> Management Technosite, Grupo Fundosa | Fundosa Group C/ Albasanz, 16, 
> 3ºB. 28037. Madrid. Spain
> Tel:             +34 91.121.03.30     
> Fax: +34 91.375.70.51
> aiglesias at technosite.es
> De: architecture-bounces at lists.gpii.net 
> <architecture-bounces at lists.gpii.net> en nombre de Alexander Milchev 
> <amilchev at asteasolutions.com>
> Enviado: viernes, 25 de abril de 2014 14:01
> Para: strobbe at hdm-stuttgart.de; claudia.loitsch at tu-dresden.de
> Cc: architecture at lists.gpii.net Architecture
> Asunto: [Architecture] Communication between Matchmaker and PCP
>  
> Hi Claudia, Christophe and all,
> 
> I'm creating this thread with the idea to open a discussion on how the interaction between the Matchmaker and PCP should be achieved.
> 
> "Interaction" here stands for these two major moments:
> 	• From MM to PCP: The set of adjusters that PCP shows should correspond to the currently logged user's needs. This means that the Matchmaker should provide this information to PCP in some way. Additional questions may be:
> 		• will the MM provide user's needs (e.g. "low vision") or directly suggest adjusters to be shown (e.g. Contrast, Magnification)? I suggest the second choice since compactness is what PCP is primarily aiming for.
> 		• if so, will the MM inform of specific adjusters or whole adjuster groups?
> 	• From PCP to MM: The PCP will provide the user rating system, which currently is under discussion, as far as I know between 5 star or like/dislike. In any case, the PCP is responsible for bringing this feedback to the Matchmaker.
> 		• will the PCP inform of the rating selected by the user only or both the rating + the final set of adjuster values he/she has left? I suppose again the second option is more reasonable here.
> We should think of the best way to create a proper pipeline between MM and PCP, through which we'll perform the communication in both directions. After that, we need to discuss the exact format in which the messages will be sent.
> 
> Looking forward to your thoughts on this.
> 
> Best,
> Alexander
> 
> --
> Alexander Milchev
> First Level Software Engineer
> Astea Solutions AD
> 
> The information in this e-mail and any accompanying files is intended only for the recipients named above. This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended recipient, you may not download, copy, disseminate, distribute or use in any way the information in this e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please notify Astea Solutions AD immediately by reply e-mail, and delete this e-mail and any copies of it.
> _______________________________________________
> Architecture mailing list
> Architecture at lists.gpii.net
> http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture




More information about the Architecture mailing list