Transcript CS376 Introduction - Stanford University

stanford hci group / cs376
Software Tools
Matt Wright
Center for Computer Research
in Music and Acoustics
(CCRMA), Stanford
14 October 2004
research topics in human-computer interaction
Readings
 Past, Present, and Future of
User Interface Software Tools,
Brad Myers, Scott E. Hudson,
Randy Pausch
 Natural Programming Languages
and Environments, Brad A.
Myers, John F. Pane, Andy Ko
14 October
Software Tools
2
Past, Present, and
Future
 Past: ideas that lived or
died
 Present: homogenous WIMP GUIs,
mature tools to make them
 Future: Ubicomp form factors
and networking, recognitionbased input, 3D, end-user
programmability (!)
14 October
Software Tools
3
Determinants of Success
 The parts of the user
interface that are addressed
 Threshold and Ceiling
 Path of Least Resistance
 Predictability
 Moving Targets
14 October
Software Tools
4
What Worked
 Window Managers (60s):
drawing, input
 Window Toolkits (Mac):
components & framework
 Event “languages” (“prog.
model”?)
 Interface builders: GUI GUI
builders
 Component Systems
 Scripting Languages
14 October
Software Tools
5
Why They Worked
 Good models (powerful and
well-matched to problem
domains)
 Good factoring
 Scripting + components +
interface builder = platform
14 October
Software Tools
6
What Didn’t Work (1/2)
 User Interface Management
Systems:
 High-level, abstract descriptions
of interfaces, system generates
implementation
 Designer wants to control lowlevel pragmatics
 Standard UI elements do this
factoring better
 Formal Language Based Tools
 Based on compiler tools (Regexp,
Software Tools
14 OctoberCFG)
7
What Didn’t Work (2/2)
 Constraints
 Good for users (spreadsheets, drawing)
 Bad for UI programmers (unpredictable,
hard to use and debug)
 Good for graphical layout (NeXTStep,
HTML(?))
 Model Based/Automatic Techniques
14
 Very high level abstract description
of interface
 Declare I/O needs; heuristics select
components, layout, etc.
 Unpredictability,
require new
Software Tools
October
8
Why They Didn’t Work
 “Impedence mismatch” between
problem and solution
 UIMS, Model-based too ambitious
 Formal Lang. tools too limited
 Constraints successful only at
right “scope” of what’s
constrained
 Moving Target problem
14 October
Software Tools
9
Futures:
commodification
 CS researchers less
ahead of
HW curve
 Multimedia
 Enable Ubicomp
14 October
Software Tools
10
Future: Ubicomp
 Deal with different I/O
capabilities
 Back to high-level, deviceindependent UI specification?
 Need device prototyping tools
 Networking, syncing
 Interpersonal and intrapersonal
 Standards vs. capitalism?
 Paper emphasizes tools; I
think representations are more
important.
14 October
Software Tools
11
Future: Recognition
(1/2)
 Gestures, handwriting, speech
 Must be interpreted by software
to identify content
 “Tools will be needed that hide
all of this complexity and
provide an easy-to-use interface
to programmers.”
 I think that’s a fantasy. (E.g.,
real-time fundamental frequency
estimation for interactive
computer music.)
Software Tools
14 October
12
Future: Recognition
(2/2)
 Uncertainty of input requires
feedback
 Interpretation of input
requires deep knowledge of
context
 No obvious segmentation into
discrete events
14 October
Software Tools
13
Future: 3D
 VRML not accepted
 Forget tools, we still need
paradigms:




Selection
Interaction
Navigation
Metaphors
14 October
Software Tools
14
Future (?!?): End-User
Programming, Customization,
Scripting
 Yay spreadsheets
 MS Office now “totally” VB
scriptable
14 October
Software Tools
15
Misc. Future Issues
 Users with worse dexterity,
memory, etc.
 Translucency, magic lens
 Components: easy to use, hard
to make
 Sitting, both hands free,
looking at UI?
 Computer has user’s full
attention?
14 October
Software Tools
16
[This space intentionally left blank]
14 October
Software Tools
17
“Natural”
 Ubicomp: pens are natural;
typewriters are artificial.
 Myers, Pane, Ko:
 “language and environment… work
in the way that people who do not
have programming experience would
expect.”
 “create programming languages and
environments that are more
“natural,” or closer to the way
people think about their tasks.”
14 October
Software Tools
18
“Unnatural”?
 Create thinking that empowers
people to accomplish their
tasks:





Indirection
Recursion
Matrices
Function as object
…
14 October
Software Tools
19
The Big Idea
 Design of programming
languages and environments
should be guided by Empirical
Studies of Programmers (ESP)
and HCI:
 What prog. lang. constructs cause
bugs?
 What questions do we ask
(ourselves) while debugging?
 What ideas do fifth graders use
to solve programming tasks on
Software Tools
14 Octoberpaper?
20
Programming as Adapting
to the Computer
 “[P]rogramming is the process
of transforming a mental plan
in familiar terms into one
that is compatible with the
computer”
 Therefore computer should work
the way we expect (i.e., the
way we think).
 Directness applied to prog.
lang. design.
14 October
Software Tools
21
Some Things People
Expect
 Undo




Cut and Paste
Save As
Search and replace
Command and filename
completion
…none are “natural”; they came
into our collective
14 October
Software Tools
22
Studies of “natural”
problem solving
 “Participants were presented
with programming tasks and
asked to solve them on paper
using whatever text or
diagrams they wanted to use.”
 85-page survey of novice
programming research:
http://web.cs.cmu.edu/~pane/cmu-cs-96132.html
14 October
Software Tools
23
Example task
14 October
Software Tools
24
Results
 Events cause action (“When
pacman loses all his lives,
it’s game over.”)
 Aggregate operators >
iteration
 Boolean logic rare and often
buggy. (E.g., “the cars with
license plates from Georgia
and Louisiana.”)
 Layout in pictures, actions
and behaviors in text
14 October
Software Tools
25
HANDS Screenshot
14 October
Software Tools
26
HANDS Programming Model
 All data are on global,
persistent, visible “cards”:
 Front: name/value lists
 Back: graphics or text for visual
display
 Cards in
 Computation done by “Handy”
handling events
14
 System generates all events
(collisions, clicks…)
 Imperative event-handler code (“add
score”)
Software Tools
October100 to the game’s
27
Success of HANDS
 Fifth graders could learn in 3
hours (!) and then use to
solve programming problems.
 Control group used “limited”
language without queries,
aggregate operations, and data
visibility:
14 October
Software Tools
28
How We Debug
 Hypothesizing what runtime actions
caused failure
 Observing data about a program’s
runtime state
 Restructuring data into different
representations
 Exploring restructured runtime
data
 Diagnosing what code caused faulty
runtime actions
 Repairing erroneous code to
prevent such Software
actions
Tools
14 October
29
Questions at time of
failure
 (32%) Why did x happen?
 (68%) Why didn’t x happen?
 (0%) Other
 WhyLine: a Workspace that
Helps You Link Instructions to
Numbers and Events
14 October
Software Tools
30
Using the WhyLine
14 October
Software Tools
31
14 October
Software Tools
32
WhyLine results
 Master’s students, identical
conditions
 Average debugging time 20
seconds/bug instead of 155
seconds/bug. (!)
 Group with WhyLine completed
40% more tasks in given 90
minutes.
14 October
Software Tools
33
Good Ideas
 Get real data on how (all
kinds of) programmers make
bugs, waste time…
 Design programming tools that
avoid these problems
 …do these techniques scale to
“real” programming?
14 October
Software Tools
34