Re: techniques for author-defined UI controls

At 09:59 PM 10/27/99 -0400, Gregory J. Rosmaita wrote:
>Prologue
>First of all, I do not believe that there is any need to
>differentiate between "author-defined" user interface (UI)
>controls and any other type of UI control. I also believe that the
>crux of the argument isn't "where do the UI controls come from",
>but, rather, "how much control over the UA will the user be
>given?"  The less control over the UA the user is allowed, the
>less that application deserves to be called a user agent.  What is
>a user agent, after all, other than a mechanism whereby a user can
>retrieve and review content?

It would seem that you only considered two options: that author-defined UI
elements would be given less attention than client-software-defined UI
elements, or equal attention.  It would seem that there is a significant
difference between author-defined elements and client-software-defined
elements which suggests that _more_ attention needs to be given to ensuring
that the author-defined elements are well explained to the user than for
client-software-defined elements.

This has to do with consistency.  The client-software-defined elements are
present in the environment of all visited pages.  If the explanation of
what they do is a little weak, the user can establish what they do by trial
and error, remember what they do, and the weakness of the tutorial
information ceases to be an issue.  For author-defined UI elements,
however, they come and go with each page.  If they are not made
excruciatingly clear, they become a major obstacle or trap.

If it takes three tries to figure out what a client-software-defined UI
element actually does, in visiting one hundred pages this can add three
percent to the overall effort required.  If each page defines a peculiar UI
element and it takes three tries to figure each one out, this adds two
hundred percent to the effort to browse the one hundred pages.

The overall quality of explanation, combining author and user agent
contributions, is more critical for UI elements which vary from page to
page than for UI elements which persist across all pages.

ACCESSKEY can reduce the time to browse the web by substituting single
keystrokes for longer key sequences.  See recent remarks by Scott Luebking
on the Interest Group List
<http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0330.html>.  But
unless the key assignments are consistent across pages, I don't know how
much time is actually saved.  So a "behavior sheet" or other
community-based method of assigning these would seem to be preferable to
what we have now.  Are there defacto standards for keystroke usage in
ACCESSKEY emerging through the natural language pressure to repeat winning
expressions?

Al


>
>That being said, the following is submitted in accordance with the
>action item that I took at today's teleconference.
>
>----
>Techniques for Exposing Author-Defined UI Controls
>
>Introduction/Background
>The first question to be answered is: "What Are Author-defined
>User Interface controls?"
>
>1. Author-defined UI controls include the following:
>  ActiveX controls
>  JavaScript
>  applets
>  ACCESSKEY (HTML4)
>  TABINDEX (HTML4)
>  HTML4 event handlers
>  [your favorite author-defined UI mechanism here!]
>
>The second question to be answered is: why differentiate between
>UA-supplied UI controls and author-supplied UI controls, since --
>to the user -- the source of the control is irrelevant?
>
>2. Reasons for differentiation between UA- and author-defined UI
>controls
>
>  A. UA doesn't know what to expect from author-defined UI
>  controls, or necessarily what to do with them or where to look
>  for them
>
>  B. author-defined UI controls may conflict with OS and UA UI
>  controls / keybindings
>
>  C. documenting / exposing / supporting author-defined UI
>  controls could be accorded a lower priority than UA-defined UI
>  controls
>
>3. Reasons for not differentiating between UA- and author-defined
>UI controls:
>
>  A. the user doesn't care where the UA obtains the array of UI
>  controls available at any given time; the user simply wants to
>  know:
>
>     1. what controls are available
>     2. how the available controls can be invoked
>     3. what will happen when they are invoked
>
>  B. the ubiquity of author-defined UI controls makes them as much
>  a part of a user's online experience as does UA-defined UI
>  controls (please refer to the list of author-defined control
>  types above before barking at me for this assertion.)
>
>  C. documenting / exposing / supporting author-defined UI
>  controls could be accorded the same priority as UA-defined UI
>  controls
>
>  D. the source of UI controls which authors are currently 
>  able to define are well known, so the UA could easily be 
>  primed to look for and expose them.  What to expect from 
>, or necessarily what to do with them once they are exposed, 
>  however, remains potentially problematic.
>
>Techniques for Exposing Author-Defined UI Controls
>
>1. General Techniques
>
>  1.1 Make a list of keybindings for the currently rendered page
>  available to the user.  If any of the author-defined keybindings
>  conflict with application or OS keybindings, alert the user in a
>  device independent manner. Do not, for example, rely exclusively

