- Matchmaking and privacy filtering
- needs vs. preferences expressed by user (
- Extending the available dispositions (to include pointers on whether to launch or not, etc)
- What solutions to start on login?
- When to kill solutions on login?
- Handling difficult use cases, such as:
- app 1 does both "stickyKeys" and "slowKeys" and app 2 does both "slowKeys" and "debounceKeys" - what do/should we do then?
- "non-nested overlapping functions"
- a combined AT such as a magnifier + screen reader, however its screen reader is not very good and can't be disabled
- Shared ontologies in solutions registry (GPII-1745)
- inversion support
- We need access to all the solutions registries
- "apptology" - shortcomings
- (eg. transformations between settings and apptology - eg. what settings would be required to deduce that a solution is a screenreader)
- what types of solutions should go in here (effectively meaning that they are considered conflicting)
- Multi-layer configuration support (GPII-1746)
- What do we do about these meta-preferences, such as:
- "http://registry.gpii.net/common/screenReaderTTSEnabled": false,
- "http://registry.gpii.net/common/magnifierEnabled": false,
- http://registry\\.gpii\\.net/common/slowKeysEnable: false
- should they have some sort of different status from others (ie. could they be our solution to the use case with multiple apps overlapping the same functionality)
- Have a system that doesn't launch all screen readers at once
- Have a system that separately knows how (and when) to launch a solution versus just configure
- Have a system that understands complex interactions between solutions (eg. windows high contrast theme and mouse cursor size)
- Have a system that understands effects adaptions on multiple layers (OS, AT, browsers, browser AT, webpages)