Re: Proposal: Single command input and edits to checkpoints about "easy access" (2.3 and 10.8)

mark novak wrote:
> 
> hi Ian, Jon, and others...
> 
> see comments at MN below:

Ian's comments preceded by IJ:

> MN:  I'm probably out of step with the group, but like to add a
> comment on this. I think the concept of "single command" should not imply or
> be retricted to " a single keypress" when referring to a keyboard, nor
> to a single "utterance" when referring to a voice input system, etc.

IJ: My understanding is that some users require single key press access
and have trouble with keys + modifiers or motion around the keyboard.
For these people, the single command qua a-singular-user-input doesn't
work. 

Also, as you indicate that it's more difficult to define the concept
that you have touched on. I don't think it's worth the effort since
I think we can get along without it. 

I like Jon's suggestion that 
one checkpoint should address the keyboard-specific needs indicated
above (motion across the keyboard + keys in combination) and
that this checkpoint only be about single key press access.

After that, I think that the other checkpoints can be specified
without recourse to a hard-to-define concept.

 _ Ian
 
> While it will be more difficult to define, I'd suggest that a "single command"
> encompass "a-singular-user-input  to  a-user- agent-action".   For
> example, if the user types "control+ h" (presses the control and
> then types the _h_ key [could also use StickyKeys to do this]), to navigate
> to the next header,  this would be an example of a "single command" even though
> it required two keys to be pressed.  Likewise, in an audio interface, I
> might say/voice "next header", a short utterance of two words, but still a
> "single command".
> 
> If we really *want* to  describe keyboard input in this manner, I'd rather
> see this
> "single command" defined in terms of "none, one, or more modifiers combined
> with a single non-modifier key" press.  That gives you several options:
> 
> x
> ctrl+ x
> shift+ctrl+x
> 
> but not
> 
> ctrl+x, ctrl+y
> 
> where x and y are any non-modifier key...
> 
> Another example:
> 
> In IE, I can type "alt+f" to open the file menu, and then "p" to print.
> I'd consider
> this two commands.  Or, I could type "ctrl+p" to print, which I'd consider
> one command.  (some people might call these accelerator keys, others short-cut
> keys, etc.)
> 
> If we are describing voice input, then this "single command" is whatever
> the utterance required per user agent action.  For example, "open file menu",
> "page up", "print", etc.   There isn't a direct link between number of words
> and "single command".
> 
> In either keyboard or voice input case/example, a good user interface will
> allow the user to reconfigure the bindings for frequently used keys/voice
> command or utterances, such that these types of distinctions between what
> is a single command and what else, quickly becomes blurred.

IJ: Exactly! That's why I am more and more convinced that we should
avoid the concept that is so difficult to define.


