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

Andrés Iglesias Pérez aiglesias at consultoria.ilunion.com
Thu Mar 12 06:42:20 EDT 2015


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>

[Ilunion Accesibilidad estudios y proyectos]




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/ux/attachments/20150312/54a6ac07/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/20150312/54a6ac07/attachment-0001.png>


More information about the Ux mailing list