Upload
kelly-cook
View
221
Download
0
Tags:
Embed Size (px)
Citation preview
The Past, Present and Future of Programming in HCI
Brad Myers and Andy KoCMU UW
2
why talk about programming?
programming languages are human-computer interfaces
“The Psychology of Programming” – 1973
“Software Psychology” – Ben Shneiderman’s book1980
“Empirical Studies of Programming” (ESP) – 1986 through 1999
Psychology of Programming Interest Group (PPIG)
– since 1987
3
why talk about programming?
programming languages and tools affect human-computer interfaces
HCI researchers have contributed to the way most software is created today
ubiquitous use of toolkits and IBs
general computer use increasingly involves programming-like activity
- scripting, customization, mail rules, Web 2.0, etc.
talk outline
computing becomes a field 70’s, 80’s
everyone computes 80’s, 90’s
everyone is connected 90’s, 2000’s
everyone is programming the future
talk outline
computing becomes a field 70’s, 80’s
everyone computes 80’s, 90’s
everyone is connected 90’s, 2000’s
everyone is programming the future
6
drivers
the software industry was new
CS departments were new
but learning syntax was difficult and typing code was cumbersome
- studies of novice programming errors
- new interaction techniques (visual programming, programming by example, syntax-directed editors)
- algorithm animation, code visualization
7
trying to make programming easier
simpler languages
visual programming
visualization
programming by example
toolkits and interface builders
syntax-directed editors
interactive development environments
8
simpler languages
maybe we can make programming accessible by making the language simpler, and including graphics?- Basic (1963)
- Logo (1966)
- Pascal (1970)
- Hypertalk (1987)
Nope
9
why not?didn’t understand what was fundamentally hard about programming
- inherent difficulties of “computational thinking” [Lewis & Olson’s cognitive barriers, 1987]
- we identified 5 classes of barriers[Ko & Myers 2004]
- (have been hundreds of studies about why programming hard)
people confused when syntax is flexible
learning programming didn’t transfer to better learning in math & science
10
visual programmingmaybe we can make programming easier by using graphics instead of text?- PICT
- [Glinert 1984]
- Flowchart
- Only 4 variables
- Animate execution
11
visual programmingmaybe we can make programming easier by using graphics instead of text?- Agentsheets
- [Repenning 91]
- Agentsheets.com
- Before and afterpictures as rules
12
visual programmingmaybe we can make programming easier by using graphics instead of text?- try using ideas from spreadsheets
- NoPumpG:[Nicholas Wilde, Clayton Lewis. CHI’90]
- C32[Myers 91]
Nope
13
why not?
visual programming doesn’t scale to useful-size programs
visual programs have higher “viscosity”- “Cognitive Dimensions” analysis by T.R.G. Green
spreadsheet ideas haven’t generalized
didn’t transfer to helping large numbers of people to be able to program
14
visualization
maybe it will help to show pictures of the code and data
- Algorithm animation
- Code & data visualization
Nope
15
why not?
not a big part of the understanding problem
some people don’t understand the pictures either
Stasko showed that constructing viz might help learning, but viewing, not so much [CHI’93]
16
programming by examplemaybe it would work to let people provide concrete examples of what they want the computer to do?- Pygmalion
- [Smith 77]
- Show the computerthe desired steps
17
programming by examplemaybe it would work to let people provide concrete examples of what they want the computer to do?- Peridot
- [Myers 86]
- Show behavior ofcontrols (widgets)by example
18
programming by examplemaybe it would work to let people provide concrete examples of what they want the computer to do?- Gamut
- [McDaniel 96]
- Tries to infer morecomplex behaviors
- “Do Something”and “Stop That”
Nope
19
why not?
people are actually not very good at coming up with concrete examples- examples tend to show the system the same thing over
and over
- people can’t think of the edge cases and negative examples
people need to be able to edit the code, so need a representation they can understand
20
interface builders and toolkits
can people draw their user interfaces?can providing libraries help developers?- Menulay
- [Buxton 83]
- Draw graphical parts of UI
21
interface builders and toolkits
can people draw their user interfaces?can providing libraries help developers?- Andrew Toolkit
- [CMU 82]
- first component architecture
- Macintosh toolkit
- [Apple 84]
- provide a library of “widgets”
- object-oriented frameworks
- MacApp - 1986
YES!
22
why?(See HCIC’99 talk)
Address the useful & important aspects of UIs
Threshold / Ceiling
- Right balance
Path of Least Resistance
- Helps create good UIs
Predictability
- Programmers can tell what will happen
23
syntax-directed editors
maybe we can solve the problems with syntax by letting the editor help with it?
- Cornell Program Synthesizer, 1981
- MacGnome, 1988
Maybe?
24
why not?
quickly gets tedious for any reasonable size program
- syntax stops being the big issue fairly quickly
viscosity is a problem
- hard to edit programs
BUT….
25
AliceAlice [Pausch] (1995 - today)
drag-and-drop program parts
pop-up menus for parameters
dramatic impact onlearning andattitudes
wide uptake for firstfew weeks ofintro to CS
26
interactive development environments
maybe tools can help with the programming tasks?
creating, maintaining, debugging code
somewhat independent of the particular language
code completion, syntax coloring, indenting, integrated with debugger
early examples: Smalltalk (1972), Interlisp (1979), Mesa (1980)
YES!
27
why?
tools from the early 80’s had most of what is found in modern tools like Visual Studio and Eclipse
appropriate level of support for professional programmers
code completion is the most common means of exploring
- obviates need for short names and helps with slow typing
but why did it take so long?resistance from “real programmers” to using IDEs
- against adopting new tools
universities were biased towards Unix and away from Mac+PC, and no decent IDEs for Unix, so IDEs were not taught
- bias against teaching with tools
IDEs wouldn’t scale to “real” applications- Visual Studio not widely used internally at Microsoft
not until universities switched to Java that had good IDEs for students to use
- now, programmers are “used to” using IDEs
Eclipse also re-invigorated IDE research- plug-in architecture
29
summary of “becomes a field”
learning to program is still hard
building small things is easier
tools and toolkits and IDEs have a big impact on all all levels
talk outline
computing becomes a field 70’s, 80’s
everyone computes 80’s, 90’s
everyone is connected 90’s, 2000’s
everyone is programming the future
31
driverscomputers went from niche to ubiquitous
what people wanted software to do became incredibly complex
software gets more complex- more features because companies used feature-creep to sell new versions
- globalization created demand for internationalization
- viruses, spam, hackers code must be more secure
long-lived software the people who understood it are gone- too big & risky to rewrite, so need support for learning old software
need to use multiple languages and paradigms- database, web, spreadsheets, regular languages together
32
increased requirements
commercial software had to get more complex to meet these requirements
1960’s – 1980’s, what we built was limited in scope
- we built “large” systems, but of relatively simplicity
DOS 1.0 ~ 4,000 lines of 8086 assembly
Linux Kernel 2.6 ~ 6 million of C
Vista ~ 50 million
Increased requirements
even for research systems
used to be possible in research to make small things
- Garnet and Amulet were popular with less than 10 widgets
- now, any toolkit needs complex capabilities, like standards-compliant HTML rendering
- similarly, for IDEs – tool expectations about what is needed
APIs manage complexityold:
- write programs from scratch, or
- use Unix command lines, so used only use standard unix libraries
new: with Windows and Java, massive APIs
- Java very much designed without I/O built-in
- shift from writing from scratch to heavy reliance on APIs
- needing lots of documentation & examples
standardssoftware became more integrated and more standards based
- more different standards
- more complex standards
plain text (Unix) -> html -> XML
plain ASCII -> many different flavors of Unicode
standard protocols for IDEs
- expectations that IDE support CVS version control system
- standard for how to compile things
36
summary of “everyone computes”
how cope with increased complexity?
APIs to the rescue!
but during this period, little research work on new languages or tools for helping with software
talk outline
computing becomes a field 70’s, 80’s
everyone computes 80’s, 90’s
everyone is connected 90’s, 2000’s
everyone is programming the future
38
38
drivers
the Internet arrives, leading to…
open source software
globalization and outsourcing
streamlined information seeking
team-oriented tools
studies of software teams
38
39
39
open source software
now possible to collaborate remotely on large software projects
version control systems
bug reporting systems
blogs, IRC, mailing lists, Twitter, Google Docs, IM
39
40
4040
globalization & outsourcing
teams no longer fit into a room
separated by time zones
distance increased collaboration requirements
increased need for specifications, design rationale
41
intercontinental design rationale
41
Amazon hires “firefighters” to carry design rationale across the Pacific Ocean in their heads
42
42
streamlined information seeking
previously had to find expert (in person or on usenet) or a book
millions of examples on the web, blogs, usenet, discussion boards, etc.
search simplified finding …
example code
troubleshooting information
documentation42
43
43
team-oriented tools
Eclipse framework enabled a generation of integrated, collaborative tools
Jazz and Mylyn, two successful research projects in broad use
43
44
44
new software development methods
44
Agile/eXtreme Programming ideas
small groupscollocationrapid iterationconstant team awareness
software industry realizing that collaboration is a crucial part of software quality and productivity
45
45
studies of software teams
45
resurgence of studies of cooperative and human aspects of software development
coordination, awareness, expertise, ownership, decision-making, information seeking, trust, training, API usability
46
46
software industry, research is paying attention
Microsoft has growing group of HCI experts in Visual Studio division
Microsoft Research recently formed Human Interactions in Programming
software engineering research has increasing use HCI methods to understand problems, evaluate tools
46
47
47
summary of “everyone’s connected”
47
the Internet changed programming…
enabling new kinds of software teams
renewing interest in programmer productivity
blurring line between software engineering, CSCW, HCI
48
talk outline
computing becomes a field 70’s, 80’s
everyone computes 80’s, 90’s
everyone is connected 90’s, 2000’s
everyone is programming the future
49
49
end-user programming
more people are programming computers to support their work and hobbies
used to just be spreadsheets and HTML
…but now much more
49
50
50
e.g. word processingonline bankingphoto management
# of needy
need
e.g. Twittering a random synonym of the music genre playing on my iPod
100’s of appsmillions of users
millions of apps100’s of users
long tail of applications
51
51
mail rules to filter, file, and flag email
CoScripter/Chickenfoot/d.mix scripts to automate web tasks
CSS/JavaScript/AJAX to customize World of Warcraft clan site
programming = customization
52
52
250,000 financial analysts, biologists, statisticians, teachers, engineers, clinical medicine using R
no training in CS, all kinds of bugs, but “good enough”
most science today is fueled by custom software, often written by scientists
last month’s NY Times …
53
53
> 50 million end-user programmers
53
most people who write programs at work are not professional programmers
(based on data from US Bureau of Labor Statistics)
54
5454
end-user programming is enabling wonderful things…
…but it has its problems
55
5555
opportunism vs. discipline
opportunism is sufficient if - code isn’t reused
- requirements don’t drift
- and precision/accuracy of output isn’t critical
otherwise …
in 2003, TransAlta bought $24 mil in worthless hedging contracts because of a cut and paste error
56
programming is an educational barrier
56
programming is now so pervasive, it’s becoming part of engineering, science, art, design training
people are abandoning these disciplines because they involve programming
57
57
[Ko 2009 (?)]
almost all (non-CS) students learned to code with TI graphing calculators, BASIC, or “view source” command
positive, social experiences pre-college
negative, isolating in college
a study of 60 computing biographies
58
5858
languages and tools are terrible
need to design languages and IDEs that are expressive enough for unique domain requirements
how do we choose the right primitives
can we attain the benefits of software engineering practices without having to teach them?
59
summary of “everyone is programming”
59
everything that mattered in the 70’s, 80’s, 90’s and 2000’s to computer science and engineering…
…is soon going to matter to everyone
60
what’s the role of HCI
in this future?
61
61
open HCI issues
simplify creation of multi-language, multi-paradigm “mashed up” software
understand, predict API usability
understand software design as CSCW
create new languages/tools to support specific domains of work and hobbies
61
62
13 papers at CHI 2009
62
Team Analytics: Understanding Teams in the Global Workplace
ESPranto SDK: an Adaptive Programming Environment for Tangible Applications
Support for Context-Aware Intelligibility and Control
Comparing the Use of Tangible and Graphical Programming Languages for Informal Science Education
Designers Wanted: Participation and the User Experience in Open Source Software Development
Understanding How and Why Open Source Contributors Use Diagrams in the Development of Ubuntu
Development of Decision Rationale in Complex Group Decision Making
Finding Causes of Program Output with the Java Whyline
Fisheyes in the Field: Using Method Triangulation to Study the Adoption and Use of a Source Code Visualization
Two Studies of Opportunistic Programming: Interleaving Web Foraging, Learning, and Writing Code
Amplifying Community Content Creation with Mixed Initiative Information Extraction
Attaching UI Enhancements to Websites with End Users
User-created Forms as an Effective Method of Human-agent Communication