[Ux] [Architecture] Preference term for auto-adjustment to context change

Dana Ayotte dana.ayotte at gmail.com
Mon Mar 16 15:47:50 EDT 2015


Hi Andrés,

Could you give an example of what you mean by "try a finer configuration" (Advanced option)? Is this the same as the "try different" concept introduced by Gregg (and shown in the wireframes)? I don't understand your distinction between "decision" and "recommendation" here.

http://wiki.fluidproject.org/download/attachments/34570511/PCP%20MM%20feedback%20for%20review.pdf

Also, at some point I think we need to discuss how this all relates to context-dependent preference sets. For example, once a user selects "always do this" for a given MM recommendation/auto-adjustment, this could potentially create and populate a preference set for that context. Does it make more sense for some adaptations to happen only at the individual preference level, and some to trigger the creation of a preference set?

Also, my understanding of the the auto-adjust on/off preference is that it was intended to demonstrate a basic level of functionality for the review only. 

Thanks,
Dana

On Mar 12, 2015, at 6:42 AM, Andrés Iglesias Pérez <aiglesias at consultoria.ilunion.com> wrote:

> I like a lot your idea of sending an email every month just to be sure that the user didn’t set anything inadvertently. It’s also cohesive with our “mail for later on” approach to be able to suggest new AT’s out of the situation of stress of the user in the field.
>  
> I’d like to see in the dialog yet another option, so finally it would appear:
> Yes - please do this
> Always do this - don’t ask me each time 
> (this can later be made more specific
> Always do this when (context is described)
> No - don’t do this
> Never - do this.  and don’t ask again.
> (this can later be made more specific
> Never do this when (context is described)
> Never do this.      
> Advanced – I will try a finer configuration, if I cannot use it, it will revert to the basic one automatically.
> Then once a month or three we send a note 
> "These are the automatic features you have turned off (or on) permanently.   We send out an email every month just to check to be sure that these are correct.  If this looks fine you can just ignore this.  If you want to change anything - just click on it and you will be able to change it online. "
>  
> The rationale of the “Advanced” option is to go beyond the “Decision” part of the Matchmaker and try to apply one of the “Recommendations”. Now that we have a TemporalReporter in place, we can set a timer to revert the changes if no OK has been given after a certain amount of time (cannot be fixed, as some users would require more time to say OK than others)
>  
> +1,000,000 to test this with a Wizard of Oz in the pilots.
>  
> Kind regards,
> Andres Iglesias-Perez
> Tech Accessibility, Studies and R&D
> Researcher
> Tel: 0034 91 121 0330
> Email: aiglesias at consultoria.ilunion.com
> <image001.png>
>  
>  
> De: ux-bounces at lists.gpii.net [mailto:ux-bounces at lists.gpii.net] En nombre de Gregg Vanderheiden
> Enviado el: miércoles, 11 de marzo de 2015 19:45
> Para: Christophe Strobbe
> CC: GPII UX; architecture at lists.gpii.net Architecture
> Asunto: Re: [Ux] [Architecture] Preference term for auto-adjustment to context change
>  
> I think 
> that we architecturally should be able to handle turning off any “automatic” or  “MatchMaker Suggestions”. 
> that the easiest way for a user to understand this is via a dialog (ala Dana)
> Dialog makes the suggested change and has the following choices at the bottom of the suggestion
> Yes - please do this
> Always do this - don’t ask me each time 
> (this can later be made more specific
> Always do this when (context is described)
> No - don’t do this
> Never - do this.  and don’t ask again.
> (this can later be made more specific
> Never do this when (context is described)
> Never do this.      
> Then once a month or three we send a note 
> "These are the automatic features you have turned off (or on) permanently.   We send out an email every month just to check to be sure that these are correct.  If this looks fine you can just ignore this.  If you want to change anything - just click on it and you will be able to change it online. "
>  
> For the next pilot — I think it would be good to test this - even if the plumbing isnt all in place.   we can  WoZ it and get good feedback on the idea and the language. 
>  
> thoughts? 
>  
> 
> gregg
>  
> ----------------------------------
> Gregg Vanderheiden
> gregg at raisingthefloor.org
>  
>  
> 
>  
> On Mar 11, 2015, at 7:34 AM, Christophe Strobbe <strobbe at hdm-stuttgart.de> wrote:
>  
> Hi,
> 
> On 19 November, Nikos Dimokas sent a message to the Architecture mailing
> list to propose a new preference term to enable or disable
> auto-adjustment to context changes (e.g. ambient noise or light)[1].
> Agreement on this preference term is necessary to finalise a pull
> request to the PMT repository (see below). 
> 
> Gregg thought this preference should not be global but work at the level
> of individual preferences [2]. Any setting that the MM might propose to
> change in response to a context change would need to have an option to
> enable this auto-adjustment, e.g. [3]:
> * volume based on sound level
> * captions based on sound level
> * brightness based on brightness
> * anything based on fatigue level (measured or reported)
> * based on time
> * based on task
> 
> Andres mixed the e-mail thread with the one about the feedback from the
> second pilot [4].
> Andy thought that excluding specific adaptations would not be a good
> approach: it would be easy to accidentally disable auto-adjustment for
> e.g. the TVM and then to find out later that the TVM does not respond
> context changes without knowing/remembering why.[5]
> Dana said this could be addressed by providing an option like "don't ask
> me again on this device". [6]
> 
> And that was the end of the thread.
> 
> So what will be our course of action? I see several options:
> 1. Go with the global setting for the third pilot. This requires that we
> agree on a name (I propose "autoAdjustToContextChange") and a value
> range. Nikos can then finalise pull request
> <https://github.com/GPII/prefsEditors/pull/84> for JIRA ticket
> GPII-1023. In addition, we may consider creating wireframes for the
> granular version proposed by Gregg and get feedback on them during the
> third pilot.
> 2. Design and implement the granular autoAdjustToContextChange option
> proposed by Gregg. However, I think this is not realistic for the third
> pilot and that we need to defer this until after the pilots.
> 3. And now that I got here, I forgot what the last option was. I'll have
> to ask Dr. Alzheimer.
> 
> 
> Best regards,
> 
> Christophe
> 
> 
> [1] <http://lists.gpii.net/pipermail/architecture/2014-November/002941.html>
> [2] <http://lists.gpii.net/pipermail/architecture/2014-November/002947.html>
> [3] <http://lists.gpii.net/pipermail/architecture/2014-November/002956.html>
> [4] <http://lists.gpii.net/pipermail/architecture/2014-November/002957.html>
> [5] <http://lists.gpii.net/pipermail/architecture/2014-November/002958.html>
> [6] <http://lists.gpii.net/pipermail/architecture/2014-November/002982.html>
> 
> -- 
> Christophe Strobbe
> Akademischer Mitarbeiter
> Responsive Media Experience Research Group (REMEX)
> Hochschule der Medien
> Nobelstraße 10
> 70569 Stuttgart
> Tel. +49 711 8923 2749
> 
> “It is possible to make a living making free software for freedom 
> instead of closed-source proprietary malware for cops.” 
> Jacob Appelbaum, 
> <http://dissenter.firedoglake.com/2012/12/28/jacob-appelbaum-on-resisting-the-surveillance-state/>
> 
> _______________________________________________
> Architecture mailing list
> Architecture at lists.gpii.net
> http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture
>  
> _______________________________________________
> Ux mailing list
> Ux at lists.gpii.net
> http://lists.gpii.net/cgi-bin/mailman/listinfo/ux

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/ux/attachments/20150316/4d93fddc/attachment-0001.html>


More information about the Ux mailing list