Agenda

• Gestures and Actions
  • The issue formerly known as Access Key
  • The actions that users can do easily on a page
  • The way they quickly access those actions
• Delivery Context and User Preferences
  • Overriding device characteristics
  • Dynamic properties
  • Transporting overriding values efficiently

This is also available as a paper.

Gestures and Actions

• Need a more general method for binding

  Gestures

  things a user can do in via the user interface

  • pressing a button
  • speaking a keyword
  • tapping with a stylus

  with Actions

  operations supported from the current page

  • traversing a link
  • submimtting a form
  • activating a menu

Available Gestures

• Hugely variable
  • Vary by type of device
    • PCs and many smart phones have full keyboards
    • Basic phones have numeric keypads that can generate other characters
    • TV remote controls have coloured buttons
  • Vary by capabilities of user
    • Users with disabilities may have special input devices
  • Might be affected by user preferences
• Authors can't directly reference gestures in markup reliably

  • <a href="../help.html" accesskey="H">Help</a> 

    not much use if you don't have an H key

Actions

• Standard actions have been defined in specific domains
• • ISO Danger and Information Signals
  • ETSI Spoken command vocabulary for ICT devices and services
  • EZ Access (R)
• We should be able to define standard actions for Web browsing
  • Work has started on Intent-based events
  • Roles are probably important sources of information about available actions
    • WAI Role Taxonomy

Indirection

• Need a level of indirection for authors and users
  • Not so much

    <a href="../help.html" accesskey="H">Help</a> 

  • More

    <a href="../help.html" action="help">Help</a> 

• Plus ontologies for
  • Gestures
    • pressing the red button
    • saying the word "help"
  • Actions
    • navigating to the associated help page
    • submitting a form
  • Plus bindings of gestures to actions
    • pressing the red button navigates to the associated help page
• Just like programmable function keys for terminals
  • F1 = Help

Bindings [1]

• Part of the delivery context
• Default bindings for device could be
  • held in the MWI Device Description Repository
  • represented in OMA UAProf for mobile devices
  • hard-wired into desktop/PC browsers
  • etc.
• Default bindings should be similar on devices with similar input capabilities
• Dynamic modifications could be
  • accessed via DIWG Delivery Context Interfaces (DCI) at the device
  • transported to servers via OMA DPE for mobile devices
  • dealt with entirely locally in desktop/PC browsers
  • etc.

Bindings [2]

• Users must be able to discover the bindings
  • Exact mechanism is device dependent
  • Depends on
    • UI modality
    • availability of screen real estate
    • etc.
  • Examples include
    • View lists of bindings
    • Listen to lists of bindings
    • On-screen prompts
    • Suggests need for an action to reveal the bindings
• User preferences need to be managed
  • User interface on the device

Some Issues

• Multiple instances of actions
  • Multiple form submissions on a page
• Extensibility models for the ontologies
• Scope of bindings
  • Browser only
  • Device-wide

Delivery Context and User Preferences

• User preferences should be able to affect aspects of delivery context
• Need representations that can be presented to users sensibly
  • Need to avoid inappropriate choices being possible
• Need to avoid premature evaluation
  • leave things to the client that only the client can do
• Need to optimise traffic associated with changing values
  • Work in OMA DPE is also looking at this
• Need to address the security implications of user preference disclosure
• User preferences need to be managed
  • User interface on the device