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

Gregg Vanderheiden gregg at raisingthefloor.org
Sun Mar 29 16:29:59 EDT 2015


Comments below  marked with GV:

gregg
 


> On Mar 23, 2015, at 10:18 AM, Andrés Iglesias Pérez <aiglesias at consultoria.ilunion.com> wrote:
> 
> Hi Dana,
> >Could you give an example of what you mean by "try a finer configuration" (Advanced option)?
> AI: Let’s say that the MM has detected that the user understands a=75 words per minute, but has a fuzzy understanding about that the user _could_ understand b=125 words per minute. The answer to ‘Yes’ is a, the answer to Advanced is b. I a similar fashion on what happens when you change your screen resolution, the system waits for approval of b, after some time with no feedback it reverts to a.
> >Is this the same as the "try different" concept introduced by Gregg (and shown in the wireframes)?
> AI: No. 
> > I don't understand your distinction between "decision" and "recommendation" here.
> AI: Decision is a. Recommendation is b (of course it’s possible to have c,d,e,f… all but a are recommendations). The initial plan [1] was to place that into the PCP, but this dialog mechanism can be helpful as well.

GV:  Correct me if I am wrong but I think…

"Try Harder”  and “Try Different”   are things that are initiated by the USER.    They give these commands when they want something different tried.

“Try a finer configuration”  above referred to a MM initiated suggestion for change.  (due to change in context or perception of user performance or ….)


RE the other question and the one below…..


Once the MM offers a different set of preferences — the user could reply 
yes  use these new ones for now
yes  use these new ones from now on for this context
yes use these new ones from now as default
Try harder/different  (no - but try again)
no don’t I don’t want to use your suggestion now
no don’t I don’t want to use your suggestion ever for this context
no don’t suggest a change ever again
(others?) 

As can be seen - there are many options but maybe they can be all handled as a couple bits of feedback

>yes /  >no /  >try again-different
if they press  "try again-different"  then this is iterative until they press yes or no

then ask
[yes:no] for this context [name the context] or for everything?
> Just for [context name]
> For everything 

and include a checkbox for “don’t ask again for [context name]    
if there is no context — then just say  “Don’t Ask Again” 


#6 is the dangerous one — but one that many may push if too many suggestions are made — or too many bad suggestions.

I think the way to address this - is to have an email sent to the person every 6 months or so — listing the things that they said they never wanted to change — with a link where they can turn this off and/or explore different settings to see if they did want to change something.  



>  
> > 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
> AI: for device-platform-application context it can make sense. For environment context can be very annoying for the user to have to state many times that they want the “Always do this” for tiny changes in the context. Even the d-p-a can be annoying if not previously understood (“Yes! I want fontsize this big! For my iPad, for my kindle, for my computer, for the ATM, don’t ask me more!!!”. Unless we have a powerful reason not to do, I will vote for placing all the “Always do this” under gpii-default.

GV:  see above.    I think we shouldn’t have a way to cut things off and never revisit. 

Also - as we introduce contexts we need to introduce the ability to change by context


Thoughts?

G



>  
> >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. 
> AI: It’s also a nice shorthand for “don’t mess me with context-related stuff, just do what I say” and saves battery for devices not continuously plugged to the AC. Anyway once it’s done (Is it done?) I don’t see a specific reason for removing it.




>  
> Kind regards,
> Andrés
>  
> [1] http://link.springer.com/chapter/10.1007%2F978-3-319-07437-5_22 <http://link.springer.com/chapter/10.1007%2F978-3-319-07437-5_22>
> “The Matchmakers output is divided into  Decision+Interaction Help+Recommendation+OfflineSuggestion.
>   Decision: some ATs are automatically applied to ensure accessibility.
>   Interaction  Help: decisions to automatically apply AT aims to ensure accessibility
> but might entail difficulties in utilize, i.e. if the user is not aware of short cuts pr ovided by a screen reader. Important operations are delivered to the user in addition 
> to a decision.
>   Recommendation: the proposed AT setup is presented in the Personal Control Panel (PCP), a module that acts as a PMT on the user’s device. E.g.: preferred speech 
> rate for screen readers.
>   OfflineSuggestion: When new AT are available and could benefit a specific user,
> the Matchmakers send an to inform about the new choices. 
>>  
> Andres Iglesias-Perez
> Tech Accessibility, Studies and R&D
> Researcher
> Tel: 0034 91 121 0330
> Email: aiglesias at consultoria.ilunion.com <mailto:aiglesias at consultoria.ilunion.com>	
> <image001.png>
>  
>  
> De: Dana Ayotte [mailto:dana.ayotte at gmail.com] 
> Enviado el: lunes, 16 de marzo de 2015 20:48
> Para: Andrés Iglesias Pérez
> CC: Gregg Vanderheiden; Christophe Strobbe; architecture at lists.gpii.net Architecture; GPII UX
> Asunto: Re: [Ux] [Architecture] Preference term for auto-adjustment to context change
>  
> 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 <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 <mailto: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 <mailto:aiglesias at consultoria.ilunion.com>	
> <image001.png>
>  
>  
> De: ux-bounces at lists.gpii.net <mailto:ux-bounces at lists.gpii.net> [mailto: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 <mailto: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 <mailto:gregg at raisingthefloor.org>
>  
>  
> 
>  
> On Mar 11, 2015, at 7:34 AM, Christophe Strobbe <strobbe at hdm-stuttgart.de <mailto: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 <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 <http://lists.gpii.net/pipermail/architecture/2014-November/002941.html>>
> [2] <http://lists.gpii.net/pipermail/architecture/2014-November/002947.html <http://lists.gpii.net/pipermail/architecture/2014-November/002947.html>>
> [3] <http://lists.gpii.net/pipermail/architecture/2014-November/002956.html <http://lists.gpii.net/pipermail/architecture/2014-November/002956.html>>
> [4] <http://lists.gpii.net/pipermail/architecture/2014-November/002957.html <http://lists.gpii.net/pipermail/architecture/2014-November/002957.html>>
> [5] <http://lists.gpii.net/pipermail/architecture/2014-November/002958.html <http://lists.gpii.net/pipermail/architecture/2014-November/002958.html>>
> [6] <http://lists.gpii.net/pipermail/architecture/2014-November/002982.html <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/ <http://dissenter.firedoglake.com/2012/12/28/jacob-appelbaum-on-resisting-the-surveillance-state/>>
> 
> _______________________________________________
> Architecture mailing list
> Architecture at lists.gpii.net <mailto:Architecture at lists.gpii.net>
> http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture <http://lists.gpii.net/cgi-bin/mailman/listinfo/architecture>
>  
> _______________________________________________
> Ux mailing list
> Ux at lists.gpii.net <mailto:Ux at lists.gpii.net>
> http://lists.gpii.net/cgi-bin/mailman/listinfo/ux <http://lists.gpii.net/cgi-bin/mailman/listinfo/ux>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/ux/attachments/20150329/7bbff5fd/attachment-0001.html>


More information about the Ux mailing list