WP204/WP205 Meeting on 2013-10-11

From wiki.gpii
Jump to: navigation, search

MINUTES

Telephone Bridge

1. To talk free using the Web click: https://www3.gotomeeting.com/join/705233502 Be sure to set AUDIO to Mic and Speaker (VoIP) - a headset is recommended.

Important Information for the Meeting

This is a meeting of WP204 and WP205 (Matchmaker) within the European Project Cloud4All. However, the minutes of the meeting will be made available to the public to allow people outside Cloud4All to follow the development of the matchmaker. If, in the meeting, you want to share confidential information that should not appear in the public minutes, you need to state so in the meeting. This is in line with the Cloud4All Consortium Agreement, section 10.

Participants

  • Andy, Christophe
  • Claudia
  • Andres, Ignacio
  • Nick
  • Kasper

Minutes of Previous Meetings

APPROVED:

New Meeting Time

Proposed new meeting time: 3 p.m. CET.

Paper for HCII 2014

The deadline for paper abstracts (800 words) is 15 October. The deadline for the final paper is 7 February 2014.

Andres proposes ideas for a paper and where to submit it.

Resolution: Discuss both context and matchmaking.

  • State of the art
    • Preferences
    • Context
    • Matchmaking
  • Describe the architecture between SAT - RBMM - MMM
  • Idea of decision + recommendation + "mail for later on"
  • Pilots
  • Details of components

Submit to "Universal Access in Human-Computer Interaction".

Common Terms and Mappings for Phase 2

  • highContrast (existing common term - Boolean) will be deprecated.
  • highContrastTheme (proposed new term) will replace highContrast.
    • Resolution: accepted.
  • foregroundColour & backgroundColour: used as common terms by smart house but overlaps with highContrastTheme.
    • Christophe to ask Boyan to consider using contrast themes instead of colours.
  • fontFace: rejected. (Also very complicated ;-) )
  • onScreenKeyboardEnabled: Linux has lots of settings, while Windows does not (basically on/off now; settings are in tricky Windows parameters).
    • Resolution: rejected for second phase, together with slowKeysEnable, stickyKeys, slowKeysInterval, debounceEnable, debounceInterval, mouseEmulationEnabled, initDelay, cursorSpeed, cursorAcceleration.
    • Also reject mouseTrailing (currently Windows only)? Keep as an alternative to other mouse settings (e.g. pointer size) that are missing on the target platform? But Windows has pointer size settings. (See below).
  • Volume: not supported on Windows and Linux. Perhaps in eCtouch and eCmobile?
    • Resolution: Accept for now.
    • Both Windows and Fedora allow users to define different volume levels for different applications. However, we have no support for conditions yet, so no way to scope a common term to a specific application.
    • Discuss with PMT and PCP teams (different volume settings)
    • Resolution: Accept volume and volumeTTS.
  • language (UI language):
    • All SP3 applications to be tested need to be available in the languages of the pilot sites (German, Spanish, Greek).
    • Language switching at OS level: very hard on Windows; requires a reboot on Fedora.
    • Ask SP3 developers whether they support language switching at/before launch time?
    • Resolution: Accept it but don't add it to the PMT (but use the info if available).
  • vibration: only in mobile phones; also good for deaf users.
    • Resolution: Accept for phase 2.

Continue discussion on Monday 14 October, 10 a.m. CET.

  • brightness & brightnessMode: Android & perhaps Linux, but not Java phones.
    • Can be useful once we implement context and motes (not ready for this phase).
    • Resolution: rejected for this phase; reconsider for third phase.
  • screenwidth & screenheight: to set resolution on a screen; being worked on for Linux but not on Windows.
    • Resolution: rejected for this phase.
  • pitch: can be used by several solutions with synthetic speech (screen readers, ...)
    • Resolution: accept for phase 2.
  • screenOff, screenDim, screenRotation, screenRotationValue: don't seem very important (and describe behaviour that happens automatically)
    • Delaying or turning off screenDim could be useful for slow readers.
    • Resolution: accept for phase 2, and ask users in the pilots how useful these features are (e.g. turning off screenDim).
  • fontMagnification: since mobile devices don't have magnification; Android has not font size.
    • Distinguish between magnification (e.g. on desktop OS) and font resizing (on mobile devices).
    • Linux Gnome (on Fedora 18) allows you to set both a text scaling factor and font size (through the Gnome Tweak Tool).
    • Resolution: reject fontMagnification for this phase, since fontSize is already supported; add it for the third phase.
  • adaptationType: only in smart house.
    • Resolution: rejected for this phase; consider for more complex scenario in third phase..
  • MouseTrailing: only-mouse specific feature and only in Windows.
    • Was triggered by the N&P set os_common when using the rule-based matchmaker.
    • Resolution: rejected for phase 2.


Preliminary conclusions:

  • Nothing for dyslexia or cognitive impairments.
  • Not enough for hard of hearing?

Other Requirements for Phase 2

Logging

What is needed for logging? See Yura's question on the Architecture mailing list.

Logging should output the current situation/settings to a file. Should cover app-specific settings, current N&P set user token, time stamp.


Invoking logging manually instead of automated logging (as last time – each time the MM is invoked) would hopefully avoid multiple sets of logs for the same user.

How to invoke/trigger the logging? A shortcut linking to a command-line script could work; depends on what works for the test sites.

Transformers

The decision to have both transformers and inverse transformers has been reversed. It looks unlikely that most SP3 developers would be able to write transformers and inverse transformers. So that would shift the burden to Kasper and Claudia.

The documentation about the transformers should be mostly up to date.

Test scenario

Ignacio updates team about hot-off-the-press changes to the test scenario.

Which Solutions Should Launch Automatically?

Maavis, Chrome, etc., vs. ATs - what should automagically launch?

Proposal was to determine in advance what solution(s) should be launched and to let the Device Reporter pretend that only these solution are available.

Next Meetings and Topics

Next meeting: WP204/WP205 Meeting on 2013-10-18.

Previous meetings: see Matchmaker Meetings.