Xref: utzoo comp.sys.mac:14591 comp.windows.misc:418 Path: utzoo!mnetor!uunet!mcvax!ukc!its63b!hwcs!hci!gilbert From: gilbert@hci.hw.ac.uk (Gilbert Cockton) Newsgroups: comp.sys.mac,comp.windows.misc Subject: Re: 2 button mouse Message-ID: <201@glenlivet.hci.hw.ac.uk> Date: 29 Mar 88 12:27:25 GMT References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <17702@think.UUCP> <1758@ssc-vax.UUCP> Reply-To: gilbert@hci.hw.ac.uk (Gilbert Cockton) Organization: Scottish HCI Centre Lines: 30 Keywords: window human computer interface In article <1758@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >How ergononomic!! :) Seriously, the whole idea of hitting the keyboard >*and* mouse is hardly elegant. Did Apple do a study on how hitting >the keyboard and mouse is easier for novice users. :) Being analytical here: a) hands on keyboard - homing time on mouse same for KM (Keyboard and Mouse) and M (Mouse only). Assumes can find key without looking. b) no hands on keyboard - homing time for KM more than for M (=0). So, at the keystroke level, we only loose out theoretically if the user does not have a hand on the keyboard. This need not happen, and in KM situations, it makes sense to keep your left/right hand near the keyboard. As for the novices, this sort of two-handed input can be learnt very quickly, once the keyboard layout is understood. If anything, the layout of the option/shift etc. keys is the source of many problems. Chording will add to problems if you need to be an octopus (as in some Cedar combinations). So, next time anyone designs a workstation keyboard, think about easy chording on those special keys, it could be a functional requirement. As you are always going to run out of mouse-buttons, all systems could end up using the KM approach to increase mouse-button bandwidth. -- Gilbert Cockton, Scottish HCI Centre, Heriot-Watt University, Chambers St., Edinburgh, EH1 1HX. JANET: gilbert@uk.ac.hw.hci ARPA: gilbert%hci.hw.ac.uk@cs.ucl.ac.uk UUCP: ..{backbone}!mcvax!ukc!hci!gilbert