Difference between revisions of "Architectural Notes About the Needs and Preferences Set Format"

From wiki.gpii
Jump to: navigation, search
m (Metadata About Preferences)
(Preferences Sets consists of:)
Line 7: Line 7:
 
* Policies which are cross-cutting assertions about preferences
 
* Policies which are cross-cutting assertions about preferences
 
** Security policies
 
** Security policies
** Providence/origin (where did this preference come from? The Snapshotter? A discovery tool? Somewhere else?)
+
** Provenance/origin (where did this preference come from? The Snapshotter? A discovery tool? Somewhere else?)
 
** Do not ontologize (dont infer from this setting, only apply to this particular application)
 
** Do not ontologize (dont infer from this setting, only apply to this particular application)
 
** Priority
 
** Priority

Revision as of 21:44, 12 August 2014

Decisions, Open Questions, Notes, and Ideas

Decisions

Preferences Sets consists of:

  • Preferences grouped by contexts and containing conditions
  • Policies which are cross-cutting assertions about preferences
    • Security policies
    • Provenance/origin (where did this preference come from? The Snapshotter? A discovery tool? Somewhere else?)
    • Do not ontologize (dont infer from this setting, only apply to this particular application)
    • Priority
    • Required
    • Launch on startup

Priority

An unbounded float range defining the relative importance of one application or context.

Required

Integer range, with fixed upper bound: 100, meaning system cannot be used without this being present/available

Granularity and Abstraction

Some common terms are very specific, such as the font size of the OS menu bar. But we also allow for very general, user-oriented common terms (for example simpleKeyboard, simplifiedContent, everythingEnlarged). The goal of common terms is to:

  1. Serve as a meeting point for adapting settings across different applications
  2. Representing the user's needs and preferences in a vocabulary that suits them

Three types of preferences in a set:

  1. Common terms, which represent user preferences that can be applied across a variety of applications, and that are intended to capture (to a greater or lesser extent) the intention and vocabulary of the user
    • Some common terms are particularly optimized for translation
    • Others are higher level and more abstract ("I need it to be easier to read")
  2. Registered application-specific terms, which have a defined scheme registered in a Preferences Dictionary, and which represent a setting for a specific application
  3. Unregistered, opaque application-specific blocks, which consist of an arbitrary block of one or more settings that are passed directly to a settings handler without any modification

Commons terms are concatenated camel-case

Flat common terms will be non-categorized, non-ontologized and non-hierarchical. They will be camel case. E.g.:

  • "http://registry.gpii.net/common/pitch"
  • "http://registry.gpii.net/common/screenreaderUppercasePitch"
  • "http://registry.gpii.net/common/bodyTextFontSize"

Open Questions and Ideas

Accumulation

Can preferences be accumulated? For example, if I have a base set of preferences and one for a specific context, when I'm in that context are both preferences applied (with those that match the context more closely overwriting)? See the Oedipus use case below for an example. This could be a user setting, which explicitly states that "this should be accumulative" or "start from scratch". This should probably be stored in the preference set itself, perhaps as a policy?

Metadata About Preferences

Where do we store Matchmaker (and other) metadata:

  • eg. I dont want to have solutions suggested to me, suggestions on specific things, request to postpone suggestion for later (dont talk for the next 3 hours)
  • Metadata relating to preference editors

The ST MM wants to store all the context at the time of snapshot, e.g. (Screen metrics, background noise, luminosity, time of day). Where should this context be stored? Should we just make MM specific blocks in policies or other metadata location?

Recording PCP usage to train the Matchmakers - where should that metadata go? i.e. the user always increases volume in the PCP, so perhaps it should suggest user a higher value - or be a nazi and actually provide without the consent of the user.

Should "policies" actually be renamed to "metadata"? It seems to be more that just policies.

Ontology Transforms: Where do we put contexts in the extended-24751 sets?: This applies in cases where the Ontology Server will transform (on request) a preference set from e.g. flat to the hierarchical extended ISO for use cases such as supporting ontology-aware Matchmakers such as the Canopy Matchmaker. All the policies need to be copied over as well as the context, at least if we plan to be able to take things like: security, priority, requirement, etc.

Use Cases

Homer