> Also, again
> in the keyboard model, keys can and do get remapped based on the "element"
> or GUI component with keyboard focus.
> 
> therefore, I'd suggest backing away from this a bit :
> 
> - single command or single input command is "device dependent", meaning
> you either make, for example,  checkpoint 10.5 very generic, or you make it
> very specific
> 
> - single command or single input command is not directly related/limited to a
> single key press or a single word utterance, but "could" be user configured
> as such via a checkpoint like 10.8
> 
> >2) What's the maximum number of keypresses that can be
> >   considered to constitute a single command?
> >   Is "Ctrl-X Ctrl-O" a single command? What about "Ctrl-x x"?
> 
> MN:  see previous....shouldn't be linked to number of keypresses..
> 
> >3) How do various OS facilities (such as StickyKeys)
> >   fit into the problem? If combinations of modifier keys and
> >   other keys are considered single command, does the usage
> >   of StickyKeys change that?
> 
> MN:  doesn't in my opinion
> 
> >4) What happens if the user agent enters a particular input
> >   mode, which changes the input configuration temporarily so
> >   that a new set of functionalities are one keypress away. Do
> >   these keypresses count as single keypress since the user had
> >   to do something else to enter the special input mode (e.g.,
> >   table navigation mode where single keys may be used to navigate
> >   around the cells of the table)?
> 
> MN:  related, see above...
> 
> >5) What corresponds to single keypress for voice input?
> >   It's probably not "single word" since I imagine being able to
> >   say "Page Down". Don't forget internationalization when
> >   trying to define the minimal discrete input act. I ask those
> >   with experience designing voice-operated interfaces to
> >   comment here: how does one express the minimal input
> >   act (e.g., what occurs up to the next pause of more than
> >   ms milliseconds)?
> >
> >6) What about other input methods such as button activation?
> >   Graphical UI is part of input configuration.
> >
> >The following proposals offer a definition of "single
> >command input" and way to avoid related but different terms
> >that might cause confusion in checkpoints 2.3 and 10.8.
> >
> >Proposal 1) Definition: Single command input
> >
> >  In this document, single command input means that the
> >  action required of the user is the simplest that can be
> >  recognized by the user agent for a particular input method.
> >  For the keyboard, this means "single key input", i.e., a
> >  single key press, without modifier keys such as "alt", "control",
> >  "apple", etc. For voice input, "single voice command input"
> >  means an individual vocal cue, though the number of words
> >  in a command may be more than on (e.g., "Activate link",
> >  "Page down", etc.) and should be few in number.
> >  For graphical user interface components, single command input means
> >  direct activation of the UI control (i.e., buttons, not menu
> >  items) with a pointing device.
> >  Note that any navigation through UI controls (by pointing
> >  devices or keyboard navigation) does not constitute single
> >  command input. Double command input means two single commands
> >  (e.g., a modifier key and another key), triple means three, etc.
> >
> >  The user agent may change the input configuration dynamically,
> >  and this may affect the set of single command bindings. The set
> >  of single command bindings is relative to an input configuration.
> >  For example, when the user is entering text, the number of
> >  single key input bindings may be reduced significantly.
> >  Or, if the user agent offers a special "table
> >  navigation mode" for cell-to-cell or cell-to-header navigation,
> >  those single key commands exist within the context of the
> >  table navigation mode.
> >
> > Note about proposal 1: Delete the part about different input modes
> >  from the note after checkpoint 10.5 since now it's in a definition.
> >
> >Proposal 2) Checkpoint 2.3
> >
> >  At the 20 July teleconference [2], we discussed eliminating
> >  the expression "easy access" in checkpoints 2.3 and 10.8.
> >  The proposal was to use "single command", which I find very
> >  confusing (using the term "single" to describe two different
> >  but closely related concepts is a mistake).
> >
> >  For checkpoint 2.3, refer to my proposal [3], which uses the
> >  term "easy access" but explains the techniques that would meet
> >  the requirement. I hope that this proposal satisfies the
> >  resolution from the 20 July teleconference [2]:
> >
> >    "No objections to modification of Jon's proposal for modification
> >2.3
> >     RESOLVED.- accept new proposal with modifications."
> >
> >Proposal 3) Checkpoint 10.8
> >
> >  For checkpoint 10.8, Jon proposed [4] the following wording:
> >
> >     10.8 Ensure that the default input configuration
> >          allows one step activation of frequently used
> >          functionalities.
> >
> >  Rather than "one step" (or "single step") I propose saying
> >  something like this:
> >
> >  <NEW>
> >       10.8 Ensure that the default input configuration
> >            offers single or double command access
> >            to functionalities the user is likely to use
> >            frequently.
> >          Note: For example, the default configuration
> >          might allow history navigation with arrow keys
> >          alone, modified arrow keys (e.g., Alt-left arrow)
> >          or both.
> >  </NEW>
> >
> >
> >Notes about Proposal 3:
> >
> > a) Some background about the goals of checkpoint
> >    10.8 provided by Charles in his review with some developers [4].
> >
> > b) There is no resolution marked in the
> >    20 July minutes about checkpoint 10.8.
> >
> > _ Ian
> >
> >[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000707
> >[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0097.html
> >[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0132.html
> >[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0032.html
> >[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0243.html
> >--
> >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
> >Tel:                         +1 831 457-2842
> >Cell:                        +1 917 450-8783

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 25 July 2000 15:25:33 UTC