- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 25 Jul 2000 15:25:25 -0400
- To: mark novak <menovak@facstaff.wisc.edu>
- CC: w3c-wai-ua@w3.org
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