Has low vision so generally prefer an increased font-size (15) on his system. At night, his eyes get tired so he would REQUIRES an even further increased font size (18) after 18:00. [require vs prefer, simple context set]

Oedipus

Is quite techy and *requires* a screen reader (or some other needs of using a computer without vision). He has used the PMT to create an "at the movies" context (non-accumulative). When this context is applied the screen reader TTS should be turned of and braille/haptic feedback enabled instead. (accumulative vs. non-accumulative contexts/sets, expression of required preferences)

Minelaus

Has very specific settings for his screen reader. He generally uses the pitch to give him clues about the text - as he mainly uses JAWS, he has most of the settings specified in terms of that (eg. pitch for italics in JAWS, pitch for underlined in JAWS, pitch for capitalized and underlined text in JAWS). He has some general preferences specified as well (generic pitch setting, read speed, etc). He also has some settings specifically for NVDA, which he requires to be able to use NVDA as its speech engine is quite different from other screen readers. As the NVDA settings are not representative for how he wants a screen reader to act, these settings should NOT be used to infer other settings. (application specific settings)

Aphrodite

(Currently out of scope) She uses two switches, both connected by USB. One of them should trigger the click function, the other should trigger the cancel function. (Using 'instance' to describe the same preferences but for multiple hardware devices).

Persephone

