The Past, Present and Future of Programming in HCI Brad Myers and Andy Ko CMUUW.

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

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





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





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





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

The Past, Present and Future of Programming in HCI Brad Myers and Andy Ko CMUUW.

Documents

Transcript of The Past, Present and Future of Programming in HCI Brad Myers and Andy Ko CMUUW.