>  on font or color changes, on the playing of an audio clip, or
>  upon an icon to convey this information to the user.
>  
>  1.2  Provide a cascade order for keybindings, through which the
>  user would be able to choose from among the following options:
>
>     a) Do not over-ride default system and UA controls, but alert
>     the user if author-supplied keybindings conflict with them,
>     and provide a pass-through mechanism to allow the user to
>     invoke author-specified UI controls that conflict with
>     default UA or OS controls/keybindings.
>     
>     b) Allow author-defined keybindings to over-ride UA and OS
>     keybindings, but      alert the user of the conflicts, and provide 
>     a pass-through mechanism so that the conflicting UA / OS 
>     keybindings can still be invoked
>     
>     c) Allow the user to choose to have the UA re-map author-
>     supplied keybindings to currently unused keystrokes, then
>     alert the user to which keystrokes the author-supplied UI
>     controls / keybindings have been re-mapped
>
>
>2. Specific Cases
>
> 2.1 ACCESSKEY
>  
>  2.1.1 Allow the user to define the triggering mechanism for
>  ACCESSKEY.
>  
>  Rationale: When an author defines an ACCESSKEY, only the
>  accelerator key is defined. It is left to the user agent to
>  apply a triggering mechanism which will invoke the ACCESSKEYs
>  defined by the author for the document currently being rendered.
>  For example, Microsoft Internet Explorer 5 uses the ALT key as
>  the ACCESSKEY trigger when running on the Windows platform.
>  This triggering mechanism, however, conflicts with some default
>  OS and application keybindings which also rely upon the ALT key
>  for their triggering mechanism, such as ALT+F (the keybinding
>  that invokes the "File" menu) and ALT+H (the keybinding that
>  invokes the "Help" menu).
>  
>  Why then, is it not the author's responsibility to avoid using
>  ACCESSKEYs that conflict with OS and application keybindings?
>  There are simply too many possible permutations that could be
>  applied as ACCESSKEY triggers across platforms for the author to
>  realistically predict such conflicts.
>  
>  A means of endowing the user with the ability to define the
>  triggering mechanism for ACCESSKEY, therefore, would alleviate
>  both of the impasses outlined above.  The advantages of allowing
>  the user to define the triggering mechanism for ACCESSKEYs
>  include:
>
>     1. the onus of avoiding key conflicts is placed on the user
>     and not the user agent;
>
>     2. the user agent can not only ask the user to define an
>     ACCESSKEY trigger, but -- through context sensitive help, a
>     "More Information" button, a field label, explanatory text in
>     a .cfg file, etc. -- could also warn the user of potential
>     key conflicts.  While the interactivity level of such a
>     mechanism is best left to individual developers to define, a
>     basic definition request could take a form similar to the
>     following, platform-specific, example:
>
>       "Please define a triggering mechanism for ACCESSKEYs.
>       ACCESSKEYs are author-defined accelerators which make it

>       possible to activate a link, move through a page, or
>       activate form controls using a keystroke combination.  Half
>       of the combination (an alphabetic or numeric character) is
>       pre-defined by the author. In order to trigger the
>       ACCESSKEY, however, it is first necessary for you to define
>       a "trigger key", which -- when pressed in conjunction with
>       the ACCESSKEY defined by the author -- will activate the
>       element for which the ACCESSKEY has been defined.  It is
>       highly recommended that you do not use the ALT or CONTROL
>       keys as the ACCESSKEY trigger, as they are commonly used to
>       trigger application and system events in the Windows
>       environment."
>     
>     Such a mechanism/message could be displayed to the user the
>     first time that a page upon which ACCESSKEYs are defined is
>     loaded.  Such a mechanism should also form part of the
>     general configuration mechanism for the user agent.
>
>  2.1.2 Ensure Uniform Action Upon Invocation.
>  
>  Rationale: The user needs to know what to expect when he or she
>  invokes an ACCESSKEY: will the focus be moved to the element for
>  which an ACCESSKEY has been defined, or will invocation of an
>  ACCESSKEY cause the element for which the ACCESSKEY has been
>  defined to be activated (i.e. the link followed or the form
>  control toggled)? To ensure uniform action upon invocation of an
>  ACCESSKEY, provide the user with the following options:
>
>     a) move focus to the element for which the ACCESSKEY has been
>     defined
>
>     b) activate the element for which the ACCESSKEY has been
>     defined
>
>     c) prompt the user each time an ACCESSKEY is invoked
>       (Note: any such prompt should also endow the user
>       with the ability to "Save current choice as the
>       default action for ACCESSKEY")
>
>--- end proposed techniques
>
>Supplemental References
>1. Minutes of the 26 October 1999 User Agent Teleconference
>    http://www.w3.org/WAI/UA/1999/10/wai-ua-telecon-19991027.html#minutes
>
>2. definition of ACCESSKEY in the HTML4 Recommendation:
>     http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accesskey
>
>3. my summation of the ACCESSKEY issue for the UA mailing list
>     http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0008.html
>
>4. my thinking-out-loud about ACCESSKEY post to the member-confidential PF
>list:
>     http://lists.w3.org/Archives/Member/w3c-wai-pf/1999OctDec/0065.html
>
>5. my post to w3c-wai-ua on the irrelevance of the source of UI controls
>     http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0172.html
>
>6. Keyboard Control section of the User Interface for CSS3 Working Draft
>     http://www.w3.org/TR/css3-userint#keyboard
>
>7. HTML4 Event Handlers
>     http://www.w3.org/TR/REC-html40/interact/scripts.html#events 
>--------------------------------------------------------
>He that lives on Hope, dies farting
>     -- Benjamin Franklin, Poor Richard's Almanack, 1763
>--------------------------------------------------------
>Gregory J. Rosmaita <unagi69@concentric.net>

>   WebMaster and Minister of Propaganda, VICUG NYC
>        <http://www.hicom.net/~oedipus/vicug/index.html>
>--------------------------------------------------------
>

Received on Thursday, 28 October 1999 10:10:39 UTC