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

Gregg Vanderheiden gregg at raisingthefloor.org
Wed Mar 11 14:44:47 EDT 2015


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/ux/attachments/20150311/a7336d3e/attachment.html>


More information about the Ux mailing list