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

Andrés Iglesias Pérez aiglesias at consultoria.ilunion.com
Mon Mar 23 11:18:29 EDT 2015


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.

> 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.

>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
“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>

[Ilunion Accesibilidad estudios y proyectos]




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

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] 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> 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<mailto:Architecture at lists.gpii.net>
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/ux/attachments/20150323/23b981b6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5441 bytes
Desc: image001.png
URL: <http://lists.gpii.net/pipermail/ux/attachments/20150323/23b981b6/attachment-0001.png>


More information about the Ux mailing list