Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!strath-cs!glasgow!gilbert From: gilbert@cs.glasgow.ac.uk (Gilbert Cockton) Newsgroups: comp.cog-eng Subject: Re: Tools for user interface RESEARCH Message-ID: <2998@crete.cs.glasgow.ac.uk> Date: 24 May 89 08:50:20 GMT References: <1085@dgbt.uucp> <4172@bgsuvax.UUCP> Reply-To: gilbert@cs.glasgow.ac.uk (Gilbert Cockton) Organization: Comp Sci, Glasgow Univ, Scotland Lines: 111 In article <4172@bgsuvax.UUCP> instone@bgsuvax.UUCP (Keith Instone) writes: >Why, you build the interface, of course. And you write programs >to collect the data, like response time and error rate. And >you conduct experiments. THAT'S A LOT OF WORK. Some UIMSs do have logging facilities (e.g. RAPID), as do some special purpose programming environments (e.g. NeWS). See Hartson and Dix in current ACM Computing Surveys. >One tool for developing interfaces are UIMSs. As best as I can >fathom, they are used to design interfaces and to help in implementing >specific interfaces. Are they used for testing them? Isn't the >general philosophy in UIMSs that they will crank out pretty >useful interfaces automatically? Certainly not, it is ONE philosophy, from the "programmer productivity" camp. There is no necessary commitment to high quality, user-centredness, or prototyping here (last one is impossible with a high degree of automation). There is still no consensus on what a UIMS is or should be (see Myers thesis, now published). Most definitions exclude toolkits as: a) they are not tools, they are code fragments; b) they are not complete, or even near complete, as a kit must be. on English semantics, toolkits score 0/2. On UIMS criteria: c) they do not manage, the underlying application does; d) they do not support iterative, participative design; e) they are a pig to use, badly designed (if at all designed), and require a (very) experienced programmer to program for too long. Frameworks (e.g. MacApp) are an interesting third option, which do less badly on (b), (c) and perhaps (e). They generally hide what should have been hidden in a toolkit anyway :-) >for testing, or do they just use findings from other research >to make good interfaces? I wish they were. Many toolkit and UIMS implementors do not waste time reading anything as irrelevant as human factors guidelines (e.g. SunView scrollbars). > o An underlying application. It should > already be programmed. Maybe a simple file manipulation system > for starters. Just something for the subjects to play with. If you're doing serious research you need more than one of these. > o Easy modification of the interface to control for my variables. > Maybe I am comparing pull down versus pop-up menus. Or > liner versus pie. Or using different phrases in the menus. All > these features have been programmed before. Why do it again? There is no such thing as THE pie menu. There is considerable choice, and a UIMS pitched at this level could make the wrong choice. This level of simulated logical input device (i.e. choice) is best provided as a standard library configuration, which can be copied and changed. Object-orientedness could help, but the programmer has some difficult public/private decisions. Encapsulation can be a bad thing in user interface configurations. Often you need to be as low level as NeWS to allow the range of variation which could be required across user/task combinations. > o Many types of interfaces supported. So I can try direct > manipulation, form fill in, sounds, whatever. We don't want > to be limited to the Macintosh style, for example. Probably the recipe for an unlearnable mammoth. Better to have library configurations for these, built on truly general lower level abstractions. > o Invisible data collection. Just sit the subjects in front > of the interface, let them do some work. Analyze the > results. Logging is straightforward if the input event queue/list is properly designed and accessible. Higher level logging may be required though, and this can be automated for some control abstractions (e.g. RAPID networks) > o Write my paper for me. Is this too much to ask? :^) As long as you acknowledge me, you can poach anything worthwhile from here :-) >Can my wish come true? It's close to true in some places. Unfortunately, much U.S. research is concentrating on automatic generation from high level semantic models. The desire is to get away from the 'what do we do with the next mouse click' level of UIMSs. At the moment, research is very ambitious, but some groups are still interested in lower level approaches (e.g. Myers and Szekely at CMU). My money's on the bottom up camp. No one has enough experience of user interface design to develop acceptable automatic generation of user interfaces. >So, to summarize, there are tools for developing interfaces. Are >there software tools for testing them? Are there software tools >for quickly and easily experimenting with interfaces? Use prototyping tools, including Hypermedia systems. These will constrain you, but no one's short of hypotheses in HCI at the moment. Good experiments could be done with HyperCard, and you should be able to do some logging via scripts (XCMDs anyone?). Hardware logging is also a possibility, and is used by some UK groups. Here you slip something between the keyboard and the mouse, and the computer. Very low level, but you can do some things with the byte streams. -- Gilbert Cockton, Department of Computing Science, The University, Glasgow gilbert@uk.ac.glasgow.cs !ukc!glasgow!gilbert