Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!husc6!bunny!rv01
From: rv01@GTE.COM (Robert Virzi)
Newsgroups: comp.cog-eng
Subject: Re: Tools for user interface RESEARCH
Summary: Maybe not a tool, but a technique.
Keywords: user interfaces, research, tools (LONG)
Message-ID: <6932@bunny.GTE.COM>
Date: 16 May 89 12:50:46 GMT
References: <4128@bgsuvax.UUCP>
Organization: GTE Laboratories, Inc., Waltham, MA
Lines: 90

In article <4128@bgsuvax.UUCP>, instone@bgsuvax.UUCP (Keith Instone) writes:
> I have been thinking about all the different ways people
> are _studying_ user interfaces now-a-days.
> 
> 1.Lots of people are building user interface management systems (UIMSs) to
> make building interfaces easier.
> 
> 2.Several companies are making prototype interfaces and testing them
> to see which specific style/lookNfeel is best for them.
> 
> 3.Some people are doing laboratory experiments on both parts of the
> interface (menus vs icons, choice of color, ...) and on complete
> systems (direct manipulation vs commands vs menus, etc).
> 
         ... stuff deleted ...
> 
> So, I guess my question for all of you is:
> 
> Has anyone made a generic tool for user interface research?
> 
>   (defn. generic - runs on any system, supports any
>                    interaction style, easily configurable)
> 
>     [note: 'generic' is approximately like 'standard', but I don't
>       want to scare anyone away by using the s-word. (^; ]
> 
> If yes, what?
> If no, why not? Too hard? Nobody wants one? Waste of time?
> 
> Inquiring minds want to know!
> 


I don't know if this is what Keith had in mind, but I would like
to bring up a 'new' methodology that seems to be a topic of invest-
igation now.  Typical UI studies in a product development environment
have tended to focus on building accurate prototypes of the 
intended user interface that capture as much of the look and feel
of the user interface as possible.  Successive iterations are performed
on the prototype to move it closer and closer to the 'final' product.
The UI is treated as a whole, and high fidelity is sought (fidelity is
measured by how close the prototype seems to be to the end result).

An alternative approach is to actively avoid high fidelity to the
entire interface, while testing small pieces of it.  Thus the entire
user interface problem is subdivided into a number of critical parts,
each of which is attacked using smaller, cheaper, special purpose
prototypes.  The data accumulated from these smaller studies is then
combined and formalized in a description of the interface as it is to
be built (a requirements or specification document).

Are these appraoches really different?  I think that they are.  Perhaps
the main difference is that the latter approach, let's call it low fidelity
prototyping, can occur earlier in the design process.  The experimenter
does not need to know what the delivery platform will be, and can use
results from the early prototypes to drive the selection.  (I believe
this has been called requirements prototyping in the literature.)
By subdividing the problem, the researcher can build cheaper prototypes
that may allow him/her to explore a broader range of alternatives.

Let me give a brief example.  Let's say a university is going to build a
system that allows students to register for courses.  Under scenario 1,
a group of designers chooses a delivery platform and sets about building
a prototype.  Let's assume they choose to use kiosks that will
be placed strategically around campus.  They would then set about optimizing
the interface for this delivery vehicle.  Under scenario 2, the designers
ask the question, What's the best delivery vehicle?  They might build two
small, only partially functioning prototypes, that capture the essense of
the two approaches.  Let's say the kiosk approach is one and an audiotext
system is the other.  The prototypes would be, by necessity, small and
only capture a piece of the total user interface.  They might be mocked
up using crude techniques and fidelity would be sacrificed to gain breadth
of coverage.  The benefit is that one avoids the trap of local optima
while seeking a global one.  I would draw the analogy to simulated
annealing techniques applied to operations research.

Which approach is better?  What, if anything, can you learn using these
low fidelity prototypes?  If it turns out that lo-fi is a cheaper way to
gain information, then it will affect the tools we need to do user interface
reasearch.  We would want tools that allow broad coverage, but that 
sacrifice depth and flexibility within a narrow domain.  We need tools
that will let us see the forest, not just one particular tree.

So, get out your flamethrowers, I've got my asbestos suit ready.  

-- 

-Bob Virzi                    | Innuendo ...
 rv01@gte.com                 |
 ...!harvard!bunny!rv01       | ... and out the other.