She has detailed pitch settings, i.e: 0.3 for general, 0.5 for italics, 0.4 for underlined, 0.6 for capitalized, 0.2 for headings. She uses computers extensively and often wants to edit her settings in a preference editor. (Illustrating the need for 'light' contexts -- if this was to be illustrated in Colin's proposal, one would require 4 different contexts)

Triptolemus

His preferences has been generated by the statistical MM (or Snapshotter) and all kinds of extra context information has been recorded as part of the snapshotting process. Some settings have been tweaked via the PCP, which is recorded in the NP set. He has also modified some settings in the PMT, the source of the change has been recorded in the NP set. Furthermore, he generally likes exploring new things so he wants MM suggestions (MM metadata).

Example Preference Set Format We Discussed

 {
    "contexts": {
        "default-xyz234871": {
            "name": "Base set",
            "preferences": {
                "http://registry.gpii.net/common/screenreaderUnderlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws/underlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws": {
                    "cat": "meow",
                    "dog": "base65stuff"
                }
            }
        },
        "at-night-xyz238416387": {
            "name": "Nighttime set",
            "priority": 0.0005,
            "preferences": {
                "http://registry.gpii.net/common/menuBarFontSize": 14
            },
            "conditions": {
                "stuff-in-here": "..."
            }
        }
    },
    "policies": {
        "default-xyz234871.http://registry\\.gpii\\.net/common/screenreaderUnderlinePitch": {
            "required": true,
            "authorized-applications": [
                "com.facebook"
            ]
        }
    }
 }
 

Other Notes, Unfinished Sketches, and an Archive of Stuff We Thought About

  • Claudia points out the complexity of alignment when we have "atomic terms" since
    • the number of common terms will be significantly higher
    • if a vendor has the concept of "just pitch," they will have to find a particular common term that best aligns with it
  • Multiple instances of the same solution (out of scope for now): e.g. Two screens, Two Switches: While we want to be able to support this at some point in the furture, this is out of scope for cloud4all. Expressing eg. two 'clickAction's as common terms, since it is impossible impossible to have two versions of the same common term (ie: common/switchClickAction can only be present once as it is used as a key). We need to somehow be able to express something like: rightSwitchClickAction and leftSwitchClickAction, and generally specify a whole group of settings for each specific switch, each specific screen, or whatever it might be (how does the system know what switch a user is referring to, across different machines, etc)?
  • Common terms will never be in the context of an application. There is no reason why settings expressed in the context of an application is not just saved as application specific terms (How does this match up with the needs of preferences editors? It may be very complex for an editor to support an arbitrary, infinite space of application-specific settings, especially when some of them may not be registered)

Alternative Example Preference Set Ideas

preferences: { 
    context1: {
        context-name: "At Home",
        priority: 60
        preferences: {
           "http://registry.gpii.org/common/pitch : http://registry.gpii.org/common/screenreader": 12
        },
        conditions: {
            ...
        }
    },
    context2: {
        context-name: "At the cat",
        preferences: {
            //"registry.gpii.org/common/screenreaderUnderlinePitch" ->
            // screenreader: {
                   underline: {
                       pitch: 27
                       }
                }
             "http://registry.gpii.org/common/pitch": {
                "contexts": [
                     "http://registry.gpii.org/common/screenreader",
                     "http://registry.gpii.org/common/underline"
                ],
                value: 2000
              }
            },
            "https://registry.gpii.org/common/cat": 45
        ],
        conditions: { ... }
    }
}
policies: {
    context1.preferences.screenreader.pitch: {
        priority: 100,
        required: 100,
    },
    context1: {
        priority: 57
    }
}
            "http://registry.gpii.net/common/pitch": [ { value: 24, conditions: { text-style: "underlined" }}, {value: 34, context: }
 {
    "Nighttime At Home": {
        "preferences": {
            "http://registry.gpii.net/common/(<context>/)*fontSize": 24,
            "http://registry.gpii.net/common/pitch": 32,
            "http://registry.gpii.net/common/switch/instance1/switchFunction": "scan"
            "http://registry.gpii.net/common/switch/instance1/switchPort": "com3"
            "http://registry.gpii.net/common/jaws-instance4/switch-instance2/switchFunction": "scan"
"http://registry.gpii.net/common/switch/switchPort": [
    instance1: ....
    instance2:  ...
]
            "http://registry.gpii.net/common/switch/instance2/switchFunction": "click"
            "http://registry.gpii.net/common/keyboard/instance1/key": "a"
            "http://registry.gpii.net/common/keyboard/instance1/favoriteKey": "∑"
            "http://registry.gpii.net/pointerControl///nstance1/switchPort": "com3""
            "http://registry.gpii.net/swich/automatedScanning/instance1/switchPort": "com3"
        },
    
        // Implicit AND
        "conditions": [
            {
                "http://registry.gpii.net/conditions/timeOfDay": {
                "range": {
                    "start": 1730,
                    "end": 730
                }
            },
            {
                "http://registry.gpii.net/conditions/location": {
                    "gps": {
                        "lat": "79.3N",
                        "long": "74.9W"
                    },
                    "range": "200m"
                }
             },
             OR 
             {
               "http://registry.gpii.net/conditions/application": {
                    "id": "com.freedomscientific.jaws"
                }
            }
        ]
        "priority": 100
    },
    "com.freedomscientific.jaws": {
        "preferences": {
            "http://registry.gpii.net/common/fontsize": [{
                "value": 19
            }]
        },
    
        // Implicit AND
        "conditions": [
            {
                "http://registry.gpii.net/conditions/application": {
                "id": "com.freedomscientific.jaws"
            }
        ]
        "priority": 100
    },
    "com.freedomscientific.jaws": {
        "preferences": {
            "http://registry.gpii.net/common/fontsize": [{
                "value": 19
            }]
        },
    
        // Implicit AND
        "conditions": [
            {
                "http://registry.gpii.net/conditions/application": {
                "id": "com.freedomscientific.jaws"
            }
        ]
{
    "contexts": {
        "default-xyz234871": {
            "name": "Base set",
            "preferences": {
                "http://registry.gpii.net/common/screenreaderUnderlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws/underlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws": {
                    "cat": "meow",
                    "dog": "base65stuff"
                }
            }
        },
        "at-night-xyz238416387": {
            "name": "Nighttime set",
            "priority": 0.0005,
            "preferences": {
                "http://registry.gpii.net/common/menuBarFontSize": 14
            },
            "conditions": {
                "stuff-in-here": "..."
            }
        }
    },
    "policies": {
        "default-xyz234871.http://registry\\.gpii\\.net/common/screenreaderUnderlinePitch": {
            "required": true,
            "authorized-applications": [
                "com.facebook"
            ]
        }
    }
}
 

Two types of contexts:

Environmental context:

  • time of day, light, noise

Ontological context:

  • Application type (e.g. screen reader)
  • Product (e.g. Jaws)
  • Link
  • To allow us to distinguish between multiple instances of the same application/solution, we have special contexts: instance1, instance2, ...